微服务架构风格

微服务体系结构由一组小型的、自治的服务组成。每个服务都是自包含的，应该在有限的上下文中实现单个业务功能。有界上下文是业务中的一个自然划分，它提供了一个域模型存在的显式边界。

什么是微服务？

• 微服务是小型的、独立的、松散耦合的。一个小型的开发团队就可以编写和维护一个服务。
• 每个服务都是一个单独的代码库，可以由一个小型开发团队来管理。
• 服务可以独立部署。团队可以更新现有服务，而无需重建和重新部署整个应用程序。
• 服务负责保存自己的数据或外部状态。这与传统模型不同，传统模型中有一个单独的数据层来处理数据持久性。
• 服务通过使用定义良好的api相互通信。每个服务的内部实现细节对其他服务都是隐藏的。
• 支持多语言编程。例如，服务不需要共享相同的技术堆栈、库或框架。

除了服务本身，还有一些其他组件出现在典型的微服务体系结构中：

管理/协调。这个组件负责在节点上放置服务、识别故障、跨节点重新平衡服务等等。通常这个组件是现成的技术，比如Kubernetes，而不是定制的。

API网关。API网关是客户端的入口点。客户端不直接调用服务，而是调用API网关，该网关将调用转发到后端的相应服务。

使用API网关的优点包括：

• 它将客户机与服务分离。可以对服务进行版本控制或重构，而无需更新所有客户机。
• 服务可以使用非web友好的消息传递协议，如AMQP。
• API网关可以执行其他交叉功能，如身份验证、日志记录、SSL终止和负载平衡。
• 开箱即用的策略，如用于限制、缓存、转换或验证的策略。

微服务好处

• 敏捷性。因为微服务是独立部署的，所以更容易管理错误修复和功能发布。您可以在不重新部署整个应用程序的情况下更新服务，并在出现问题时回滚更新。在许多传统的应用程序中，如果在应用程序的某个部分发现一个bug，它可能会阻止整个发布过程。新特性可能会被搁置，等待bug修复被集成、测试和发布。
• 小型、专注的团队。微服务应该足够小，一个单一的功能团队可以构建、测试和部署它。团队规模小有助于提高灵活性。大型团队往往效率较低，因为沟通较慢，管理开销增加，灵活性降低。
• 小代码库。在单片应用程序中，随着时间的推移，代码依赖关系有变得混乱的趋势。添加一个新功能需要在很多地方接触代码。通过不共享代码或数据存储，microservices体系结构可以最大限度地减少依赖性，从而更容易添加新功能。
• 技术组合。团队可以选择最适合他们服务的技术，适当地使用技术栈的组合。
• 故障隔离。如果单个微服务变得不可用，它不会中断整个应用程序，只要任何上游微服务被设计成正确地处理故障（例如，通过实现断路）。
• 可扩展性。服务可以独立扩展，允许您扩展需要更多资源的子系统，而无需扩展整个应用程序。使用诸如Kubernetes或servicefrich之类的编排器，您可以将更高密度的服务打包到单个主机上，这样可以更有效地利用资源。
• 数据隔离。执行模式更新要容易得多，因为只有一个微服务受到影响。在单片应用程序中，模式更新可能变得非常具有挑战性，因为应用程序的不同部分都可能接触相同的数据，因此对模式的任何更改都是有风险的。

微服务挑战

微服务的好处不是免费的。以下是在开始微服务架构之前需要考虑的一些挑战。

• 复杂性。微服务应用程序比等效的单片应用程序有更多的活动部件。每个服务都比较简单，但整个系统作为一个整体更为复杂。
• 开发和测试。编写依赖于其他依赖服务的小型服务需要不同于编写传统单片或分层应用程序的方法。现有的工具并不总是设计用于处理服务依赖关系。跨服务边界重构可能很困难。测试服务依赖性也很有挑战性，尤其是在应用程序快速发展的情况下。
• 缺乏治理。构建微服务的分散方法有其优点，但也可能导致问题。您可能会遇到如此多不同的语言和框架，以至于应用程序很难维护。在不过度限制团队灵活性的情况下，制定一些项目范围的标准可能是有用的。这尤其适用于横切功能，如日志记录。
• 网络拥塞和延迟。使用许多小的、细粒度的服务可以产生更多的服务间通信。另外，如果服务依赖链太长（服务A调用B，B调用C…），那么额外的延迟可能会成为一个问题。您需要仔细设计api。避免过于健谈的API，考虑序列化格式，并寻找使用异步通信模式（如基于队列的负载均衡）的地方。
• 数据完整性。每个微服务负责自己的数据持久性。因此，数据一致性可能是一个挑战。尽可能保持一致性。
• 管理层。要成功使用微服务，需要成熟的DevOps文化。跨服务的相关日志记录可能很有挑战性。通常，日志记录必须关联单个用户操作的多个服务调用。
• 版本控制。对服务的更新不能中断依赖它的服务。多个服务可以在任何给定的时间更新，因此如果不仔细设计，您可能会遇到向后或向前兼容的问题。
• 技能组合。微服务是高度分布式的系统。仔细评估团队是否具备成功的技能和经验。

微服务最佳实践

• 围绕业务领域的模型服务。
• 分散一切。独立团队负责设计和构建服务。避免共享代码或数据模式。
• 数据存储应该是拥有数据的服务的私有存储。为每种服务和数据类型使用最佳存储。
• 服务通过设计良好的api进行通信。避免泄露实现细节。api应该为域建模，而不是服务的内部实现。
• 避免服务之间的耦合。耦合的原因包括共享数据库模式和严格的通信协议。
• 将交叉关注点（如身份验证和SSL终止）卸载到网关。
• 将领域知识排除在网关之外。网关应该在不了解任何业务规则或域逻辑的情况下处理和路由客户端请求。否则，网关将成为依赖项，并可能导致服务之间的耦合。
• 服务应该具有松散耦合和高功能内聚性。可能一起更改的功能应该一起打包和部署。如果它们驻留在不同的服务中，那么这些服务最终会紧密耦合，因为一个服务中的更改将需要更新另一个服务。两个服务之间过于健谈的通信可能是紧耦合和低内聚的症状。
• 隔离故障。使用弹性策略来防止服务内的故障级联。请参阅弹性模式和设计可靠的应用程序。