可视化微服务：设计微服务系统
Visualizing Microservices: Designing a Microservice System
原文作者：Matt McLarty
原文地址：https://dzone.com/articles/visualizing-microservices-designing-a-microservice
译者微博：@从流域到海域
译者博客：blog.csdn.net/solo95
可视化微服务：设计微服务系统
这是关于可视化微服务的三部分博客系列的第二部分。点击这里查阅第一部分。
最近我一直在与许多大型组织机构合作，帮助他们理解并实现Web API和微服务体系结构的价值。在这项工作中，我看到这些组织或机构一直在努力确定如何定义它们的微服务之间的最佳边界。在这个行业中，这是一个已知的问题，但一直没有解决。虽然关于凝聚式(粘性)服务的价值和边界上下文的力量已经写了很多(文章)，但似乎没有(文章)指导我们如何去实际识别这些内容。
这个问题的一个原因是试图去确定服务边界的人是技术人员，他们天生就在寻找技术性的解决方案，但是我们需要定义的是具备结合性的和与能力对等的服务边界而不是该领域的专业知识。从根本上说，这应该是一种建模练习，它独立于表面下实现的任何技术。然而，即使那些有意识地采用了技术无关的建模方法的组织也一直在努力定义服务边界。
发生这种情况的部分原因是，最流行的软件建模方法往往存在实现偏差(implementation bias)。例如，领域驱动设计(domain-driven design)(DDD)倾向于面向对象的编程，而UML本身具备数据建模的观点。除此之外，业界还没有就如何直观地描绘微服务系统模型达成共识 - 应该描述哪些组件，应该如何表示关系，应该使用什么术语 - 更不用说该领域中的任何工具。
不过，所有的希望都不会就此消失。DDD的一些概念 - 最明显的是“有界上下文”的概念 - 已经得到了普及，并启动了关于服务边界定义的行业对话。重要的是，DDD方法论中有更高层次的抽象 - 域，子域，有界上下文，聚合，上下文映射 - 都是技术不可知(也称不透明，即黑盒，译者注)和以模型为中心的。
既然被接受的理解系统的方法是关注它的组件之间的关系，那么如果我们想要一个微服务系统的基本表示，我们就不需要比上下文映射更深入。因此，也许我们可以使用DDD上下文映射作为可视化表示微服务系统的起点。
即使在上下文映射层面，大型组织或机构的完整的服务系统也是不可理解的。因此，为了使上下文映射有用，为上下文映射本身也设置上下文非常重要。这种上下文可以是特定整体应用程序的拆分或特定计划的活动的交互。连贯地构建一个大型组织或机构的微服务系统的唯一方法就是逐条地，上下文地进行。在进行过程中，这些上下文可以合并成一个完整展示项目的图片，如果你需要这样的一张图片的话。
微服务上下文映射：一个例子
我们来看看这种方法在实际中的一个例子。考虑一家大型零售银行希望引入以客户为中心的服务，以实现客户保留的战略目标。它希望提供一种新的以客户为中心的支付解决方案，该解决方案将允许客户根据他们与银行的关系（他们的账户，投资，资产，交互模式）进行购买，而不是将授权决策基于一个特定帐户(来进行)。
零售银行业务本身就是一个复杂的业务领域。客户，产品和服务渠道（分支机构，网上银行，销售点）等实体之间存在相互关系，而且存在与财务透明度和数据隐私相关的强制性规定。因此，尽管这种新的支付服务背后的想法很直观，但它其实呈现了一个复杂的问题空间。你从哪里开始？
继DDD方法松散化之后，我们可以首先将零售银行业务领域划分为子域。作为一个起点 - 并遵循康威法则(Conway's Law)的必然性 - 我们可以从组成零售银行的组织单位开始，并与以客户为中心的支付解决方案进行关联。这些是：
自助银行
支持自助银行渠道（如移动，网络，ATM和销售点）的应用程序将需要建立和执行以客户为中心的支付的应用程序。
客户和卡片管理
支持客户信息，客户认证和基于卡的授权申请与新的支付服务最为接近的应用程序。
存款账户
支持存款账户的记录和发放系统（审核，储蓄）授权和实现以客户为中心的付款所需的信息的系统。
零售贷款和信贷
支持贷款产品（例如个人信用额度）和信用卡的记录和发放系统并包含授权和实现以客户为中心的付款所需的信息的系统。
抵押贷款
支持记录和抵押来源的系统，它包含可帮助以客户为中心的支付解决方案进行授权决策的信息。
投资银行
尽管不是零售银行业务的一部分，但客户在银行的投资将在未来用于以客户为中心的支付方式的解决方案。
这些子域可以通过以下方式进行可视化描述：
这给了我们一个起点，以考虑如何对创建以客户为中心的支付解决方案所需的服务进行分类。自助银行和客户以及卡片管理子域名被突出显示，因为它们已被确定为解决方案的关键子域名。使用DDD的“语言边界”概念，显然会有一些有界的上下文出现在子域中。
在自助银行内部，有两种截然不同的有界上下文。网上银行渠道与手机银行渠道共用一种语言，因为它们都提供高度亲切的客户体验，而支持移动渠道的应用程序则由Web渠道构建并共享组件。我们将这种情况称为网上银行。另一方面，销售点具有独特的语言，更多地集中在设备管理和商家关系上。我们将称之为销售点上下文。
客户与卡片管理甚至会更加分散。核心的客户信息 - 包括银行客户的权威列表，他们的联系信息以及他们的产品库 - 形成了一个独特的词汇表，我们将其称为客户信息有界上下文。另一种不同的语言被用来描述卡的功能，这主要与支付活动有关。这是“消费者付款和交易”的环境。最后，还有一个客户身份上下文专注于客户安全和权限控制。
产品子域名对于该付款解决方案并不重要，但值得注意的是，零售贷款和贷款子域被划分为单独的PLC账户上下文和信用卡上下文。完整的相关有界上下文集如下所示：
在确定了有界上下文之后，我们现在可以考虑其中哪些服务和消费者服务在其中发挥作用。如前所述，网上银行有两种消费者服务：网银网上应用程序和手机银行应用程序。新的付款解决方案也会被销售点环境中通过POS网络收到的消息请求处理掉。
客户身份上下文必须提供客户身份验证服务，以确保只有合适的请求者才能访问新的付款服务。客户信息上下文包含客户和产品持有者之间的交叉参照，因此需要由“核心客户信息服务”来为新的支付解决方案提供这些数据。
除此之外，跟踪客户的财务活动 - 即与其产品持有相关的财务事件 - 对授权决策是有用的。因此，客户活动分析服务可以在客户信息上下文中创建。
消费者支付和交易上下文是为新的以客户为中心的支付解决方案而建立核心服务的场所。首先，客户需要注册新产品并设置其帐户和产品偏好。为此，引入了以客户为中心的支付管理服务。
对于非功能性原因（例如性能，安全性和可用性），我们将创建一个单独的授权付款服务，称为以客户为中心的付款授权服务。最后，由于向客户帐户发布交易可以晚于授权决定发布的时间，因此我们将创建与授权服务分离的交易过帐服务。
对于产品子域，我们只会在每个有界的上下文中引用单个同名服务。例如，存款账户上下文只包含一个存款账户服务。整个服务系统现在看起来像下面这样：
这个设计过程的最后一步是为将发生在服务之间的交互添加注释。事实上，人们可能想要模拟有界上下文之间的相互作用，以便梳理出单个服务，但为了叠加视觉效果，我们将在最后描述这一步骤。在这个阶段举例说明所有可能的交互会造成视觉上的混淆，因此我们只会关注一些能够帮助我们理解系统如何运作的关键信息。这里有些例子：
- 客户使用网银网络应用程序通过以客户为中心的支付管理服务注册并设置新的支付解决方案偏好。
- 以客户为中心的支付管理服务从客户信息服务中检索该客户的产品组合。
- 客户活动分析服务使用来自产品系统的信息构建出客户财务状况。
- 客户通过移动银行应用程序(即手机上的App)执行以客户为中心的支付，该应用程序称为以客户为中心的支付授权服务。
- 以客户为中心的支付授权服务反过来使用来自以客户为中心的支付管理服务和客户活动分析服务的信息构建授权配置文件。
- 一旦获得授权，支付将被转交给交易过账服务完成，然后调用相应的产品服务。
关于这个微服务系统有几点需要注意。首先，不要假定在为终端用户活动提供服务时，这些交互中的每一个都会实时发生。例如，尽管以客户为中心的授权服务需要来自其他一些服务的信息，但可以使用基于事件的方法结合缓存来确保其处理过程是独立的，以便对客户的授权请求提供实时服务。
其次，可以在有界上下文之间建立反腐败层（an anti-corruption layer，ACL），以提供松散的语义耦合。最后，你会注意到，虽然这是一个相当复杂的图片，但没有实现细节。换句话说，这种模式可以使用许多不同的技术来实现，包括语言，主机环境和网络协议。
最终的上下文映射（包括交互）如下所示：
最终，此系统设计过程的目的是帮助对如何在复杂的解决方案中定义微服务的服务边界进行最佳猜想。希望这里描述的方法既能为服务建立一个良好的初始模型，又能更容易地重新绘制出服务边界。
整个微服务设计过程的下一步将是更深入地了解各项服务。这将在本系列的第三部分中进行探讨。敬请关注！