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