译者|李腾辉几十年来，人们一直采用单体架构来开发应用程序，现在越来越多的人转向微服务架构。微服务架构可以为我们带来更快的开发迭代、更高的可扩展性、可靠性和灵活性——使用更合适的技术栈来开发每个组件。微服务架构依赖于独立部署的微服务。每个微服务都有自己独特的业务逻辑和数据库，其测试、增强和扩展与其他服务无关。然而，微服务架构也面临着诸多挑战。为了解决最常见的问题，一些设计模式被广泛采用和改进。在本文中，我们将介绍其中最重要的部分。必备的设计模式在微服务架构中，必备的设计模式不止8种。根据您正在开发的应用类型，我们将它们分为两类——绿地应用（Greenfieldapplication）和棕地应用（Brownfieldapplication）。接下来，我们将更详细地研究这些模式。全新应用程序的设计模式当我们从头开始设计应用程序时，我们拥有所有最新最好的微服务设计模式供我们使用，所以让我们仔细看看。API网关模式当你将整个业务拆分成多个微服务时，你会遇到以下问题：鉴权、限流、重试、负载均衡、服务发现等问题如何处理？如何避免客户端直连微服务带来的网络拓扑混乱和高耦合的问题？如果客户端只需要部分数据集，谁来做数据过滤和映射？如果客户端需要调用多个微服务来获取完整的数据，谁来做数据聚合？为了解决这些问题，APIGateway应运而生。它位于客户端和微服务之间。具有反向代理、请求聚合、优雅下线、服务发现等功能，还可以根据客户端的不同选择，对外暴露不同的API。界面。图1–API网关示例UI组合模式在此模式中，微服务由负责特定业务的不同团队开发。某些UI页面可能需要来自多个微服务的数据。例如，购物网站包括类别、购物车、购买选项和用户评论等功能。这些数据属于每个微服务，负责不同的团队。如何协调这个问题？UI团队可以创建一个页面框架，通过组合多个UI组件来构建一个完整的页面。这个框架也被称为单页应用程序（SPA，single-pageapplication）。AngularJS、ReactJS等前端框架都支持该功能。.这种模式还带来了更好的用户体验，允许用户刷新任何指定的页面区域。独立数据库模式的微服务需要设计成独立松耦合的，那么对应的数据库架构应该是什么样的呢？有一些问题需要考虑：一个具体的业务场景可能会涉及到查询、连接表、多个服务的持久化等数据库操作，而这些服务由不同的团队来处理。在异构微服务架构中，每个微服务服务可能有不同的数据存储需求，如非结构化数据（NoSQL数据库）、结构化数据（关系数据库）、图数据（Neo4j）考虑可扩展性，数据库需要有备份和分片图2–Services配置独立数据库示例一个微服务事务必须限制在自己的数据库中，其他需要此类数据的服务必须调用这个微服务的API接口。如果您使用的是关系数据库，那么每个服务都使用自己独立的库来帮助确保数据隐私。同时，为了更好地隔离数据访问，最好为每个服务分配不同的数据库账户，这样可以保证开发者无法绕过微服务API直接访问数据库。独立的数据库模式使每个微服务能够选择最适合的数据库类型，例如使用Neo4j进行社交图数据，使用Elasticsearch进行文本搜索。在Saga模式下，当我们为每个服务配置一个独立的数据库时，在实现跨服务事务时就会出现问题，因为这样的话，本地的ACID已经无法处理了，如何保证数据的一致性呢？解决方案是使用saga模式。Saga是指一系列本地事务，每个本地事务更新数据库后，发布一个事件来触发下一个本地事务。saga模式还需要在任何本地事务失败时进行补偿。saga模式有两种实现方式：Choreography——去掉控制器，每个微服务负责监听和发布事件，并在失败时启用补偿事件。控制比编排更容易实现，在编排中只有控制器需要协调所有事件，而在编排中，每个微服务都必须监听事件并对事件做出反应。Fuse模式在微服务架构中，一个操作涉及调用多个微服务。如果其中一个下游服务出现故障，会继续调用下游服务，最终会耗尽所有网络资源，造成严重的用户体验差。那么我们如何处理级联故障呢？我们从断路器中得到灵感，设计了熔断器模式来解决这个问题。具体来说，在客户端和微服务之间，设置了一个熔断器来跟踪调用失败的次数，如果超过一个阈值，就会触发熔断器并快速失效。一段时间后，断路器会允许少量请求通过，检查服务是否正常。如果正常则恢复流量，否则会持续断线一段时间。图3–断路器状态机按业务或子域划分。在微服务架构中，复杂的大型应用必须合理划分，高内聚，低耦合。每个微服务还应该是自治的和足够小的，可以由一个“披萨大小”的团队（6-8人）来开发和维护。那么，我们应该如何划分服务呢？一般来说，有两种划分方式——按业务能力或子域划分：业务能力是指能够产生价值的行为，例如在航空公司中，业务能力可以是订票、销售、支付、选座等。;领域概念来源于领域设计模式（Domain-DesignPattern，DDD），一个领域由多个子领域组成，如产品目录、订单管理、配送管理等。适合棕地应用的设计模式由于互联网应用已经发展了几十年，大约公司80%的业务运营都是基于现有的应用程序，这些应用程序被称为棕地应用程序。将棕地应用程序迁移到微服务架构极具挑战性。让我们看看有哪些设计模式可以帮助我们更好地简化迁移工作。绞杀模式绞杀模式以藤蔓命名，通过缠绕杀死它所附着的树。在这种模式下，单体应用的功能逐渐被微服务所取代。对于客户端来说，由于外部API保持不变，客户端感知不到任何变化。随着转换的进行，最终所有的功能都被重构为微服务，新的架构被“干掉”，取代了原来的单体架构。防腐层模式当新应用需要与遗留应用集成时，过时的底层协议、API和数据模型是一个令人头疼的问题。妥协遗留模式和旧语义会限制和破坏新应用程序的技术设计。我们怎样才能避免这个问题呢？我们需要添加一个防腐层来转换两个系统之间的通信。防腐层兼容新旧应用的数据模型，根据通信的对象决定使用哪种通信方式。这样就实现了双赢，既不改变旧应用的逻辑，又保证新应用不需要在设计和技术上做出妥协。图4–防腐层示例总结微服务架构为开发人员带来了很大的灵活性，但随着要管理的组件数量的增加，也带来了很多困难。在这篇文章中，我们介绍了微服务应用开发最本质的设计模式，供读者了解和学习。译者介绍李腾辉，社区编辑，目前就职于某东南亚互联网金融独角兽，任高级Java工程师，负责金融借贷平台的架构设计和核心建设。对互联网金融架构、微服务体系有深入研究。金田继续深耕。原标题：PopularDesignPatternsforMicroservicesArchitectures，作者：RajeshBhojwani链接：https://dzone.com/articles/popular-design-patterns-for-microservices-architec
