Web应用程序的微服务架构

微服务：将应用程序构建为独立服务

传统的Web应用程序是作为一个单一单元构建的——一个单体。处理用户、产品、订单和支付的所有代码都存在于一个代码库中，作为一个应用程序部署。微服务采用不同的方法：每个业务能力都成为自己的独立服务，拥有自己的代码库、数据库和部署周期。

拆分的好处

微服务的主要优势是独立性。团队可以同时处理不同的服务，而不会互相干扰。每个服务可以独立部署，因此对支付服务的更改不需要重新部署整个应用程序。服务可以独立扩展——如果产品目录比用户帐户获得更多流量，您只需扩展目录服务。

微服务还允许您为不同的工作使用不同的技术。产品目录可能最适合使用Node.js和MongoDB，而支付服务需要Java来保证事务。如果一个服务崩溃，其他服务可以继续运行，从而限制故障的爆炸半径。

挑战

微服务引入了显著的复杂性。您可能需要多次网络调用不同的服务来组装一个页面，而不是一次数据库查询。网络延迟成为一个因素。确保跨服务的数据一致性比在单体数据库中更难。调试跨多个服务的问题需要分布式追踪。

服务通信需要精心设计。同步调用（HTTP/gRPC）很简单，但可能导致级联故障。异步消息传递（通过消息队列或事件总线）解耦了服务，但增加了复杂性。您需要服务发现，以便服务可以相互找到。您需要API网关为客户端提供单一入口点。您还需要断路器来防止故障蔓延。

何时微服务有意义

微服务并非适合所有项目。对于构建简单应用程序的小团队来说，单体开发更快，管理更容易。当您有多个团队，每个团队拥有不同的业务领域，并且系统的不同部分具有不同的扩展需求时，微服务变得有价值。

许多成功的团队从结构良好的单体开始，并在需要时拆分出服务。过早的微服务——在理解领域边界之前拆分应用程序——通常会导致一个分布式的混乱，比您开始的单体更难管理。

关键模式

如果您采用微服务，有几种模式有助于管理复杂性。API网关模式为客户端提供单一入口点，将请求路由到适当的服务。Saga模式通过协调一系列本地事务来管理分布式事务。CQRS模式分离读写操作。事件溯源模式将更改存储为一系列事件，提供完整的审计跟踪。