微服务项目能对您的民营企业造成积极主动负面影响。 因而，值得一提，怎样处置微服务项目构架（MSA）和很多微服务项目程序语言。 微服务项目构架的通常最终目标或准则。 这是微服务项目构架方式[1]上要考量的五个最终目标。

· 提高效率：MSA将减少结构设计，实行和保护IT服务项目的整体生产成本。

· 提升正式发布速率：MSA将提升从构想到服务项目布署的速率。

· 进一步增强稳定性：MSA将提升他们服务项目互联网的稳定性。

· 投入采用由此可见性：MSA全力支持可在您的服务项目和互联网上提供更多更快的由此可见性。

您须要介绍微服务项目构架的构筑基本原理

· 扩展性

· 易用性

· 稳定性

· 稳定性

· 自由民主

· 零散环境治理

· 故障隔离

· 手动实用性

· 透过DevOps稳步交货

倾听前述准则，在使您的软件控制系统或控制系统付诸行动的与此同时，增添了很多考验和难题。 这些难题在很多软件控制系统中都很常用。 采用恰当和相匹配的程序语言能消除这些难题。 微服务项目有很多程序语言，能分成六种商业模式。 每一都包涵很多商业模式。 右图表明了这些。

> Design Patterns for Microservices

分解商业模式

按业务能力分解

微服务项目就是要采用单一责任准则使服务项目松散耦合。 它根据业务能力分解。 定义与业务能力相对应的服务项目。 业务能力是来自业务体系结构筑模的概念[2]。 民营企业为了创造价值而要做的事情。 业务能力通常对应于一个业务对象，例如

· 订单管理负责订单

· 客户管理对客户负责

按子域分解

采用业务功能分解应用程序可能是一个不错的开始，但是您会遇到所谓的”神类”，这很难分解。 这些类将在多种服务项目中通用。 定义与域驱动结构设计（DDD）子域相对应的服务项目。 DDD将应用程序的难题空间（业务）称为域。 域由多个子域组成。 每一子域对应于业务的不同部分。

子域能分类如下：

· 核心-业务和应用程序最有价值部分的关键区别

· 全力支持-与业务有关，但与众不同。 这些能在内部实现，也能外包

· 通用-不特定于业务，理想情况下采用现成的软件实行

订单管理的子域包括：

· 产品目录服务项目

· 库存管理服务项目

· 订单管理服务项目

· 送货管理服务项目

按事务分解/两阶段提交（2pc）商业模式

您能透过事务分解服务项目。 然后，控制系统中将有多个事务。 分布式事务处置的重要参与者之一是事务处置协调器[3]。 分布式事务包括两个步骤：

· 准备阶段-在此阶段，事务的所有参与者都准备提交并通知协调员他们已准备好完成事务

· 提交或回滚阶段-在此阶段，事务协调器向所有参与者发出提交或回滚命令

2PC的问题在于，与单个微服务项目的运行时间相比，它相当慢。 即使微服务项目在同一互联网上，它们之间的事务协调也确实会减少控制系统速率，因而这种方式通常在高负载情况下不常用。

扼杀商业模式

在上面的三种商业模式中，您经历的程序语言是分解Greenfield的应用程序，但是您所做的工作中有80％是针对Brownfield应用程序，这是大型的整体应用程序（旧版代码库）。 扼杀者商业模式能解决。 这将创建两个单独的应用程序，它们在同一URI空间中并排运行。 随着时间的推移，新重构的应用程序会”扼杀”或替换原始应用程序，直到最终，您能关闭整体应用程序。 Strangler应用程序步骤能转换，共存和消除[4]：

· 转换-采用现代方式创建并行的新站点。

· 消除-从现有站点中删除旧功能。

隔板商业模式

将应用程序的元素隔离到池中，以便如果其中一个失败，其他应用程序将继续运行。 这种商业模式之所以称为”舱壁”，是因为它类似于船体的分段分区。 根据采用者负载和易用性要求，将服务项目实例划分成不同的组。 此结构设计有助于隔离故障，并允许您即使在故障期间仍可为某些采用者维持服务项目功能。

边车商业模式

将应用程序的组件布署到单独的处置器容器中以提供更多隔离和封装。 这种商业模式还能使应用程序由异构组件和技术组成。 该商业模式被称为Sidecar，因为它类似于连接到摩托车的Sidecar。 在该商业模式中，sidecar附加到父应用程序，并为该应用程序提供更多全力支持功能。 Sidecar还与父应用程序共享相同的生命周期，并与父应用程序一起创建并退出。 Sidecar商业模式有时被称为sidekick商业模式，是他们在文章中表明的最后一个分解商业模式。

整合商业模式

API网关商业模式

当应用程序分解为较小的微服务时，有很多须要解决的难题

· 不同的渠道多次呼吁提供更多多种微服务项目

· 须要处置不同类型的协议

· 不同的消费者可能须要不同的响应格式

API网关有助于解决微服务项目实现引发的很多难题，而不仅限于前述难题。

· API网关是任何微服务项目调用的单一入口点。

· 它能用作将请求路由到相关微服务项目的代理服务项目。

· 它能汇总结果以发送回消费者。

· 该软件控制系统能为每种特定类型的客户端创建一个细粒度的API。

· 它还能转换协议请求并做出响应。

· 它还能减轻微服务项目的身份验证/授权责任。

聚合商业模式

在将业务功能分解为几个较小的逻辑代码段时，有必要考量怎样对每一服务项目返回的数据进行协作。 消费者不能承担这种责任。 聚合器商业模式有助于解决此难题。 它讨论了他们怎样聚合来自不同服务项目的数据，然后将最终响应发送给消费者。 这能透过两种方式来完成[6]：

· 复合微服务项目将调用所有必需的微服务项目，合并数据，并在发送回数据之前对其进行转换。

· API网关还能将请求划分成多个微服务项目，并在将数据发送给采用者之前汇总数据。

如果要应用任何业务逻辑，建议选择复合微服务项目。 否则，API网关是已建立的软件控制系统。

代理商业模式

API网关他们只是透过API网关公开微服务项目。 我允许获得API功能，例如GW中的安全性和API分类。 在此示例中，API网关具有三个API模块：

· 移动API，为FTGO移动客户端实现API

· 浏览器API，它实现了浏览器中运行的JavaScript应用程序的API

· 公共API，为第三方开发人员实现API

网关路由商业模式

API网关负责请求路由。 API网关透过将请求路由到相应的服务项目来实现很多API操作。 当API网关接收到请求时，它会查询路由映射，该路由映射指定将请求路由到的服务项目。 路由映射例如能将HTTP方式和路径映射到服务项目的HTTP URL。 此功能与Web服务项目器（如NGINX）提供更多的反向代理功能相同。

链式微服务项目商业模式

单个服务或微服务项目将有多个依赖关系，例如：销售微服务项目具有依赖产品微服务项目和订单微服务项目。 链接微服务项目程序语言将帮助您根据请求提供更多合并结果。 微服务项目1接收到的请求，该服务项目随后与微服务项目2进行通信，并且可能正在与微服务项目3进行通信。 所有这些服务项目都是同步调用。

分支商业模式

的微服务项目能是微服务项目链。 Brach商业模式还可用于根据您的业务需求调用不同的微服务项目链或单个链。

客户端UI组合商业模式

当透过分解业务功能/子域来开发服务项目时，负责用户体验的服务项目必须从多个微服务项目中提取数据。 在单片世界中，从UI到后端服务项目只有一次调用，以检索所有数据并刷新/提交UI页面。 但是，现在不一样了。 对于微服务项目，必须将UI结构设计为具有屏幕/页面的多个部分/区域的框架。 每一部分都将调用单个后端微服务项目以提取数据。 诸如AngularJS和ReactJS之类的框架能轻松地做到这一点。 这些屏幕称为单页应用程序（SPA）。 每一团队都开发一个客户端UI组件，例如AngularJS指令，该组件实现其服务项目的页面/屏幕区域。 UI团队负责透过构成多个服务项目特定的UI组件来实现构筑页面/屏幕的页面框架。

数据库商业模式

为微服务项目定义数据库构架时，他们须要考量以下几点。

· 服务项目必须是松散耦合的。 它们能独立开发，部署和扩展。

· 商业交易可能会强制跨越多个服务项目的不变量。

· 很多业务交易须要查询多个服务项目拥有的数据。

· 有时必须复制和共享数据库才能进行扩展。

· 不同的服务项目有不同的数据存储要求。

每一服务项目的数据库

为介绍决前述难题，必须为每一微服务项目结构设计一个数据库。 它必须仅对该服务项目专用。 只能由微服务项目API访问它。 其他服务项目无法直接访问它。 例如，对于关系数据库，他们能采用每一服务项目专用表，每一服务项目构架或每一服务项目数据库服务项目器。

每一服务项目共享数据库

他们已经讨论了每一服务项目一个数据库是微服务项目的理想选择。 它是微服务项目的反商业模式。 但是，如果应用程序是一个整体并且试图闯入微服务项目，那么非规范化就不那么容易了。 在后面的阶段中，他们能转到每一服务项目商业模式的数据库，直到他们遵循此商业模式。每一服务项目的共享数据库并不理想，但这是前述情况的可行软件控制系统。 多数人认为这是微服务项目的反商业模式，但对于棕地应用程序，这是将应用程序分解成较小逻辑部分的一个很好的开始。 这不应应用于未开发的应用程序。

命令查询责任隔离（CQRS）

一旦他们实现了每一服务项目的数据库，就须要查询，这须要来自多个服务项目的联合数据。 这是不可能的。 CQRS建议将应用程序分成两部分-命令端和查询端。

· 命令行处置创建，更新和删除请求

· 查询端透过采用实例化视图来处置查询部分

通常将事件源商业模式与它一起采用来为任何数据更改创建事件。 透过订阅事件流，能使物化视图保持更新。

活动采购

大多数应用程序都采用数据，典型的方式是使应用程序保持当前状态。 例如，在传统的创建，读取，更新和删除（CRUD）模型中，典型的数据处置是从存储中读取数据。 它包涵经常采用事务锁定数据的限制。

Event Sourcing商业模式[8]定义了一种方式，用于处置由一系列事件驱动的数据上的操作，每一事件都记录在仅追加存储中。 应用程序代码向事件存储发送一系列事件，这些事件命令性地描述了对数据执行的每一操作，并在事件存储中保留了这些事件。 每一事件代表一组数据更改（例如，AddedItemToOrder）。

这些事件将保留在充当记录控制系统的事件存储中。 事件存储正式发布的事件的典型用途是在应用程序中的动作更改实体时保护实体的实体化视图，以及与外部控制系统集成。 例如，控制系统能保护用于填充UI部分的所有客户订单的实例化视图。 当应用程序添加新订单，添加或删除订单上的项目以及添加运输信息时，能处置描述这些更改的事件并将其用于更新实例化视图。 该图表明了该商业模式的概述。

> Event Sourcing pattern[8]

传奇商业模式

当每一服务项目都有自己的数据库并且一个业务事务跨越多个服务项目时，他们怎样确保各个服务项目之间的数据一致性。 每一请求都有一个补偿请求，该请求将在请求失败时执行。 它能透过两种方式实现：

· 编排-在没有中央协调的情况下，每一服务项目都会生成并侦听另一个服务项目的事件，并决定是否应该采取措施。 编排是指定两个或两个以上参与者的方式。 任何一方都无法控制对方的流程，或者对这些流程的任何由此可见性，都无法协调他们的活动和流程以共享信息和价值。 当须要跨控制/由此可见性域进行协调时，请采用编排。 您能在简单的情况下将编排视为互联网协议。 它规定了各方之间可接受的请求和响应商业模式。

> Saga pattern — Choreography

· 编排-编排（对象）负责传奇的决策和业务逻辑排序。 当您控制流程中的所有参与者时。 当它们全部处于一个控制范围内时，您能控制活动的流程。 当然，这通常是当您指定将在您拥有控制权的一个组织内制定的业务流程时。

> Sage pattern — Orchestration

可观察性商业模式

日志汇总

考量一个应用程序包涵多个服务项目的用例。 请求通常跨越多个服务项目实例。 每一服务项目实例均以标准化格式生成日志文件。 他们须要一个集中式日志记录服务项目，该服务项目能汇总每一服务项目实例的日志。 用户能搜索和分析日志。 他们能实用性在某些消息出现在日志中时触发的警报。 例如，PCF确实有Log Aggregator，它从PCF平台的每一组件（路由器，控制器，diego等）收集日志，并附带应用程序。 AWS Cloud Watch也这样做。

性能指标

当服务项目组合由于微服务项目体系结构而增加时，密切注意事务，以便能监控商业模式并在发生难题时发送警报就变得至关重要。

须要度量服务项目来收集有关单个操作的统计信息。 它应该聚合提供更多报告和警报的应用程序服务项目的指标。 有两种用于汇总指标的模型：

· 推送-服务项目将指标推送到指标服务项目，例如 NewRelic，AppDynamics

· 提取-指标服务项目从服务项目中提取指标，例如 普罗米修斯

分布式跟踪

在微服务项目构架中，请求通常跨越多个服务项目。 每一服务项目透过跨多个服务项目执行一个或多个操作来处置请求。 在进行故障排除时，值得拥有跟踪ID，但他们会端对端跟踪请求。

软件控制系统是引入一个事务ID。 能采用跟随方式；

· 为每一外部请求分配一个唯一的外部请求ID。

· 将外部请求ID传递给所有服务项目。

· 在所有日志消息中包括外部请求ID。

健康检查

实行微服务项目构架后，服务项目可能会启动但无法处置事务。 每一服务项目都须要具有一个可用于检查应用程序运行状况的终结点，例如/ health。 该API应该o检查主机的状态，与其他服务项目/基础结构的连接以及任何特定的逻辑。

外部实用性

服务项目通常还会调用其他服务项目和数据库。 对于开发，质量检查，UAT，产品等每一环境，端点URL或某些实用性属性可能会有所不同。 这些属性中的任何一项更改都可能须要重新构筑和重新布署服务项目。

为了避免代码修改，能采用实用性。 外部化所有实用性，包括端点URL和凭据。 应用程序应该在启动时或运行时加载它们。 这些能在启动时由应用程序访问，也能在不重新启动服务项目器的情况下进行刷新。

服务项目发现商业模式

当微服务项目出现时，他们须要在调用服务项目方面解决很多难题。

采用容器技术，IP地址能动态分配给服务项目实例。 每次地址更改时，消费者服务项目都会中断，须要手动更改。

消费者必须记住每一服务项目URL，并使其紧密耦合。

须要创建服务项目注册表，该注册表将保留每一生产者服务项目的元数据和每个规范的规范。 服务项目实例在启动时应注册到注册表，而在关闭时应注销。 服务项目发现有两种类型：

· 客户端：例如：Netflix Eureka

· 服务项目器端：例如：AWS ALB。

> service discovery [9]

断路器商业模式

一个服务项目通常会调用其他服务项目来检索数据，并且下游服务项目可能会关闭。 这样做有两个难题：首先，请求将继续进入服务项目中断状态，耗尽互联网资源，并减少性能。 其次，用户体验将是糟糕且不可预测的。

消费者应透过代理来调用远程服务项目，该代理的行为与断路器相似。 当连续的故障数超过阈值时，断路器将跳闸，并且在超时期间内，所有调用远程服务项目的尝试都将立即失败。 超时到期后，断路器将允许有限数量的测试请求透过。 如果这些请求成功，则断路器将恢复正常操作。 否则，如果发生故障，则超时时间将再次开始。 如果此操作很有可能失败，则此商业模式适用于防止应用程序尝试调用远程服务项目或访问共享资源。

> Circuit Breaker Pattern [10]

蓝绿色布署商业模式

采用微服务项目构架，一个应用程序能具有很多微服务项目。 如果他们停止所有服务项目，然后布署进一步增强版本，则停机时间将是巨大的，并可能负面影响业务。 同样，回滚将是一场噩梦。 蓝绿色布署商业模式可避免这种情况。

能实行蓝绿色布署策略以减少或消除停机时间。 它透过运行两个相同的生产环境Blue和Green来实现这一最终目标。 假设绿色是现有的活动实例，蓝色是该应用程序的新版本。 在任何时候，只有一个环境处于活动状态，该活动环境为所有生产流量提供更多服务项目。 所有云平台均提供更多用于实行蓝绿色布署的选项。

> Blue-Green Deployment Pattern

参考文献[1]”微服务项目体系结构：准则，实践和文化的统一”，作者Irakli Nadareishvili，Matt McLarty和Michael Amundsen

[2] https://microservices.io/patterns/decomposition/decompose-by-business-capability.html

[3] https://www.baeldung.com/transactions-across-microservices

[4] https://developer.ibm.com/articles/cl-strangler-application-pattern-microservices-apps-trs/

[5] https://docs.microsoft.com/zh-CN/azure/architecture/patterns/bulkhead

[6] https://dzone.com/articles/design-patterns-for-microservices

[7] https://docs.microsoft.com/zh-CN/azure/architecture/patterns/cqrs#event-sourcing-and-cqrs

[8] https://docs.microsoft.com/zh-CN/azure/architecture/patterns/event-sourcing

[9] https://www.dineshonjava.com/microservices-with-spring-boot/

[10] https://docs.microsoft.com/zh-CN/azure/architecture/patterns/circuit-breaker

(本文翻译自madhuka udantha的文章《Microservice Architecture and Design Patterns for Microservices》，参考：https://medium.com/@