微服务设计模式.pdf

微服务设计模式 微服务架构已经成为现代应用程序开发的主流。虽然说它能够解决某些问题，但却也不是万金油。在使用这个体系架构时，还有许多的问题要我们解决。这就需要学习这些问题的通用模式，并通过可复用的解决方案来解决问题。因此，有必要讨论微服务的设计模式。 在深入研究设计模式之前，我们还需了解微服务架构的构建原理： 1. 可拓展性 2. 可用性 3. 弹性 4. 独立自主 5. 分散治理 6. 故障隔离 7. 自动配置 8. 通过 DevOps 持续交付 应用这些构建原理会带来一些挑战和问题。让我们讨论这些问题及其解决方案。 分解模式 微服务就是让应用服务松散耦合，但是将应用程序分解成较小的部分还必须要在逻辑上实现。那我们如何将应用程序分解为小型服务呢？ 解决方案：一种策略就是按业务能力分解，业务能力是企业业务价值的体现。业务的功能取决于业务的类型。例如，保险公司的业务能力通常包括销售，市场营销，承保，理赔处理，开票，合规性等。每种业务能力都可以视为一种服务，但它面向的是业务而不是技术。 按子域划分 问题：按业务功能来分解应用程序或许是个不错的思路。但是我们可能会遇到某些比较难以分解出来的类（God Classes），这种类在多种服务中通用。比如，订单类用于“订单管理”，“接单”，“订单交付”等业务中。那我们该如何来分解呢？ 解决方案：对于这种难以分解出来的（God Classes）类，使用DDD（即领域驱动设计）可以解决。它使用子域和有界上下文概念来解决此问题。DDD将为企业创建的整个域模型分解为子域。每个子域都有一个模型，该模型的范围称为有界上下文。每个微服务将围绕有界的上下文进行开发。 扼杀者模式 问题：到目前为止，我们所讨论的设计模式都是分解未开发的应用程序，但是我们所做的工作中有80％是用于已开发的应用程序（brownfield applications）中，这是个大型的整体应用程序。上述所有设计模式并不是适用于它们，因为把它们作为一个整体应用的同时将它们拆分成一个个较小的部分是一项艰巨的任务。 解决方案：扼杀者模式可以解决此类问题。扼杀者模式是以缠绕类的藤蔓植物作为类比。该解决方案是与Web应用程序配合使用，在Web应用程序之间来回调用，对于每个URL的调用，一个服务可以分为不同的域并作为单独的服务托管。这个想法是一次做一个域，这将会创建两个单独的应用程序，它们并行存在于同一个URL空间中。最终，新重构的应用程序会“扼杀”或者替换原来的应用程序，直到最后可以停止整个应用程序。 API 网关模式 问题： 1. 当一个应用程序被分解为多个微服务时，还有一些问题需要解决： 2. 如何调用多个微服务来抽象化生产者信息。 3. 在不同设备上（比如台式机，移动设备和平板电脑），由于UI可能存在不同，应用程序需要不同的数据来响应相同的后端服务。 4. 不同的使用者对于可重复使用的微服务响应格式可能不同，那由谁来进行数据转换或者字段操作。 5. 生产者微服务可能不支持某些类型协议的处理方式。 解决方案： 1. API 网关有助于解决因微服务实现而引起的许多问题，而不仅限于上述问题。 2. API 网关是任务微服务调用的单一入口点。 3. 用作代理服务，将请求路由至相关的微服务，从而抽象出生产者的详细信息。 4. 将一个请求发送至多个服务，然后把响应结果聚合后发送回消费者。 5. 通用的 API 网关无法满足所有的消费者需求。可以为每种特定类型的客户端创建细粒度的 API。 6. 将协议请求（例如 AMQP）转换成另外一个协议（例如 HTTP），反之亦然，以便生产者和消费者处理它。 7. 它还可以减轻微服务的身份验证/授权责任。 聚合模式 问题：我们已经讨论过如何解决API 网关模式中的聚合数据问题。但是，接下来我们将会更加全面地讨论它。比如，在将业务功能分解为几个较小的逻辑代码时，有必要考虑聚合每个服务返回的数据。这个任务不能留给消费者，因为如果这么做消费者可能需要了解生产者应用程序的内部实现。 解决方案：聚合模式有助于解决此类问题。它讨论了关于如何聚合来自不同服务的数据，然后将最终响应结果发送给消费者。我们可以通过以下两种方式来实现： 1. 复合微服务将调用所有必需的微服务，整合数据，并在回退数据之前转换数据。 2. 用 API 网关将请求划分为多个微服务并聚合数据，然后再将其发送给使用者。 3. 如果要应用任何业务逻辑，建议选择使用复合微服务。否则，API 网关是已建立的解决方案。 客户端 UI 组合模式 问题：当通过分解业务功能/子域来开发服务时，负责用户体验的UI组件如何与后端微服务集成？如何将不同的微服务集成到一个一致的用户体验中？