07-Saas系统业务架构设计

SaaS业务架构的系统性框架，探讨业务架构分析的核心要素，帮助SaaS企业深入剖析目标客户的业务模式，全面理解SaaS业务架构。

一、SaaS业务结构

1.目标与步骤

SaaS业务架构需要区分两种视角：SaaS企业自身的业务架构、SaaS服务客户的业务架构。

前者聚焦于SaaS公司自身如何研发、销售、交付其软件服务，涵盖产品研发、获客、产品交付和技术支持等业务活动。

后者关注客户如何利用SaaS产品支持和改进自身业务，需要分析客户的价值流、业务流程、业务能力和组织架构等内容。理解这两种视角的区别对SaaS企业至关重要。SaaS企业不仅要确保自身高效运营，还需为客户提供有价值的、灵活的且可扩展的解决方案。

本章主要聚焦第二种视角，即SaaS服务客户的业务架构。如果读者想了解SaaS企业自身的业务架构如何设计，可以参考吴昊老师的《SaaS创业路线图》。

在这个阶段，我们的核心目标是深入剖析客户群体的业务模式，全面理解他们的业务架构。要实现这一目标，需要系统性地梳理业务架构的各个核心要素。

市面上有许多业务架构分析体系，各有各的侧重点。有些体系包含过多晦涩难懂的概念、术语。

对于业务架构分析方法，核心目标有两点：一是将复杂业务解构为一系列清晰、合理的抽象模型，使SaaS企业各部门能快速理解并落实业务目标；二是确保这些抽象模型具有强大的复用性和灵活的扩展性。

本章主要参考BIZBOK的业务架构体系，主要因为它概念清晰、逻辑简洁，易于理解和应用。业务架构的核心要素包括：价值流、业务能力、业务流程、业务对象、组织架构。

我们将通过以下步骤展开业务架构的分析：

• 价值流分析：识别为客户创造价值的关键流程和环节
• 业务能力分析：评估和确定组织需要具备的关键能力
• 业务流程分析：细化业务能力的具体工作流程
• 业务对象分析：明确并管理业务流程中的关键业务实体和关系
• 组织架构分析：确定支持业务能力所需的组织单元和关系

2.价值流分析

价值流在业务架构中扮演着关键角色，它是企业战略和日常运营之间的纽带。

通过价值流分析，企业能够清晰地了解如何持续为客户创造价值。这种分析不仅有助于企业实现其价值主张，还为后续的业务能力评估、流程改进和组织结构优化提供了坚实基础。

2.1 从价值主张到价值流

在商业模式中，价值主张占据了核心地位。

每个企业基本都会强调以“客户为中心”，企业在决定投入某个产品或服务前，首先需明确三个关键问题：它服务于哪个“客户群体”？提供什么价值？目标“客群”能否接受其价格？

价值主张，简单来说，就是客户或其他利益相关者的“愿望清单”，企业需要通过产品或服务来满足这些愿望。

利益相关者们不关心你有多强，他们只在乎你能不能解决他们的实际问题。

那么，如何实现这些”愿望”？答案是通过企业的价值流。价值流概念的引入对企业聚焦”以客户为中心”的理念至关重要。

如果没有梳理清楚价值流，企业可能会面临以下问题：

• 资源分配不当：无法准确识别哪些活动真正为客户创造价值，导致资源浪费在非关键环节上。
• 客户需求满足不足：缺乏对客户价值的清晰认识，可能导致产品或服务无法有效满足客户需求。
• 内部协作效率低下：各部门之间缺乏共同目标和清晰的价值创造路径，造成沟通障碍和效率损失。
• 创新方向偏离：无法准确把握市场需求和价值创造机会，可能导致创新方向与实际需求脱节。

2.2 价值流的概念

在 BIZBOK 中，价值流是核心业务架构要素之一，主要用于描绘企业如何为其客户和其他利益相关者创造和交付价值。

价值流是为客户创造价值的端到端活动集合，涵盖从客户需求到最终价值交付的所有环节。这里的客户可能是最终消费者，也可能是企业内部用户。价值流有两个关键特点：

1、针对特定利益相关者的需求设计。

这意味着每条价值流都有其服务的目标群体，我们需要时刻关注这些群体，满足他们的具体需求。

2、针对这些特定需求，实现闭环价值交付。

价值流会进一步细化为价值流阶段、具体的业务流程、解决方案、产品或服务。我们需要确保这些要素能够有效地串联起来，使最终交付的价值真正满足利益相关者的需求。

这样可以避免出现”各自为战”的情况，即每个人都在辛苦工作，但最终却没有交付实际价值。

那么，利益相关者有哪些？对零售企业而言，利益相关者可大致分为两大类：

1、终端消费者。

他们是企业产品和服务的直接消费者，其需求、偏好和体验直接决定了企业的市场地位和长期发展。因此，企业在战略决策和日常运营中，必须将终端消费者的需求置于核心位置。这是驱动业务增长的关键。

2、其他利益相关者。

包括供应商、员工、股东、合作伙伴等，他们虽然不是直接的消费者，但在企业的运营和发展中扮演着至关重要的角色。

2.2 价值流如何识别？

在零售行业中，价值流涵盖了从产品开发到客户服务的方方面面，反映了零售商家如何在竞争激烈的市场中脱颖而出。

零售企业的价值流，通常有两类：运营型价值流、支撑和管理型价值流。

1、运营型价值流

这类价值流是企业创造和传递价值给客户的主要途径，直接关系到企业的核心业务运作，包括产品研发、销售、客户服务等方面，对企业的日常运营和收入产生直接影响。这类型的核心价值流包括：

• 产品管理价值流（从创意到产品）：将一个想法转化为实际产品的全过程。包括市场调研、产品设计、研发、生产和上市等步骤。
• 市场营销价值流（从机会到潜在客户）：利用市场机会，通过营销手段吸引潜在客户的过程，目的是让更多人了解并感兴趣。
• 交易价值流（从潜在客户到订单交付）：将感兴趣的潜在客户转化为实际购买者，并完成商品交付的过程。涉及销售、订单处理、物流配送等环节。
• 客户服务价值流（从成交客户到忠诚客户）：通过优质的售后服务、客户关怀、客户权益，将一次性购买的客户培养成长期支持的忠诚客户的过程。

2、支撑和管理型价值流

这类价值流虽不直接面向客户，却满足其他利益相关者的需求，对企业的整体运作起着至关重要的作用。例如，人力资源管理、财务管理、IT支持、法律合规、供应链管理等方面。

这些价值流为核心业务提供必要的支持和保障，确保企业能够高效、合规地运营。

以下以一家蛋糕商家为例，展示了几条常见的价值流，并阐明了利益相关者、价值主张和价值流之间的关系。

2.3 价值流阶段如何识别？

价值流通常会包含多个价值流阶段，每个阶段都具有其特定的价值增量，共同确保为客户交付完整价值。

如何划分价值流阶段？价值流的阶段应尽可能与客户旅程的阶段相匹配，建立清晰的对应关系。梳理客户旅程是提升客户体验的关键步骤。通过对客户旅程进行端到端的分析，确保涵盖所有重要阶段。

以一家蛋糕企业为例，对于一个蛋糕产品的消费者来说，他的客户旅程可划分为以下几个阶段：

• 想买蛋糕：客户意识到自己想要买蛋糕，可能是为特殊场合（如生日、婚礼或庆典）准备，或单纯想品尝甜点。
• 寻找店铺并对比：客户开始寻找并对比不同的蛋糕品牌或店铺，寻找能满足其特定需求（如款式、口味、预算、定制服务）的选项。
• 决定到哪买：客户决定在哪家蛋糕店购买，并确定所需的蛋糕种类、口味、装饰以及交付方式。
• 正式购买：客户正式下单并支付费用，确认交付时间和方式（如店内自提或配送服务）。
• 收货：客户接收蛋糕，体验商家的交付服务。

基于客户旅程的关键活动，我们识别出各个价值流阶段，每个阶段都有相应价值。理论上，如果某阶段无法增加或满足客户所需价值，可以考虑舍弃。

我们以市场营销价值流为例，可以划分为4个价值流阶段：

• 客户洞察：通过市场调研和客户数据分析，了解客户需求、痛点和行为模式。这有助于企业深入理解客户，让品牌更容易触达目标客户，并设计出有针对性的营销方案。
• 品牌推广：向客户展示产品或服务的独特卖点，帮助客户在考虑阶段更加关注你的品牌。
• 场景营销：此时客户已筛选出几个可能的品牌，正在做出最终购买决定。通过针对特定客户场景（如生日、婚礼、周年纪念等）的个性化营销，增加产品吸引力并促使客户做出购买决策。
• 触达转化：在客户购买前，通过流量渠道、企业微信、短信等渠道发放福利、多次提醒，激励客户最终完成交易。

3.业务流程

3.1 业务流程的概念

业务流程是企业为实现目标而制定的一套系统化的工作方法。它由一系列有序的业务活动组成，按照既定规则将资源（输入）转化为有价值的结果（输出）。

在业务架构分析阶段，业务流程发挥着关键作用：

• 明确业务运作的方式：业务流程详细描述了企业的各项业务活动及其顺序和关联，帮助深入理解企业如何将资源转化为产品或服务。
• 识别改进机会：通过分析现有的业务流程，可以发现流程中的瓶颈、重复和低效环节，为流程优化和业务改进提供依据。
• 支持战略对齐：业务流程分析确保业务运营与企业的战略目标保持一致，促进战略的有效实施和落地。
• 支持系统架构设计：业务流程为信息系统的设计和开发提供了清晰的业务需求，确保技术解决方案与业务需求紧密匹配。

业务流程通常有2大核心视角：

• 端到端流程：强调跨部门的协作与整体效率，贯穿整个业务链条，从客户需求的起点到最终满足的终点。
• 职能流程：聚焦于各个部门内部的专业化分工，确保每个职能领域的高效运作。

这两种流程相辅相成，共同构建了企业的完整业务体系。

3.2 端到端流程

1、端到端流程的定义

简单来说，端到端流程就是从客户需求发起，到最终客户需求被满足的整个过程。

“价值流”与”端到端流程”常被拿来比较。那么，这两者之间有何区别？

“价值流”是企业业务的战略蓝图，提供宏观视角，概括了整体价值创造过程。而”端到端流程”则是这个蓝图的具体实施方案，详细描绘了每个环节的操作细节。

前文中讲到，通过梳理价值流，我们可以聚焦客户需求，发现哪些环节为客户创造价值，哪些环节存在浪费。然后，基于这些环节，形成高效的端到端流程。

它们之间的关系如图所示。

从价值流到端到端流程，就是把企业价值创造的过程进行细化。端到端流程的作用包括：

• 全面了解业务：通过梳理从需求发起到满足的完整过程，展示各环节如何衔接以及潜在问题。这就像一张清晰的路线图，为企业指明工作方向。
• 聚焦核心目标：端到端流程始于客户的真实需求。通过确保流程中的各个团队和部门都围绕这些需求展开工作，我们能够为客户交付真正的价值，同时避免资源浪费。
• 增强企业响应能力：面对瞬息万变的市场和客户需求，清晰的流程让企业能够迅速调整策略。当新需求出现时，企业可以快速组合现有的流程模块，及时响应市场机会。

2、端到端流程的颗粒度

端到端流程的颗粒度与终端客户的典型需求密切相关。因此，划分端到端流程的核心在于准确定位终端客户及其典型需求。

以一家蛋糕商家为例，其端到端流程可能包括：

• 线上预订，配送到家流程：客户在线上预订蛋糕，选好配送时间，商家按约定时间配送到家。
• 客户到店，门店服务流程：针对亲临实体店的客户，门店销售和服务的全过程。

3.3 职能流程

1、职能流程的定义

职能流程是企业各部门为完成特定任务而制定的工作规范。

通过梳理和完善职能流程，各部门的工作流程变得清晰明确。这为构建端到端流程提供了可靠的基础模块。职能流程的核心作用包括：

• 审视企业管理的完整性：由于企业组织架构通常基于职能分工，梳理各职能流程就像对企业进行全面体检，找出需要改进的方面。
• 构建端到端流程：有了职能流程，就能像搭积木一样构建出端到端流程。缺乏职能流程架构，端到端流程就需要反复梳理，导致大量资源浪费。

2、职能流程的颗粒度

职能流程如何切分？一种较为直观的方式是根据企业的组织架构进行划分。例如，一个蛋糕商家有研发部、生产部、品牌部、直营店部、配送部等部门，就相应设计研发流程、生产流程、品牌推广流程等职能流程。

然而，这种方式直接将组织架构与职能流程绑定。如果组织架构设计不合理，职能流程也将随之不合理。更重要的是，这种方法无法通过职能流程发现组织的问题，从而难以打破组织壁垒。

切分职能流程的关键在于以”业务对象”为核心进行划分。

业务对象指在业务运营中核心关注的人、事、物。例如客户、产品、订单、合同、供应商等。

以业务对象管理闭环为核心来切分职能流程，可确保：

• 划分标准清晰：企业能统一职能流程的颗粒度，避免过度拆分或界定模糊。
• 避免重复建设：职能流程涵盖业务对象相关的完整事项和信息。如果两个职能流程围绕同一个或同类业务对象进行操作，很可能可以合并。

以蛋糕加工作业流程为例，从提交加工单开始，经过领料、配料、制作、裱花，直到加工完成。整个流程围绕”加工单”这一核心业务对象展开。不应将领料、配料等环节拆分成独立流程，这可能导致流程不闭环，徒增管理复杂性。

3.4 示例：零售企业的业务流程

下图展示了一个典型的线上预订蛋糕并配送到家的端到端流程，其中包含了多个部门的职能流程。例如，客服部门负责接收、确认蛋糕细节、派单。中央厨房负责蛋糕的制作，物流部门则负责配送。

这些部门各自的工作流程体现了职能流程的具体实施。每个部门的泳道内的活动序列，准确地反映了该部门在整个业务流程中的职责和具体操作步骤。

从整体来看，我们可以清晰地观察到各个职能部门如何协同工作，共同完成从接收订单到最终交付的全过程。

4.业务能力

4.1 业务能力的概念

简单来说，业务能力是企业“做某事的能力”。

业务能力描述了企业当前和未来应对挑战的能力，即企业能做什么或需要做什么。业务能力建模的关键在于定义了企业做什么，而不是如何做（由业务流程描述）。

以人才招聘为例，大多数公司都需要”招聘人才”这项业务能力。”招聘人才”明确了要做什么，但并未详述如何执行。这可能是招聘HR通过招聘网站吸引候选人，也可能是将任务外包给猎头公司。

准确定义的业务能力通常具有高度稳定性。过去几十年中，尽管招聘流程、技术和模式经历了翻天覆地的变化，”招聘人才”这项核心业务能力依然保持不变。

正是由于业务能力的这些特征，它对构建IT系统架构提供了至关重要的帮助。围绕业务能力构建的IT系统不仅具有更稳定的结构，还更容易扩展。

当需要推出新产品或服务时，合理复用现有能力是最高效的方案。

4.2 业务能力的构成

业务能力独立于组织的人员、流程、信息、资源。准确地说，这些业务要素是支撑业务能力而存在的。同样以“招聘人才”为例，“招聘人才”包括的业务要素可能有：

• 人员：人力资源团队。
• 业务流程：吸引、筛选、面试、雇用。
• 信息：职位描述、招聘需求、应聘者简历、面试评估表、入职文件等。
• 资源：招聘系统、人事系统。

4.3 业务流程与业务能力的区别

• 业务能力：关注企业核心业务的能力和结果，不涉及具体的流程分解。
• 业务流程：专注于流程本身，面向特定场景，通过活动组合解决具体问题，是企业日常运作的关键动作。

	业务能力	业务流程
关注点	做什么（what）	怎么做（how）
业务目标	职能专业化	协作顺畅
表现形式	抽象的、模块化	具体的、端到端
相互关系	为流程提供支持	向能力提需求

业务流程的不同环节，需要对应的业务能力来支持，业务能力可以被多个业务流程复用。业务能力被复用的次数越多，企业在业务能力建设上的收益就越大。

如图所示，以订单派单的业务流程为例，接收订单、派单环节依赖订单履约能力，确认蛋糕订单细节环节依赖客户服务能力。

4.4 业务能力如何识别？

企业可以采用多种方法来有效识别业务能力。每种方法都有其特点，企业应根据自身实际情况和需求灵活选择。下面我们将介绍几种常见且行之有效的识别方法。

1、围绕业务对象进行识别。

这种方法是业务能力识别中最基础且推荐的梳理方式。业务对象作为企业运营的基本要素，不仅能有效帮助企业识别关键业务能力，还能确保这些能力的全面性和稳定性。

举例来说，通过深入分析”客户”、”商品”、”库存”、”渠道”等核心业务对象，企业可以相应地识别出”客户服务”、”商品销售管理”、”库存管理”、”渠道运营”等关键业务能力。

2、基于职能流程来识别业务能力

对于已经建立良好流程基础的企业，通过分析各个职能部门的业务流程，企业可以迅速识别出对应的业务能力。这确保业务能力与企业实际运营的紧密联系，同时也有助于发现可能被忽视的关键能力。

3、参考业界成熟模型

成熟的行业模型可以帮助企业识别和定义自己的业务能力。这些模型提供了很好的起点。不过，企业需根据自己的实际情况来调整和定制这些模型。

以下是一些常用的行业模型：

• APQC流程分类框架：提供了各个行业的标准化业务流程和能力分类。
• IBM Industry Models：针对特定行业提供详细的业务能力模型，涵盖零售、银行、保险、电信等多个领域。
• SAP Retail Business Capability Framework：专门针对零售行业的业务能力框架，涵盖了从采购到销售的各个环节。

4、参考成熟的B端软件来识别

在识别业务能力时，成熟的B端软件可以作为一个重要的参考来源。这些软件通常是基于行业最佳实践和广泛的市场需求开发的，因此能够反映出特定领域中普遍需要的业务能力。

例如，ERP系统通常包含了财务管理、供应链管理、人力资源管理等模块，这些模块可以直接对应到相关的业务能力。

同样，CRM（客户关系管理）系统中的销售管理、客户服务、市场营销等功能，也能帮助企业识别出这些领域的关键业务能力。

通过分析这些软件的功能模块和特点，企业可以全面了解行业标准和最佳实践，从而更准确地定义和完善自身的业务能力体系。

4.5 示例：零售企业的业务能力

如图所示，我们详细展示了一个典型零售企业的业务能力体系，涵盖了L1和L2两个层级。

核心运营能力直接面向终端客户，包括采购管理、供应链管理和商品销售管理等。这些能力直接影响企业的市场表现和客户满意度，是企业竞争力的核心体现。

其次是企业运营支持能力。这部分能力虽然不直接面向客户，但为企业的日常运营提供了重要支撑。包括财务管理、IT部署和管理以及员工管理等。这些能力确保了企业内部运作的效率和稳定性。

5.业务对象

5.1 业务对象的概念

业务对象指企业在业务运营中核心关注的人、事、物，承载了业务运作和管理决策涉及的重要信息。例如客户、产品、订单、合同、供应商等。

5.2 如何识别业务对象？

1、物理可感知的实体

一种是物理可感知的实体，如客户、商品、人员、设备等，它们在特定的时间和空间中真实存在，大部分能看得见摸得着。

2、管理记录

另一种是”管理记录”，即企业业务活动的可追溯凭证。这些信息载体通常以文档、表格等形式存在，记录了业务流程中的关键数据和状态信息，也就是所谓的”表证单书”。

“表证单书”在企业信息管理和流程控制中扮演着不可或缺的角色。它们不仅帮助企业规范化和标准化信息传递，还确保了业务流程的透明度和可追溯性。

我们以在线预订蛋糕，配送到家的流程为例：

一位消费者在线上预订了次日的蛋糕，满怀期待地等待着。然而，约定的时间悄然过去，蛋糕却迟迟未送达。一场满怀期待的生日就被毁了，消费者的期待转为愤怒的投诉。

管理者接到投诉后，首先查看订单状态，发现订单处于”待发货”状态。由此判断，订单已流转至中央厨房，订单流转环节无误。

接着检查相应的加工单状态，发现加工单已完成。这表明加工环节也未出问题。

最后查看配送单状态，发现配送单仍处于”待配送”状态。进一步了解，原来是分配的配送员因个人紧急原因，无法完成配送。

通过这一追溯过程，管理者确定问题出在配送环节。这一发现为后续改进流程、防止类似情况再次发生提供了依据。

如果缺乏这些清晰准确的管理记录，管理者可能一头雾水，无法确定责任归属。

5.3 业务对象的属性

业务对象包含多个细节信息，这些信息被称为属性。属性是描述业务对象特征和状态的具体数据项，它们共同构成了业务对象的完整定义。

每个属性都代表了业务对象的一个特定维度，如名称、日期、数量或状态等。

通过这些属性，我们能够全面地描述和理解业务对象，从而有效地管理和利用这些信息来支持业务运营和决策制定。

我们以零售商家的客户订单为例，至少需要包含以下属性：

• 商店在某段时间内销售了哪些零售商品？
• 零售商品在什么时候售出？
• 商品在商店的什么位置售出？
• 谁卖出了这些零售商品？
• 商品售价是多少？
• 交易中赚取了哪些费用？
• 对商品应用了哪些特殊折扣、价格调整、降价等方式？
• 为结算这笔交易，收取多少现金？
• 使用哪种支付方式支付的？

6.组织架构

组织架构是按照企业战略来设定和安排部门和岗位，形成稳定且科学的管理体系。这个体系保证企业能适应业务需求并支持企业发展。

组织架构对业务架构至关重要。在梳理业务流程时，要根据流程的运作规律和处理逻辑，在各个节点安排合适的人员，这样才能确保组织得灵活性和责任明确。

同时，业务架构也需要考虑组织的业务发展和需求，对部门的岗位设置、人员配置、角色定义、权限职责以及考核机制进行清晰规划，确保业务流程中每个环节能顺利运作。

6.1 组织架构的核心内容

• 层级结构：明确企业内部的上下级关系，即谁对谁负责，谁向谁汇报。通常分为高层管理、中层管理和基层员工。
• 部门划分：根据职能、产品、地区或客户等因素划分不同部门，各部门负责特定的业务活动。例如，常见的职能部门包括市场部、财务部和生产部等。
• 职责和权限：明确每个职位的具体职责和权限范围，确保各岗位员工了解自己的工作内容和权限。这有助于避免职责重叠或权责不清，从而提高工作效率。
• 沟通协作：制定不同层级和部门之间的沟通方式和渠道，确保信息流动顺畅。有效的沟通和协调机制能促进问题解决、决策制定和工作推进。
• 指挥链：建立从最高领导到基层员工的清晰指挥链，确保决策和指令能够有效传达和执行。指挥链通常呈纵向结构，有助于维持组织的统一性和协调性。

6.2 常见的组织架构类型

• 职能型组织架构：根据主要职能划分部门，如生产、销售、财务等，每个部门负责特定的职能。
• 产品型组织架构：根据产品或服务划分部门，每个部门负责一个或多个产品线的全部活动。
• 区域型组织架构：根据地理区域划分部门，每个区域部门负责该地区的业务活动。
• 矩阵型组织架构：结合职能型和项目型架构，员工同时隶属于职能部门和项目团队，适用于复杂项目管理。
• 扁平型组织架构：减少管理层级，缩短管理链条，增强灵活性和创新能力。

6.3 示例：零售企业的组织架构

通常情况下，零售企业会从单店经营开始，业务不断扩展，开设更多的门店，达到中小连锁企业规模，员工数量达到了几十人或上百人。

中小连锁企业下设部门通常包括：研发部、生产部、品牌部、直营店部、配送部、品控部、仓储部、采购部、大客户部、行政人事部、信息技术部。

• 研发部门：负责新品研发、产品升级和口味改进，确保产品持续保持市场竞争力。
• 生产部门：管理生产制造、品质控制和生产计划，确保产品质量和产量的平衡。
• 品牌部门：执行品牌策划、市场推广和形象宣传，提升品牌知名度和美誉度。
• 直营店部门：负责直营店的日常运营、销售业绩和客户服务，优化店铺运营效率和客户满意度。
• 配送部门：处理产品配送、物流管理和仓储管理，保证配送的及时性和准确性。
• 品控部门：进行产品品质检测和质量控制，维持产品质量的稳定性。
• 仓储部门：管理原材料、半成品和成品的仓储，以及物资采购，确保生产和销售的流畅性。
• 采购部门：从供应商处采购原材料、半成品和包装材料，确保原材料的及时供应和合理定价。
• 大客户部门：开拓大客户并提供定制化服务，提高大客户的满意度和忠诚度。
• 行政人事部门：负责企业的招聘、人事管理和行政管理，保证企业运营的法律合规性和人力资源的稳定性。
• 信息技术部门：负责企业IT系统的改造、实施和维护，确保系统、服务器和网络的稳定运行。

下图所示为一个中小连锁企业的组织架构图。

本文已收录于，我的技术网站：tangshiye.cn 里面有，算法Leetcode详解，面试八股文、BAT面试真题、简历模版、架构设计，等经验分享。

二、SaaS系统架构设计

1.多租户

多租户是SaaS领域的特有产物，在SaaS服务中，租户是指使用SaaS系统的客户，租户不同于用户，例如，B端SaaS产品，用户可能是某个组织下的员工，但整个企业组织是SaaS系统的租户。

多租户技术是一种软件架构技术，可以实现多个租户共享系统实例，并且租户间能够实现数据与行为的隔离。

传统软件模式 VS SaaS模式

传统软件项目一般是指，面向客户开发一套特定的软件系统，并部署在独立的环境中，通常是企业内部环境。

而SaaS模式，是将软件服务部署到云端环境，可以面向不同的客户提供相同的软件服务。

2.SaaS多租户隔离模式

对于SaaS模式，多租户间的资源隔离是非常基础的能力，出于成本和运营效率考虑，SaaS服务商需要构建多租户可同时访问软件的环境，不同租户虽然访问同一套SaaS产品服务，但资源访问需要严格隔离开。

SaaS资源隔离包含几个层次：

• 第一层是SaaS系统底层所涉及到的计算、存储、网络等资源的隔离。
• 第二层是系统基础数据的隔离，主要包括组织，用户，角色，权限，产品能力授权关系等。
• 第三层是系统使用过程中，各类业务动态数据的隔离，例如业务单据、操作记录等。

多租户架构主要是解决第一层的隔离问题，即计算、存储、网络等资源的隔离。为了实现多租户隔离架构，我们先要搞清楚常见的几种多租户隔离模式。

2.1 竖井隔离模式

有些SaaS服务商会选择竖井隔离模式，即每个租户都运行在隔离的一套资源中。有人会说，这不就是传统软件模式吗，为什么会是SaaS模式呢？但如果这些竖井式的资源，拥有标准化的租户身份识别、入驻流程、计费体系、部署流程、运营流程，那边它依然是SaaS模式，只不过每个客户都有一套端到端的基础设施。

优势

• 满足强隔离需求：一些客户为了系统和数据的安全性，可能提出非常严格的隔离需求，期望软件产品能够部署在一套完全独立的环境中，不和其他租户的应用实例、数据放在一起。
• 计费逻辑简单：SaaS服务商需要针对租户使用资源进行计费，对于复杂的业务场景，计算、存储、网络资源间的关系同样也会非常复杂，计费模型是很有挑战的，但在竖井模式下，计费模型相对来说是比较简单的。
• 降低故障影响面：因为每个客户的系统都部署在自己的环境中，如果其中一个环境出现故障，并不会影响其他客户使用软件服务。

劣势

• 规模化问题：由于租户的SaaS环境是独立的，所以每入驻一个租户，就需要创建和运营一套SaaS环境，如果只是少量的租户，还可能可以管理，但如果是成千上万的租户，管理和运营这些环境将会是非常大的挑战。
• 成本问题：每个租户都有独立的环境，花费在单个客户上的成本将非常高，会大幅削弱SaaS软件服务的盈利能力。
• 敏捷迭代问题：SaaS模式的一个优势是能够快速响应市场需求，迭代产品功能。但竖井隔离策略会阻碍这种敏捷迭代能力，因为更新、管理、支撑这些租户的SaaS环境，会变得非常复杂和低效。
• 系统管理与监控：在同一套环境中，对部署的基础设施进行管理与监控，是较为简单的。但每个租户都有独立的环境，在这种非中心化的模式下，对每个租户的基础设施进行管理与监控，同样也是非常复杂、困难的。

2.2 共享模式

相信很多SaaS服务商会优先选择共享模式，即多租户共享一套基础设施资源，这样能让SaaS软件服务更加高效、敏捷、低成本。

优势

• 高效管理：在共享策略下，能够集中化地管理、运营所有租户，管理效率非常高。同时，对基础设施配置管理、监控，也将更加容易。相比竖井策略，产品的迭代更新会更快。
• 成本低：SaaS服务商的成本结构中，很大一块是基础设施的成本。在共享模型下，服务商可以根据租户们的实际资源负载情况，动态伸缩系统，这样基础设施的利用率将非常高。

劣势

• 租户相互影响：由于所有租户共享一套资源，当其中一个租户大量占用机器资源，其他租户的使用体验很可能受到影响，在这种场景下，需要在技术架构上设计一些限制措施（限流、降级、服务器隔离等），让影响面可控。
• 租户计费困难：在竖井模型下，非常容易统计租户的资源消耗。然而，在共享模型下，由于所有租户共享一套资源，需要投入更多的精力统计单个租户的合理费用。

2.3 分域隔离模式

传统大企业更喜欢私有化部署、个性化交付的传统模式，因为他们需要更强的管控和更高的安全性。然而，中小企业付费能力有限，需求往往也更加标准化，所以更喜欢价格更低的、订购更简单的SaaS产品。

为了满足不同客户的需求，还有一种混合了竖井模型与共享模型的模式，即分域隔离模式。在该模式下，会细分基础域、专用域，基础域是使用共享模型，所有租户共享一套资源；而专用域是使用竖井模型，每个租户都有独立的资源环境。

对于大多数中小客户来说，他们都是在基础域环境使用SaaS产品，只有少量的大客户会在专用域使用SaaS产品，通常他们付费能力强，有强烈的强隔离需求。

但需要注意的是，为了避免多套产品版本出现，SaaS服务商需要保证基础域、专用域的产品版本一致，个性化的部分尽可能通过构建PaaS平台，让ISV参与建设。否则，一旦SaaS产品的标准化程度降低，后续各版本的维护将变成灾难。

3.多租户系统的定位

了解各种多租户隔离模式后，我们来总结下多租户系统的定位。

多租户系统是为了满足多用户使用一套产品，并实现用户间的数据与行为隔离，但根据用户需求不同，可以共享或隔离软硬件资源，系统架构上能够灵活支持多种隔离模式。

多租户系统需要具备的能力：

• 多个租户支持共享一套云资源，如计算、存储、网络资源等。单个租户也可以独占一套云资源。
• 多个租户间能够实现数据与行为的隔离，能够对租户进行分权分域控制。
• 租户内部能够支持基于组织架构的管理，可以对产品能力进行授权和管理。
• 不同的产品能力可以根据客户需求，支持运行在不同的云资源上。

4.多租户概念模型

多租户核心概念

• 租户：一般指一个企业客户或个人客户，租户之间数据与行为是隔离的。
• 用户：在某个租户内的具体使用者，可以通过使用账户名、密码等登录信息，登录到SaaS系统使用软件服务。
• 组织：如果租户是一个企业客户，通常会拥有自己的组织架构。
• 员工：是指组织内部具体的某位员工。
• 解决方案：为了解决客户的某类型业务问题，SaaS服务商将产品与服务组合在一起，为商家提供整体的打包方案。
• 产品能力：指的是SaaS服务商对客户售卖的产品应用，特指能够帮助客户实现端到端场景解决方案闭环的能力。
• 资源域：用来运行1个或多个产品应用的一套云资源环境。
• 云资源：SaaS产品一般都部署在各种云平台上，例如阿里云、腾讯云、华为云等。对这些云平台提供的计算、存储、网络、容器等资源，抽象为云资源。

概念模型设计

• SaaS平台可以创建与管理多个平台用户、多个租户、多个资源域。
• 单个平台用户可以关联到多个租户下，例如，平台用户张三，可以是租户A的用户，也可以是租户B的用户。单个租户下可以拥有多个用户。
• 单个租户可以订购多个解决方案，解决方案可以包多个产品能力，产品能力运行在某个资源域上。
• 组织单元间有上下级关系，单个组织下可以有多个员工，员工与单个用户进行绑定。

5.多租户核心场景

租户内部模型关系

对SaaS产品来说，租户是最顶层的概念，租户内部拥有组织、用户、产品能力、云资源等模型，租户就像租了一套大房子，其他模型都是房子内部的家具或设施。

租户身份识别

在各种隔离模式下，识别租户身份，获取租户的资源配置，是非常关键的。当一个用户登录SaaS系统后，系统会返回租户上下文信息，上下文会包含用户绑定的租户信息，以及隔离模式。

租户上下文信息会被附加在每一次系统交互中，贯穿整个系统调用链路，让上游调用方知道路由到哪些下游资源。

租户计费计量管理

在竖井隔离模式下，由于资源本身就是隔离的，所以可以根据占用的计算、存储、网络资源来计费计量，逻辑相对简单。

在共享模式下，计费计量就比较复杂，我们要能准确地采集到各个租户对实际资源的使用情况，一般会根据请求并发量、存储容量、数据对象数量等数据来进行组合计费。

多租户系统应用架构

三、SaaS应用架构设计

1.应用架构概述

应用架构就像整个SaaS系统的骨架，决定了系统的整体结构和各个组件之间的关系。接下来，我们会深入探讨应用架构的三个核心要素：应用服务、应用结构和应用交互。这些要素共同构成了一个体系化的SaaS系统架构。如图所示。

通常，应用架构设计包括以下几个步骤：

• 识别应用服务：根据业务架构，把业务需求转化为IT系统，找出关键的应用服务。
• 划分应用结构：设计应用结构，以及与业务流程、数据之间的关系，明确各部分的职责。
• 设计应用交互：规划各个应用结构之间如何交互和集成，确保系统各部分协调运作。

2.应用服务设计

在设计应用服务之前，我们先搞清楚什么是应用服务，以及重要性。

应用服务的概念

应用服务是对一个或一组密切相关的业务对象及其操作的封装。

应用服务要明确定义自己的责任范围，将相关业务功能和对象组合在一起，避免暴露内部细节。

它需要整合因为同一原因变化的功能和数据，同时分离那些因为不同原因变化的部分。这样的设计方法，确保了服务的内聚性和灵活性。

应用服务的概念源自SOA（面向服务的架构）和微服务架构的兴起。通过把系统功能拆分成多个独立的服务，可以提高系统的可维护性、可扩展性和灵活性。

应用服务如何划分？

应用服务在应用架构中非常重要，它把系统的核心功能“打包”起来，提供给外部的业务流程使用，可以看作是SaaS系统对外的“门面”。用户或者其他系统通过调用应用服务来实现特定的业务功能。那么，怎么设计应用服务呢？

1、对齐业务能力，划分粒度适中的应用服务，职责单一。

在划分应用服务粒度时，可以参考领域驱动设计（DDD）中的”限界上下文”概念。业务对象类似于限界上下文中的聚合根，是应用服务的核心。

通常情况下，我们会基于业务能力来划分应用服务，每个业务能力都对应一到多个独立的应用服务，每个应用服务用于支撑特定的业务能力。如图所示。

将应用服务与业务能力对齐，确保系统功能紧密贴合业务需求，避免技术实现与业务逻辑脱节。

如果一个应用服务支撑了过多的业务能力，需要评估其内部是否关联了过多的业务对象。在这种情况下，可以考虑将多个业务对象进行分组，从而将该应用服务拆分为多个更小、更专注的服务。

2、围绕业务对象，提供具体的业务功能，避免包含不相关的功能。

从外部来看，应用服务通常有明确的业务含义，主要围绕一个或一组密切相关的业务对象进行操作。

围绕业务对象设计服务可确保服务内部功能高度相关，提升内聚性。提供具体的业务功能让服务的边界更清晰，有利于业务团队和技术团队的协作与沟通。

例如，线上商城系统的”交易服务”专注于订单确认、下单和支付等功能，不应处理用户认证、商品推荐等其他业务。

服务化架构的价值

面向服务的架构最大的价值就在于它的敏捷性和灵活性。

敏捷性体现在服务可以快速调整，独立演进。灵活性体现在每个服务都有清晰的业务边界，功能内聚性强，能够单独管理生命周期。具体来说：

1. 轻量级应用：采用基于服务设计的轻应用，各个服务独立开发、部署和运营，可以独立交付，影响范围小，提升交付效率。
2. 服务复用、灵活编排：通过服务的复用和灵活编排，可以快速响应业务的变化，支持复杂的业务流程。
3. 局部扩展性高：系统被拆分为独立的服务后，容易进行横向扩展，只需要扩展必要的部分，成本更低，效果更好。

示例：订单履约应用服务划分

如图所示，订单履约能力是零售企业业务能力地图中的 L2 级别业务能力。

订单履约能力可以细分为多个末级业务能力：面向消费者的履约服务、订单派单、订单管理、拣货管理、发货管理和逆向履约。

基于这些末级业务能力，我们就可以设计出对应的应用服务。

3.应用结构设计

在完成应用服务的设计后，我们需要深入地了解应用的内部结构。

应用结构设计是把应用服务的概念转化为具体实现的关键步骤。它描述了应用服务内部的层次结构和组织关系，决定了系统的模块化程度，以及后续开发和维护的难度。

应用结构的抽象层次

在设计应用结构时，我们通常会把系统分成不同的层次，比如系统级、应用级、模块级和代码级。

这种分层的方式有助于我们在不同层面处理复杂问题，确保系统结构清晰、易于维护。如图所示：

• 系统级：关注各个系统的整体布局和管理方式，比如系统之间的关系，以及它们如何协同工作。
• 应用级：聚焦每个应用的整体架构，包括应用与其他应用的交互方式，以及它们在整个系统中的角色。
• 模块级：对应用内部进行更细致的划分，涉及代码的模块化设计、数据和状态的管理等。通过合理的模块划分，可以提高代码的可维护性和可重用性，减少重复工作。
• 代码级：关注代码本身的结构和实现方式，这一层的设计直接影响到代码的质量和实现细节。

抽象层次的存在，是为了帮我们更有效地管理系统的复杂性。

通过把系统分成不同的抽象层次，我们可以更好地组织和理解系统结构，简化开发过程，提高代码的可维护性和可扩展性。

这种分层方法让开发团队能在不同层次上专注于特定的问题，更好地应对大型软件系统的挑战。具体来说有以下作用：

1、分解复杂度

如果把所有的业务细节、技术细节都混在一起，整个系统就会变得难以理解、维护和扩展。通过设置不同的抽象层次，我们可以把系统的复杂性分解到各个层次，每个层次只需关注特定的功能和职责。

这种分层处理方式让开发人员在专注于系统某一部分时，不用过多关注其他部分的细节，大大简化了系统的设计和开发过程。

2、团队协作边界清晰

在大型项目中，通常会有多个团队同时开发。如果系统没有明确的边界，各团队之间很容易产生冲突和重复劳动。

通过清晰的抽象层次划分，不同团队可以专注于系统的不同层次或模块，互不干扰。

3、扩展性强

随着业务需求的变化，系统往往需要不断地扩展和升级。如果系统的架构设计没有合理的抽象层次，扩展和升级就会变得非常困难，甚至可能需要对系统进行全面重构。

而在有抽象层次的系统中，变更通常只需聚焦在特定的层次上进行，而不会影响整个系统。比如，一次业务改动只影响模块级别，我们就可以在不改变系统整体架构的情况下，替换或新增某个模块，满足新的业务需求。

应用结构如何划分？

在前面，我们提到了应用服务的设计方法，那么怎么把这些应用服务一步一步地转化成代码结构呢？

其实，应用服务是通过一系列的应用结构来实现的。如图所示。

基于应用服务的划分，我们可以进一步细化应用结构，更好地组织和管理系统功能。这个过程涉及到多个层次的设计方法：

1. 系统和子系统的划分要和业务域、业务子域的粒度保持一致。 这样，我们就能更好地把业务需求映射到技术实现上。
2. 一个或多个相关的应用服务，可以组合成一个可独立部署的应用。
3. 在应用内部，可以进一步分层。 比如，参考领域驱动设计（DDD）的分层方法，可以分为用户接口层、应用层、领域层和基础设施层。
4. 应用的各个层级内部，还可以细分为多个模块，每个模块又包含多个代码单元。

那么，具体来说，我们该怎么划分应用呢？可以参考以下几点原则：

1、业务划分原则

应用划分的关键是看应用服务的边界。

应用服务的核心目标是帮助企业实现业务能力，所以它们需要和业务能力保持一致。而应用是实际的物理部署单元，应用服务最终要部署在特定的应用上。

因此，一个或多个相关的应用服务，可以组合成一个可独立部署的应用。

应用服务可以单独部署，也可以多个服务合并部署。那么，如何判断何时选择独立部署，何时选择合并部署呢？这需要参考技术层面的成本和稳定性风险等因素。

2、技术划分原则

在业务初期，尽量从单体应用开始，避免过早地把应用拆得太细，这样可以减少分布式数据库事务和数据不一致的问题，并可以降低技术部署成本。然而，即使在单体应用内部，也需要将应用服务划分为界限分明的模块。

避免应用之间出现循环依赖或双向依赖。在应用单元内部，可以进一步分层，始终保持不同层级之间的单向依赖关系，高层级可以依赖低层级，同层级之间不应互相依赖。

只有当真正遇到技术上的痛点，比如规模、性能、安全等问题时，才考虑拆分应用。如果不拆分会严重影响业务的稳定性，那就应该拆分。但不要为了拆分而拆分，因为每次拆分都会增加系统的复杂度。

3、组织规模原则

划分后的单个应用的项目团队规模通常建议保持在10～12人左右。

因为团队成员越多，沟通的渠道就会成倍增加，可能导致信息传递变慢或者失真。一个10到12人的团队，可以确保大家的沟通更直接、更高效，减少信息障碍。

小团队更容易管理，项目经理或者团队领导能更好地了解每个成员的工作状态和需求，进行更有效的协调和支持。

同时，小团队有助于建立更紧密的合作关系，成员之间更容易培养出默契，提升整体工作效率和项目质量。

示例：订单履约系统的应用结构划分

如图所示，是订单履约系统的应用结构划分。

• 用户接口层：直接与用户交互的层级，负责向用户显示信息，响应用户命令。
• 应用层：定义软件的应用功能，它负责接收用户请求，协调领域层能力来执行任务，并将结果返回给用户，核心模块包括：
• 领域层：业务逻辑的核心，专注于表示业务概念、业务状态流转和业务规则，沉淀可复用的服务能力。

4.应用交互设计

应用交互就是指不同应用之间怎么“沟通”和“交流”。

在一个复杂的系统中，各个应用可不是孤立存在的，它们需要互相配合，才能完成更复杂的业务流程。

应用交互的设计，就是为了确保这些系统和组件能够顺畅地“对话”，一起实现系统的整体目标。

应用交互的方式有很多种，包括同步调用、异步消息通信等等。每种方式都有特定的应用场景和优缺点。

通过合理的交互设计，系统中的各个部分能够高效协作，降低耦合度，增强系统的灵活性。

同时，好的交互设计还能显著提升系统的性能和容错能力，即使在高并发、大流量的情况下，也能保持稳定运行。

应用服务的上下游

应用服务是系统对外提供的核心业务功能。

虽然应用服务可以独立发展和演化，但它们必须相互交互，才能实现整个系统目标。

那么，如何设计应用服务之间的交互呢？首先，我们需要了解服务的上下游概念。

1、服务上下游的概念

服务的上下游关系可以通过DDD（领域驱动设计）的建模方法来定义，主要涉及“限界上下文”（bounded context）和“上下文映射”（context mapping）这两个概念。

上下游表示上下文之间的映射关系，下游需要了解上游的领域知识来实现业务，而上游不需要了解下游。

换句话说，上游服务不需要关心下游服务的存在，但下游服务的实现却依赖于上游服务提供的能力。

这个概念听起来有些抽象，确实让许多人犯迷糊。让我们通过线上商城的几个应用服务来具体说明：

• 用户服务：管理用户的账户信息，包括注册、登录、认证、个人资料等，处理用户的权限和角色管理。
• 商品服务：管理商品的基本信息，包括名称、描述、价格、图片、分类等，提供商品的查询、筛选和浏览功能。
• 库存服务：管理商品的库存数量，处理库存的预占、扣减和回补操作。
• 交易服务：处理订单的创建、修改、取消和查询，管理订单的状态和生命周期。
• 支付服务：处理支付事务，支持多种支付方式，管理支付状态。
• 履约服务：处理订单的履约，包括拣货、包装、发货等，管理物流信息和配送状态。

如图所示，我们可以看出各个服务的上下游关系。

商品服务和用户服务是上游服务，它们提供基础数据，其他服务依赖这些数据。

交易服务位于中间位置。对于用户服务和商品服务来说，交易服务是下游，因为它依赖这两个服务的基础数据。

对于库存服务来说，交易服务也是下游，因为交易下单过程中，需要库存服务来预占、扣减库存。

对于履约服务而言，交易服务是上游，因为它提供订单数据，驱动后续的订单履约流程。

2、为什么要区分上下游？

区分上下游关系的核心目标是为了解耦。

“解耦”这个词相信大家都不陌生，但它的含义往往过于抽象和模糊。在这里，我们探讨一下解耦到底指什么。

耦合是指两个或多个结构之间的相互作用和影响。在软件开发中，这可以理解为不同模块、系统或团队之间的相互依赖和影响。

随着业务需求越来越复杂，单个系统或团队很难独立实现所有功能。因此，解耦的目的并不是完全消除耦合，而是减少不必要的依赖关系。

前面提到，上游服务不需要关心下游服务的存在，但下游服务的实现却依赖上游服务提供的能力。

因此，当下游服务的团队在迭代新功能时，无需评估是否影响上游服务，因为基于明确的上下游关系，可以快速判断不会影响上游服务。只需评估是否影响自己的下游服务。

比如，交易服务的功能发生变更时，只需通知履约服务的团队，评估是否会影响到他们，上游服务团队则无需知晓。

这种方式能大大减少影响面的评估工作，提高团队协作效率。

相反，如果上下游关系混乱，存在各种循环依赖，那么任何一个服务的改动都难以准确评估影响面。此时，就需要召集所有服务的团队，逐一评估是否有影响。

在实际场景中，如果每次项目会议都需要拉一大群人才能评估出影响面，这样的协作效率就太低了。

3、上下游关系的核心使用场景

在软件研发过程中，上下游关系在很多关键场景中都发挥着重要作用：

• 明确服务之间的依赖关系：上下游关系让开发者清晰地了解服务间的依赖。这有助于减少不合理的依赖，确保服务的独立性和模块化设计。同时，它也避免了服务间的循环依赖，降低了一个服务出现故障引发连锁反应的风险。
• 评估影响面：当上游服务变更时，可以预见其对下游服务的影响，从而制定相应的应对策略。
• 指导团队协作：上下游关系有助于明确各团队的职责和工作范围。上游团队需要考虑下游团队的需求，提供稳定的接口和服务；下游团队则需要适应上游的变化。

应用服务的交互方式

应用服务之间的交互方式有很多，最主要的就是同步调用和异步消息。

1、同步调用

同步调用是一种通信方式，调用方（客户端）向被调用方（服务端）发送请求，然后等待服务端处理完再返回结果。

在这期间，调用方会被“堵住”，直到收到服务端的响应。这种方式要求双方都在线，而且调用方在等待响应时，没法做别的事。

在微服务架构中，常用的同步调用协议包括 HTTP、REST API、Dubbo、Thrift、gRPC 和 SOAP 等。

同步调用适用于下游服务需要立刻从上游服务获取数据或功能的场景。这种方式简单直接，但需要处理服务之间的可用性问题。

举个例子，用户下单时，订单服务需要同步调用商品服务，获取商品的最新价格和库存信息，确保订单有效。

通常来说，上游服务不应同步调用下游服务。如果上游服务同步调用下游服务，会导致上游需要了解下游的领域知识，违背DDD上下游的设计原则，加深系统耦合，并增加团队协作复杂性。

此外，这种做法还可能引发级联故障，降低系统可靠性。如果上下游直接互相调用，那下游服务发生故障时，也将直接影响上游服务的可用性，可能导致整个系统都瘫痪。

2、异步消息

异步消息是另一种通信方式，消息的发送者（生产者）和接收者（消费者）通过消息队列或消息中间件进行通信。

发送者发完消息就可继续其他操作，不用等接收者处理完。消息被发送到消息队列后，接收者从队列中异步获取并处理。这样一来，发送者和接收者的处理时间就不耦合了，双方可以各自独立运作，提高了系统的灵活性和可扩展性。

在微服务架构中，异步消息通常通过消息中间件实现，比如 RabbitMQ、Kafka、RocketMQ 等。

异步消息适用于上游服务向下游服务发布事件或通知的场景，能有效解耦服务，提高系统的弹性和可靠性。下游服务也可以通过异步消息向上游服务反馈信息，实现双向通信。

比如，用户提交订单后，订单服务调用支付服务发起支付。用户完成支付后，支付服务发布一个“支付成功”的消息，订单服务接收到消息后，更新订单状态并发送通知。

3、其他交互方式

1）共享数据库方式

多个服务访问同一个数据库，直接读取或写入数据。

在微服务架构中，通常不建议采用共享数据库的方式，因为这违反了服务自治的原则，增加了服务之间的耦合度。

2）文件传输

服务之间通过共享文件系统或 FTP 等方式交换数据文件。这种方式一般适用于批处理的场景，实时性较差。

3）服务总线（ESB）

使用统一的通信总线来连接不同的服务和系统。服务之间不直接通信，而是通过总线来“中转”，适用于需要集成多种异构系统和服务的大型企业级系统。

但是，这种方式引入了额外的架构层，增加了系统的复杂性。所有服务都耦合到总线上，存在单点故障的风险。