组织微服务

微服务可能是我的开发伙伴朋友中最受欢迎的热门话题之一，我确实喜欢灵活，敏捷以及拥有更多选择的概念。但作为一名在软件集成领域工作多年的人，我开始看到一些类似于以前ESB的东西。

从一万英尺的高空看问题：十年前，我们不得不提出一种更好的方法来组织系统之间的复杂连接，并停止在相同的业务逻辑上重复工作。那时，面向服务的体系结构(SOA)开始流行起来。通过模块化服务，在其他系统中共享服务，组织通信方式，数据路由。ESB是其中的一个实现，可能并不一定要知道如何实现的。

我非常幸运地参与了许多这样的集成项目，并亲自领导了一些项目。我们与各种中间件供应商合作，当时的解决方案都是关于ESB的。通过将系统之间复杂的互连逻辑移除到ESB中，可以在团队之间（与应用程序/服务领导者）协商数据模型，为Web服务设置WSDL合约，并在调用之间添加BPEL流程（如果需要的话）。而且我自己也看到了相当一部分ESB——在ESB之外，一切似乎都非常有条理。但是打开ESB“盒子”，你会发现其中许多结果是由于更糟的混乱代码（或图表，取决于你的工具），而这个巨大的混乱局面则成为企业变革的瓶颈。

（请注意：这是我开始介绍轻量级ESB概念，以及我如何介绍Camel、Karaf和servicemix的原因，因为它解决了我将集成代码独立打包，将ESB box分解为更小的发行版等问题）当独立部署微服务的想法出现时，这个巨大的单片怪物想到了一个智能管道，它试图做太多的事情，比如数据模型定义，流程流，互连协议和数据格式转换，以及服务等待被事件激活的愚蠢端点，这些很快被开发人员抛诸脑后。各项服务之间的关系仍然十分混乱，整体的特性使得发展周期漫长而繁琐。微服务允许开发人员变得更敏捷，他们需要那些“集成”。这和我曾经试图解决的问题很相似。

我们仍然需要与微服务之外的其他服务（系统/应用程序）进行交互。所以，从过去学习，以下是我们知道不该做的事情：

• 没有更大的单片捆绑应用程序来加速开发周期。
• 停止在系统集成代码中执行复杂的业务流程。
• 数据模型不应该在集成层中定义，它只会导致团队之间的额外协商。
• 不应该将状态保留在集成层中，以实现最大的可扩展性
• 在服务之间创建固定的复杂契约。

而且，我们仍然喜欢旧的“整合”方式：

• 有组织的、可视化的、相互关联的系统视图。
• 已经为集成应用程序（如聚合，分离和数据规范化）定义的模式。
• 一个基于事件的方法。一种更灵活和更少耦合的方式来集成系统。

这就是为什么我想出了微服务的分层架构。我希望在现代集成/应用程序开发的新集成架构中实现的主要目标是灵活性。不仅以可扩展的方式，而且还允许开发人员轻松地进行任何架构更改。首先，在新的现代敏捷集成中，集成代码本身应该被分类到不同的小型服务中，这些小型服务在商业世界中是有意义的，并且是分离的，并且是独立部署的微服务单元。然后我们可以开始将真正的CI / CD应用到集成代码。这将避免成为一个庞大的单片ESB。

为了给我的微服务带来一些逻辑意义，并避免重复在单个集成包中承担过多的错误，我为我的微服务定义了四个层，因此每个层都有自己的职责，从而更容易适应变化。

• 网关层：提供简单的网关路由功能，如版本控制和处理不同平台的设备。

本来，我想把这个层分成两层，但决定不这样做是因为现在网关模式变得如此流行。人们有这样的感觉，即网关应该达到某种能力（这是另一个故事，我以后再谈）。这就是为什么我在图中有两种不同形式的网关 ——一种代表绿色，另一种代表蓝色。

这都是关于关注点的分离。这一层是关于将外部API消耗所需的内容整合在一起的。当不同的应用程序域试图相互集成并路由到正确的服务版本时，就会出现这种情况。显然，主要的问题是：

• 访问策略规则，端点版本控制（API）。
• 设置流量限制，应用限制和策略。
• API的安全性。
• 路由到正确的版本。
• 将结果合并，转换并返回给客户端。
• 普通开发者是这里的主要创造者，他们利用每个微服务团队提供的功能为外部客户提供有意义的服务。
• 收集、拆分或规范化一个规范化数据格式给外部用户。
• 根据客户端转换数据输出。
• 应用程序域之间的路由
• 复合层：处理多个微服务组合的重要中间层。它们通过处理内容数据和聚合/拆分数据执行更复杂的路由，并通过触发事件或简单地传递事件来将拆分/聚合结果填充到其他微服务。这一层将微服务的复杂性隐藏在客户端之外。

该层可能是负责以前大部分集成逻辑的层，它负责执行

• 撰写微服务。
  • 通过调用微服务提供的API，根据需要在它们之间转换数据，并根据数据的内容将数据路由到相应的微服务。
• 触发域内的事件
  • 我坚信，事件库在分离每个服务之间的粘性方面做得最好，并且由于其异步性，允许性能达到最佳状态。这里的事件总线不必是消息代理，而是任何形式的总线。
• 丰富的内容
  • 这里的内容丰富应该针对格式，尽可能避免任何业务方面的丰富。
• 应用集成模式
  • 旧的集成问题不会在微服务领域消失。通过应用经过验证的模式，我们可以避免犯错误。
• 缓存
  • REST架构专门讨论缓存层。复合层尝试应用缓存机制是有意义的，因为它与业务无关，但确实对系统的性能和容错能力产生了重大影响。

复合服务也应该包含在应用程序域中，我将在基础层中讨论这个问题。

• 基础层：像名称一样，它很可能代表系统的基本组件，处理数据检索或业务逻辑处理。每一个都应该是独立自主的。

借鉴Bounded Context（限界上下文）的思想，在本例中，逻辑组织的一组微服务进入所谓的应用程序域，其中每个域表示共享相同数据模型的业务功能的独立实体，从而消除了在代码中进行过多转换的需要。

• 反腐败层：该层负责处理传统应用程序的接口或针对微服务的快速灵活原则的任何操作。这一层是为你的系统构建的内置保护墙，通过执行转换工作并在系统的两个非常不同的实现之间进行转换。

下一次再见！