一文搞懂SaaS应用架构：应用服务、应用结构、应用交互设计

技术分享 1个月前 (10-22) 0 999+

关注

大家好，我是汤师爷~

今天系统性地聊聊SaaS应用架构设计。

应用架构概述

我们已经完成了SaaS系统的定位分析，明确了系统的目标和核心能力。这为接下来的应用架构设计奠定了基础。

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

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

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

应用服务设计

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

应用服务的概念

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

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

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

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

应用服务如何划分？

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

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

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

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

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

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

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

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

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

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

服务化架构的价值

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

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

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

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

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

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

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

应用结构设计

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

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

应用结构的抽象层次

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

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

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

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

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

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

1、分解复杂度

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

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

2、团队协作边界清晰

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

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

3、扩展性强

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

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

应用结构如何划分？

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

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

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

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

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

1、业务划分原则

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

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

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

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

2、技术划分原则

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

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

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

3、组织规模原则

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

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

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

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

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

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

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

应用交互设计

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

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

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

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

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

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

应用服务的上下游

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

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

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

1、服务上下游的概念

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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