作者 | 佩里阿萨米、克里希纳拉杰
译者 | 崔莹峰
策划 | 云昭
从单一的单体应用到迄今为止的微服务架构，架构风格已经走过了漫长的道路。每种风格都有独特的优势和复杂性。当下，基于微服务的架构适逢其时，它提供了灵活性、敏捷性，并由此给企业带来了更提前的上市时间。然而，微服务体系结构依旧存在严重的问题：在每个领域的即时功能的添加或排除方面缺乏可组合性。也就是说，所有这些架构风格都没有提供可组合的能力。
对可组合架构的需求更多是由业务和市场驱动的，而不是由技术驱动的。在目前的情况下，颠覆性创新既能发生在大范围内，也能发生在小范围内。本文讨论了可组合应用架构的概念及其架构模式。另外，为了充分阐述该架构，本文引入了一个真实的行业应用作为示例。
选择架构的前提已发生变化
时下，一个企业选择何种技术或软件的假设与前提发生了变化。虽然原则、政策和指导方针还是一样的，但在大多数情况下，下列因素对产品、技术和开发的选择也有了直接影响：
- 企业中现有的技术
- 所选用的技术选型在市场上的可用性
- 保证在基础设施、知识产权和人力资源方面的已有投资
- 选择的产品/技术如何应对现有的IT环境
当然，还有其他易见的收益，如TCO、ROI、上市时间等。
围绕可变性：可组合架构的魅力所在
众所周知，每个架构都是由"领域"和"映射到领域的功能"组成。每个功能又由一个或多个解决方案组件实现。
可组合架构并不会偏离上述领域拆分原则；它只是不同于实现所需业务领域功能的组件的组合。
整个架构围绕可变性原则展开。这意味着可变性可能会发生在技术层，也可能会发生在功能中。
以风险管理框架为例，我们将其视为一个领域。这个领域需要和客户打交道，并处理客户各种纬度方面的数据，例如：
了解客户画像
财务适配分析
欺诈分析
关系分析
以上的每一个分析步骤需要全部完成，才能筛选有资格的客户进入金融机构。实际上领域映射的"功能"则会根据技术和功能组件而有所不同，而这些组件像乐高一样堆叠在每个领域上，如下面的示意图所示：
让我们以图中的“KYC”为例，深入了解细节。下图是一个包含四个乐高块的KYC域，然而它从多个维度管理相同的功能“KYC”，每个维度都有自己的实现成本、操作成本、优点和缺点。而且每一个纬度都适合不同的客户群。例如，“X”代和“Y”代的客户更喜欢视频KYC或第三方，而老年人则更喜欢老式的手工分析方式，因为他们的笔迹可能不适合OCR。这就是可组合架构带来的可变性。
正如 Gartner 所指出的那样：
到 2024 年，新 SaaS 和自定义应用程序的设计口号将是“可组合的 API 优先或仅 API”，将传统的 SaaS 和自定义应用程序视为“遗留系统。"
架构风格的演变
从单一的绿屏应用程序到迄今为止的可组合架构，架构风格已经走过了漫长的道路。每种风格都有额外的优势和复杂性。当下，基于微服务的架构适逢其时，它提供了灵活性、敏捷性和更提前的上市时间。然而，微服务体系结构风格却在每个领域的即时功能的添加或排除方面缺乏可组合性。
所有这些架构风格都没有提供可组合的能力，但是，微服务架构以渐进的方式提供了灵活性，从而提供了最大的灵活性和敏捷性。
对可组合架构的需求更多是由业务和市场驱动的，而不是由技术驱动的。在目前的情况下，颠覆性创新既能发生在大范围内，也能发生在小范围内。例如，基于AI、基于ICR的KYC是KYC领域的创新，而像元宇宙这样的东西是大规模的颠覆性创新，可能并不适合可组合架构。
可组合架构的关键原则
可组合架构是一种完整的、全新的技术创新，它也是在流行的微服务架构之上的一种增量式创新。如上一节所述，可组合架构能够在不影响架构的模块化或服务编排的情况下为特定领域添加或排除临时功能。
需要遵循的两个基本原则:
- API优先：API成为提供和使用业务功能的基本理念
- 即时编排绑定：编排过程在运行时被发现，就像服务被发现一样。编排需要存储在一个持久性或内存数据库中(图形数据库是一个很好的选择，因为它可以描述序列以及替代路径)。
可组合服务逻辑解决方案视图
以前面描述的几个领域和功能领域为例，下面展示了涉及可组合服务的解决方案的逻辑视图(与技术栈无关)：
使用组合服务构建的更大的解决方案包含以下核心框架功能：
除了单个或多个领域内的可组合性之外，上述实现可组合性的方法也可以应用于编制/编排层。
可组合服务解决方案实现视图
可组合服务的解决方案实现可以有多种选择，如下图中所示的示例利用图形数据库实现了可组合服务。
图数据库对于不同对象/实体之间的连接建模非常有用。在这种情况下，对象/实体就是通过不同机制(API、事件驱动等)连接起来的微服务本身。在有许多复杂相互关系的服务/API(每个关系由不同的属性驱动)需要连接在一起的情况下，这种方法可能很有用。
另一种方法是利用规则引擎或AI-ML模型来驱动可组合性。
可组合架构模式
以下部分解释了一种代表性的架构模式以及如何实现可组合架构。以下是架构模式的关键组件：
微应用—— 数字场景中的典型事件生成器
事件主干—— 事件主干处理整个事件检测、传播和处理
通道服务—— BFF 服务，实现特定于通道的实现
SOR - 记录系统
事件处理—— 将技术事件转换为业务事件的事件处理引擎
事件主题—— 为不同目的传播的不同主题
事件存储—— 时间序列数据库，帮助实现交易补偿
事件操作关联 - 将事件映射到要执行的操作的名称值存储，以便后续无论是调用特定 API 还是要启动流程编排
API 网关
领域服务—— 封装业务功能的所有领域服务
API 注册表 ——API 发现注册表
流程编排组件
流程编排注册表—— 该注册表有助于根据"事件动作关联"组件提供的业务事件发现需要触发的流程。
流程编排绑定器—— 该组件在运行时绑定 API ，以便为流程编排提供灵活性。对流程的编排的任何更改都映射到该组件，以便实现必要的组合性。这会生成BPMN 的执行脚本，这些脚本将被传播到流程编排执行器 。
流程编排执行器—— 该组件监听流程编排执行的状态并管理流程的状态。它是流程的运行时组件，类似于流程引擎，但轻量级且适用。
流程编排补偿—— 这是业务流程回滚所需要的框架，用于处理由于多种原因导致的流程失败。
通知—— 通知组件将编排状态传递给事件主题，以便所有的订阅者可以使用相同的内容。
结论
本文的目的是介绍可组合架构的核心原则及设计方法，并重点介绍了一个行业场景，并阐明了如何使用图形数据库实现可组合服务。
原文链接：
https://dzone.com/articles/composable-architecture?fromrel=true
译者介绍
崔莹峰，51CTO社区编辑，一名70后程序员，拥有10多年工作经验，长期从事 Java 开发，架构设计，容器化等相关工作。精通Java，熟练使用Maven、Jenkins等Devops相关工具链，擅长容器化方案规划、设计和落地。
