【.com原稿】将一个单一功能的应用单元分解为多个微服务单元，这就是微服务在处理传统单体架构时的思路。然而，事实上，微服务的架构模式远不止于此。如今，它已成为各大主流软件的首选开发方案。微服务在提高系统整体性能的同时，也有自身的一些局限性。因此，对于架构师来说，需要掌握各种微服务设计模式的特点和适用范围。下面，在开始深入之前，先简单回顾一下微服务架构的基本概念和整体功能。微服务架构的设计原则微服务架构的设计原则如下：高内聚、低耦合。无缝的API集成。为每个服务分配一个唯一的资源ID。实时交通管理。最小化数据表以优化加载。通过内部/外部API执行持续监控。为每个微服务隔离数据存储。这对于限制对数据的访问和避免“服务耦合”很有用。例如：基于用户分类数据，我们可以实现命令查询职责分离（CommandQueryResponsibilitySegregation，CQRS）。分散的。设计微服务架构的首要原则是将单体结构分解为独立的多个实体，这些实体称为微服务。这些微服务可以独立于其他系统功能提供服务，用户在其他地方对它们的所有编辑、删除或使用都不会影响系统的整体性能。可扩展性。微服务的设计目标是：性能和效率。在现实世界中，解决大规模系统的可扩展性问题是任何微服务生态系统的性能表现。虽然丰富的技术能力为海量数据工作负载带来了多条数据，但如果实施得当并使用各种应用控制器（ApplicationController），它可以使微服务架构更具可扩展性。通过与DevOps集成实现持续交付。DevOps的多技术互操作和集成更适合微服务架构。在设计微服务架构时，我们需要着重于提高性能和系统效率，这符合DevOps更快交付解决方案的理念。与传统的单体设计相比，它更适合可部署、可靠和可扩展的解决方案管理。当然，相比于以上的原则和优势，微服务架构也有一定的局限性。幸运的是，我们有多种微服务设计模式可供选择，以实现我们自己的系统设计目标。让我们一一讨论。有效协作的微服务设计模式高效的微服务架构必须使多个微服务能够有效协作并同步运行。聚合器微服务设计模式涉及多个业务，所以我们有必要为最终用户捕获输出并进行组合。对于用户来说，如果要自己合并数据，需要对系统内部有很多了解。那么，我们在设计微服务架构的时候，为了打破这种单一性，我们应该按照输出来划分资源。因此，我们使用聚合器模式来聚合这些数据。该解决方案可以通过两个主要组件呈现给最终用户。其中之一是带有API网关的复合微服务。它可以聚合数据并将其转发给用户。如果需要在分解后的系统中使用各种业务功能模块，复合微服务应该是你的首选。分支微服务设计模式该模式扩展了聚合器设计模式。在fork模式下，您可以通过两个独立（更准确地说：互斥）的微服务链并发处理请求和响应。这种设计模式根据您不同的业务需求，为单个或多个服务链提供了灵活性。例如：对于电子商务网站或Web应用程序，我们可能会按需接收来自不同微服务的多个数据源。后端从前端/API网关的每个运行服务中获取数据，是任何应用程序的主要任务。对于微服务架构，从独立的服务中提取数据也很重要。然而，仅通过一个用户界面（UI）从大量微服务中获取用户手中的资源信息并不是一件容易的事。因此，就像企业中的服务台一样，我们可以通过API网关为微服务架构中的所有交互操作提供统一的入口。此外，在安全方面，APIGateway还有助于实现用户授权，并为合适的用户提供相关的API。因此，API网关作为单一入口，不仅可以作为代理服务器将各种请求路由到不同的微服务，还可以聚合多个服务的输出结果发送给用户。可以处理多种协议请求，按需转换（比如实现HTTPS和AMQP之间的转换）。用于性能监控的微服务设计模式性能监控是确保微服务架构成功的另一个重要方面。它有助于衡量系统的效率并了解拖慢系统速度的罪魁祸首。以下模式涉及可观察性的范围，可以保证微服务架构设计的健壮性。日志聚合微服务可以独立并行地支持多个其他服务。此外，它的实例可以跨机器。同时，每个服务都会根据其执行情况生成一个日志条目。那么我们如何追踪这些海量的服务相关日志呢？这就是日志聚合模式的用武之地。为了防止混乱，我们应该设置一个可以为所有微服务实例聚合日志的主服务。此外，这个集中的日志应该具有搜索和监控功能。微服务架构的综合监控（或语义监控）监控是一项繁琐但又必不可少的工作。当数百个服务同时运行时，查明日志存储库中故障的根本原因会更加困难。这就是综合监控可能派上用场的地方。当您自动化测试时，综合监控可帮助您定期将结果与生产环境进行映射和比较。一旦发生故障，将及时警告用户。此外，语义监控还可以帮助您实现以下两个方面：监控自动化测试用例。根据业务需求检测生产环境中的故障??。同时，随着系统负载和微服务数量的增加，持续监控系统性能并发现跨服务的潜在问题非常重要。我们可以通过指标服务收集各种数据。度量服务可以采用“推”和“拉”两种形式。顾名思义，推送服务（如：AppDynamics）就是将抓取的数据指标推送到服务器；而拉取服务（如：Prometheus）则负责从服务中拉取相应的数据指标。APIHealthCheck微服务架构的设计促进了每个服务的独立性，避免了系统中的任何延迟。我们知道API可以在网络连接中发挥基石作用。我们需要通过对API的定期健康检查来提前发现各种障碍。例如，您可能经常观察到微服务已启动并正在运行，但无法处理任何请求。那么，下面是一些导致API失败的因素：服务器负载、用户使用、各种延迟、错误日志下载，为了应对以上因素，我们应该保证每个服务都配备特定的API进行健康检查当它运行端点时。例如：我们可以通过在每个服务的末尾附加HTTP/health参数来返回每个服务实例、主机、连接、算法逻辑的健康状态。同时，服务注册中心需要周期性调用健康检查API端点来执行相关的健康扫描任务。健康检查的内容可以包括以下几个方面：针对具体应用的系统逻辑。主机状态。与其他基础设施或任何服务实例的连接状态。为业务能力改变一切在将单体架构分解为多个微服务的过程中，我们需要根据实际情况遵循不同的设计模式。独特的微服务业务能力微服务的成功应该充分体现高内聚、低耦合的特点。因此，各种服务需要在抽象相似功能的基础上保持低耦合状态。那么，我们如何将一个软件系统分解成更小、更独立的逻辑单元呢？我们需要定义微服务的范围来支持特定的业务能力。例如，我们可以将组织的内部架构划分为技术、市场、公关、销售、服务、运维等不同的部门。这些不同的职能部门可以看作是各种微服务，组织本身就是一套系统。因此，为了保持效率和预测增长，我们需要按照业务能力对系统进行分解，根据各种能力产生的价值来区分不同的业务领域。围绕类似业务能力的微服务虽然我们可以根据业务能力对各种微服务进行分类，但是我们如何处理那些服务中的公共类呢？这里，我们可以使用需要介入的“神类”来分解这些类。例如，在电子商务系统中，订单是订单号、订单管理、订单退货和订单发货等服务使用的公共类。因此，针对这个问题，我们引入了领域驱动设计（DDD）的微服务设计原则。在领域驱动设计中，我们使用子域。这些子域模型应该是预先确定的功能范围，即限界上下文（boundedcontext）。这些限界上下文用作创建微服务的参数，从而克服了与泛型类相关的问题。上面的割藤模式我们讨论了新单体架构概念的分解，下面我们来看看如何将现有的单体系统转换为微服务架构。在这里，我们介绍一下砍藤模式。由于在Web应用中，经常会涉及到不同领域的服务之间的往返调用，因此刀砍模式非常适合领域切分。在这种模式下，虽然系统会有两个域共享同一个URI，但是一旦一个服务完成转换，我们就会砍掉对应应用中的现有版本。并且，这个过程一直持续到单片系统不复存在。优化数据库存储的微服务设计模式就微服务架构而言，其松散耦合的特性造就了单个服务的部署和扩展能力。但是由于不同的服务有不同的存储需求，它们可能需要访问不在本地存储的数据。让我们根据不同的需求讨论一些适合使用的主要数据库设计模式。基于服务的分离数据库在领域驱动设计的原则中，基于服务的分离数据库是将整个数据库分配给特定的微服务。因此，我们需要根据业务提前设计专属的数据库。换句话说，任何其他外部微服务都无法访问未分配给它们的其他数据库中的数据，除非是通过微服务的API网关。基于服务的共享数据库如果我们仅仅将上述独享数据库模式应用到单体架构分解为多个微服务的场景中，那么难免会遇到各种麻烦。因此，我们可以在分解过程中针对有限数量的服务采用基于服务的共享数据库模式。而且这个数量一般限制在2到3个，否则会影响系统的部署、自治性和可扩展性。EventSourcingDesignPattern当应用当前状态发生变化时，如何保证架构能够按需变化，并根据这些变化实时产生相应的事件？EventSourcing模式可以根据每个业务实体的状态变化，依次将新的事件添加到事件列表中。在系统中，Customer等实体会产生很多事件，因此我们可以将实体当前的状态记录为“截图”事件，以供进一步查询或自动调整状态以优化负载。命令查询职责分离（CQRS）对于基于服务的数据库模型，我们很难实现各种复杂的查询效果，因为访问仅限于单个数据库。那么我们如何实现基于数据库系统的各种联合查询呢？CQRS模型将单个应用程序分为命令和查询两部分：命令部分处理创建、更新和删除等各种请求。查询使用通过事件流更新的物化视图。同时，这些事件是由事件溯源模型产生的，标记了数据的各种变化。无缝部署的微服务设计模式我们在实现微服务的时候，难免会遇到调用服务的问题，所以我们可以使用横切（cross-cutting）模式来简化工作。由于在服务发现中使用了容器技术，IP地址往往是动态分配的。这意味着IP地址可能随时更改，从而导致服务中断。此外，用户需要记住每个服务的URL，这会退化为紧耦合。为了解决这个问题，我们需要通过注册表单向用户请求提供位置信息。服务实例可以在启动时注册到表中，也可以在关闭时注销。此方法帮助用户找出可用于查询的确切位置。另外，注册中心可以通过健康检查来保证实例的可用性，从而提高系统性能。蓝绿部署在微服务架构中，一个系统中往往存在多个微服务。如果我们因为部署，或者更新版本而停止所有服务，那么长时间的宕机势必会影响整体的生产力。因此，我们在设计微服务架构时，需要通过蓝绿部署模式来避免这个问题。在这种模式下，我们有两个相同且平行的环境，蓝色和绿色。在任何时间点，只有一个环境（如蓝色系统）实际在线并处理真实的业务流量。然后当需要新的部署时，我们将最新版本的应用上传到绿色系统，将真正的外部路由器切换到绿色系统，完成更新。结论虽然您不一定会在自己的微服务系统中使用上述每种设计模式，但每种模式都有其独特的应用场景。作为架构师，针对不同的微服务架构设计模式，需要从应用设计阶段到生产环境维护阶段不断进行各种评估、审计、测试和实践。相信他们可以提高应用程序的整体可靠性，同时为您带来一致的标准。【原创稿件，合作网站转载请注明原作者和出处为.com】
