微服务架构10个最关键的设计形式
自从软件开发的早期(1960年代)以来，处置大型软件系统中的复杂性不时是一项艰难的义务。多年来，软件工程师和架构师为处置软件系统的复杂性启动了许多尝试：DavidParnas的模块化和信息暗藏(1972)，Edsger W. Dijkstra的关注分别(1974)，面向服务的体系结构(1998)。
他们一切人都经常使用了久经考验的成熟技术来处置大型系统的复杂性：分而治之。自2010年代以来，这些技术无余以处置Web规模运行程序或现代大型企业运行程序的复杂性。结果，架构师和工程师开发了一种新方法来处置现代软件系统的复杂性：微服务架构。它也经常使用了相反的旧"分而治之"技术，虽然驳回了陈腐的方式。
软件设计形式是处置软件设计中经常出现疑问的通用，可重用的处置打算。设计形式可协助咱们共享通用词汇，并经常使用经过实战测验的处置打算，而不是从新发明轮子。在文章：有效的微服务：10个最佳通常中，我形容了开发有效的微服务的一组最佳通常。在这里，我将形容一组设计形式，以协助您成功这些最佳通常。假设您是微服务架构的新手，那么不用担忧，我将向您引见微服务架构。
经过浏览本文，您将学到：
请留意，此清单的大少数设计形式都有几种高低文，可以在非微服务体系结构中经常使用。然而我将在微服务架构的背景下对其启动形容。
微服务架构
在之前的博客文章中，我曾经具体引见了微服务体系结构：微服务体系结构：简明概述以及为什么要在下一个名目中经常使用它以及模块化单片软件体系结构真的死了吗?假设您有兴味，可以浏览它们以更深化地了解它们。
什么是微服务架构。微服务架构有很多定义。这是我的定义：
微服务架构旨在将大型，复杂的系统垂直(按性能或业务要求)划分为较小的子系统，这些子系统属于流程(因此可独立部署)，并且这些子系统之间经过与言语有关的轻量级网络通讯相互通讯(例如REST，gRPC)或异步(经过信息传递)方式。
这是具备微服务架构的业务Web运行程序的组件视图：
> Microservice Architecture by Md Kamaruzzaman
微服务架构的关键特色：
微服务架构的优势：
微服务架构的缺陷：
何时经常使用微服务架构：
微服务架构的设计形式
每个微服务独占数据库
一旦公司用许多较小的微服务交流了大型的单片系统，它面临的最关键的选择就是关于数据库。在全体架构中，经常使用大型中央数据库。许多架构师都青睐保管数据库原样，即使他们转向微服务架构也是如此。虽然它提供了一些短期好处，但它是一种反形式，尤其是在大规模系统中，由于微服务将严密耦合在数据库层中。转向微服务的整个指标将失败(例如，团队授权，独立开发)。
更好的方法是为每个微服务都提供自己的数据存储，以使数据库层中的服务之间不存在强耦合。在这里，我经常使用数据库一词来示意数据的逻辑分别，即微服务可以共享同一物理数据库，然而它们应该经常使用独自的架构/汇合/表。它还将确保依据域驱动设计正确隔离微服务。
> Event Sourcing by Md Kamaruzzaman
优势：
缺陷：
启用技术示例：
命令查问职责隔离(CQRS)
假设咱们经常使用事情源，那么从事情存储中读取数据将变得充溢应战。要从数据存储中失掉实体，咱们须要处置一实际体事情。另外，有时咱们对读写操作有不同的分歧性和吞吐量要求。
在这种用例中，咱们可以经常使用CQRS形式。在CQRS形式中，系统的数据修正部分(命令)与数据读取(查问)部分分开。CQRS形式有两种方式：便捷和初级，这造成软件工程师之间发生一些混杂。
以便捷的方式，不同的实体或ORM模型用于读取和写入，如下所示：
> CQRS (simple) by Md Kamaruzzaman
它有助于实施"繁多责任准则"和"关注点分别"，从而使设计更繁复。
> CQRS (advanced) by Md Kamaruzzaman
关于重读运行程序或微服务体系结构，将OLTP数据库(任何提供ACID事务保障的SQL或NoSQL数据库)或散布式信息平台用作写存储。关于惨重的写程序(高写可伸缩性和吞吐量)，经常使用了水平可写伸缩的数据库(公共云全局数据库)。规范化的数据保管在写入数据存储中。
为搜查(例如ApacheSolr，Elasticsearch)或读取(键值数据存储，文档数据存储)而提升的NoSQL数据库用作读取存储。在许多状况下，在须要SQL查问的中央经常使用可伸缩的SQL数据库。归一化和提升的数据将保管在读取存储中。
数据从写入存储异步复制到读取存储。结果，读存储区滞后于写存储区，并且最终坚持分歧。
优势：
缺陷：
何时经常使用CQRS：
何时不经常使用CQRS：
启用技术示例：
假设您将微服务体系结构与每个微服务的数据库一同经常使用，那么经过散布式事务治理分歧性就具备应战性。您不能经常使用传统的两阶段提交协定，由于它无法裁减(SQL数据库)或不被支持(许多NoSQL数据库)。
您可以将Saga形式用于MicroserviceArchitecture中的散布式事务。Saga是一种旧形式，于1987年开发，作为SQL数据库中常年运转的数据库事务的概念代替打算。然而，这种形式的现代变体关于散布式事务也十分有效。Saga形式是一个本地事务序列，其中每个事务在单个微服务中更新数据存储中的数据并颁布事情或信息。传奇中的第一个事务由外部恳求(事情或操作)启动。一旦本地事务成功(数据存储在数据存储中，并且颁布信息或事情)，颁布的信息/事情将触发Saga中的下一个本地事务。
> Saga by Md Kamaruzzaman
假设本地事务失败，则Saga口头一系列补救事务，以吊销先前本地事务的更改。
Saga买卖协调关键有两种变体：
优势：
缺陷：
何时经常使用佐贺：
什么时刻不经常使用佐贺：
启用技术示例：
前端的后端(BFF)
在现代业务运行程序开发中，尤其是在微服务体系结构中，前端和后端运行程序是分别的和独立的服务。它们经过API或GraphQL衔接。假设运行程序还具备MobileApp客户端，则对Web和Mobile客户端经常使用相反的后端微服务将成为疑问。移动客户端的API要求通常与Web客户端不同，由于它们具备不同的屏幕大小，显示，性能，动力和网络带宽。
后端的后端形式可用于每个UI都有为特定UI定制的独自后端的场景。它还提供了其余优势，例如充任下游微服务的外观，从而缩小了UI与下游微服务之间的闲谈通讯。雷同，在高度安保的状况下，下游微服务部署在DMZ网络中，BFF用于提供更高的安保性。
> Backends for Frontends by Md Kamaruzzaman
优势：
缺陷：
何时将后端用于前端：
何时不经常使用后端作为前端：
启用技术示例：
API网关
在微服务架构中，UI通常与多个微服务衔接。假设微服务是细粒度的(FaaS)，则客户端或许须要衔接许多微服务，这变得很繁琐且具备应战性。而且，服务(包括其API)可以开展。大型企业还宿愿领有其余跨畛域的疑问(SSL中断，身份验证，授权，限度，日志记载等)。
处置这些疑问的一种或许方法是经常使用API网关。API网关位于客户端APP和后端微服务之间，并充任外观。它可以用作反向代理，将客户端恳求路由到适当的后端微服务。它还可以支持将客户端恳求的扇出裁减到多个微服务，而后将汇总的照应前往给客户端。它还支持基本的跨畛域关注。
> API Gateway by Md Kamaruzzaman
优势：
缺陷：
何时经常使用API网关：
何时不经常使用API网关：
启用技术示例：
扼杀者
假设要在棕地名目中经常使用微服务架构，则须要将旧版或现有的Monolithic运行程序迁徙到微服务。将现有的大型消费单片式运行程序迁徙到微服务中具备很大的应战性，由于这或许会破坏运行程序的可用性。
一种处置打算是经常使用Strangler形式。Strangler形式象征着经过逐渐用新的微服务交流特定性能，将Monolithic运行程序逐渐迁徙到微服务架构。此外，新性能仅在微服务中参与，绕过了传统的Monolithic运行程序。而后将Facade(API网关)性能为在旧版Monolith和微服务之间路由恳求。一旦性能从Monolith迁徙到微服务，Facade就会阻拦客户端恳求并路由到新的微服务。一旦一切旧版Monolithic性能都已迁徙，旧版Monolithic运行程序将被"勒死"，即退役。
> Strangler by Md Kamaruzzaman
优势：
缺陷：
何时经常使用Strangler：
何时不经常使用Strangler：
推进技术：
断路器
在微服务体系结构中，微服务启动同步通讯，微服务通常调用其余服务来满足业务需求。由于瞬态缺点(网络衔接速度慢，超时或期间无法用)，对另一个服务的调用或许会失败。在这种状况下，重试呼叫可以处置此疑问。然而，假设存在重大疑问(微服务齐全失败)，则微服务将常年间无法用。在这种状况下，重试是没无心义的，并且糜费了贵重的资源(线程被阻塞，糜费了CPU周期)。雷同，一项服务的缺点或许会造成整个运行程序级联缺点。在这种状况下，立刻失败是一种更好的方法。
关于此类用例，可以经常使用断路器形式。微服务应经过代理来恳求另一个微服务，该代理的上班方式相似于断路器。代理当该计算最近出现的缺点数，并经常使用它来选择是准许操作继续启动还是间接前往异常。
> Circuit Breaker by Md Kamaruzzaman
优势：
缺陷：
何时经常使用断路器：
何时不经常使用断路器：
推进技术：
外部化性能
每个业务运行程序都有许多用于各种基础结构的性能参数(例如，数据库，网络，衔接的服务地址，凭据，证书门路)。雷同，在企业环境中，运行程序通常部署在各种运转时中(本地，开发，消费)。成功此指标的一种方法是经过外部性能，这是一种致命的不良做法。由于很容易破坏消费凭据，因此或许造成重大的安保危险。另外，性能参数的任何更改都须要重建运行程序。在微服务架构中，这一点尤为关键，由于咱们或许领有数百种服务。
更好的方法是外部化一切性能。结果，将构建环节与运转时环境分开。此外，由于消费性能文件仅在运转时或经过环境变量经常使用，因此将安保危险降到最低。
优势：
缺陷：
何时经常使用外部化性能：
何时不经常使用外部化性能：
推进技术：简直一切企业级的现代框架都支持外部化性能。
消费者驱动的合同测试
在微服务架构中，通常由独立的团队开发许多微服务。这些微服务一同上班来满足业务需求(例如，客户恳求)，并且彼此同步或异步地通讯。消费者微服务的集成测试具备应战性。通常，在这种状况下经常使用TestDouble可以启动更快，更廉价的测试。然而TestDouble通常并不代表真正的提供程序微服务。另外，假设提供者微服务更改了其API或信息，则TestDouble无法确认这一点。另一个选用是启动端到端测试。虽然在消费之前必定启动端到端测试，但它软弱，缓慢，低廉，并且不能代替集成测试(测试金字塔)。
消费者驱动的合同测试可以在这方面为咱们提供协助。此处，消费者微服务一切者团队编写了一个测试套件，其中蕴含针对特定提供者微服务的恳求和预期照应(用于同步通讯)或预期信息(用于异步通讯)。这些测试套件称为显式合同。关于提供商微服务，其经常使用者的一切合同测试套件都参与到了智能测试中。在口头针对特定提供程序微服务的智能测试时，它将运转自己的测试，合同并验证合同。经过这种方式，合同测试可以协助以智能化的方式保养微服务通讯的完整性。
优势：
缺陷：
何时经常使用消费者驱动的合同测试：
何时不经常使用消费者主导的合同测试：
推进技术：
论断
在现代的大型企业软件开发中，微服务体系结构可以协助裁减规模并带来许多常年利益。然而微服务架构并不是可以在每个用例中经常使用的"银弹"。假设在失误的运行程序类型中经常使用它，则微服务架构会带来更多的费事。想要驳回微服务体系结构的开发团队应遵照一组最佳通常，并经常使用一组可重复经常使用的，经过严厉通常的设计形式。
微服务架构中最关键的设计形式是每个微服务的数据库。实施此设计形式具备应战性，并且须要其余几个严密相关的设计形式(事情源，CQRS和Saga)。在具备多个客户端(Web，移动，台式机，智能设施)的典型业务运行程序中，客户端与微服务之间的通讯或许会比拟凌乱，或许须要具备附加安保性的中央控制。在这种状况下，前端的设计形式和API网关十分有用。雷同，断路器形式可以极大地协助处置此类运行程序中的失误状况。将旧的Monolithic运行程序迁徙到微服务中具备很大的应战性，而Strangler形式可以协助迁徙。消费者驱动的合同测试是微服务集成测试的工具形式。同时，外部化性能是任何现代运行程序开发中的强迫性形式。
该列表并不片面，并且取决于您的用例，您或许须要其余设计形式。然而此列表将为您提供有关微服务体系结构设计形式的杰出引见。
