九游会j9·(中国)登录入口

微服务可以对您的企业发生努力影响。因此，值得一提的是，如那边理微服务架构（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/@madhukaudantha/microservice-architecture-and-design-patterns-for-microservices-e0e5013fd58a)。

本文来源：j9九游会登录入口-www.hykj360.com