SaaS架构：应用服务、应用结构设计

这篇文章介绍了SaaS架构：应用服务、应用结构设计，分享给大家做个参考，收藏极客之家收获更多编程知识

大家好，我是汤师爷~

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

• 根据业务架构，将业务需求转化为IT系统，识别核心应用服务。
• 划分应用结构，设计应用结构与业务流程、数据之间的关系。
• 设计应用结构之间的交互和集成关系。

本文主要分享一下应用服务、应用结构设计设计。

应用服务设计

应用服务的概念

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

应用服务应明确定义其责任范围，将相关业务功能和对象组合在一起，避免暴露内部细节。它需要整合因同一原因变化的功能和数据，同时分离因不同原因变化的部分。这种设计方法确保了服务的内聚性和灵活性。

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

应用服务如何划分？

应用服务在应用架构中起着至关重要的作用，它将系统的核心功能”打包“，并提供给外部的业务流程使用，可以视为SaaS系统对外的“门面”。

用户或其他系统通过调用应用服务来实现特定的业务功能。那么，如何设计应用服务呢？

1、对齐业务能力，设计颗粒度适中的服务，职责单一，避免跨服务调用。

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

通常情况下，每个业务能力都对应一到多个独立的应用服务，同时每个应用服务也支持特定的业务能力。如图所示。

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

2、围绕业务对象，提供具体的业务功能，具有明确的业务含义，不能包含不相关的功能。

从外部视角看来，应用服务通常是带有明确的业务含义，一般围绕某一个或一组密切相关的业务对象业务对象操作，不应该包含不相关的业务功能。

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

3、服务可注册、可监控、可度量

应用服务的公共 API 应注册到 API 管理平台，形成一份服务列表，供消费者订阅调用。

应用服务对外提供服务时候，应能监控其运行状态，并支持启停操作。同时，服务应可度量，包括订阅数量、调用次数、响应时间等指标。

服务化架构的价值

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

敏捷性体现在服务可以快速调整，独立演化。

灵活性则体现在每个服务都有清晰的业务边界，功能内聚性强，能够单独管理生命周期。具体来说：

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

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

如图所示，订单履约能力是零售企业业务能力地图中的 L2 业务能力。订单履约能力可以细分为多个末级业务能力：ToC 履约服务、订单派单、订单管理、拣货管理、发货管理和履约逆向。

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

应用结构设计

应用结构描述了应用服务内部的层次结构和组织关系，它决定了系统的模块化程度，以及后续的开发和维护难度。

应用结构的抽象层次

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

这种抽象级别的划分帮助我们在不同层面处理复杂性，确保系统结构清晰且易于维护。如图所示：

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

抽象级别的存在，主要是为了帮助我们更好地管理系统的复杂性。

1、分解复杂度

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

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

2、团队协作边界清晰

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

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

3、扩展性强

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

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

应用结构如何划分？

在前文中，我们提到应用服务的设计方法，那么应用服务如何通过一步步转化为代码结构呢？

应用服务会由一系列的应用结构来实现。如图所示。

基于应用服务的划分方案，我们可以进一步细化应用结构，以便更好地组织和管理系统功能。

这个过程涉及多个层次的设计方法：

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

在上述设计方法中，一个应用服务可以单独部署，也可以多个应用服务组合在一起部署。

那应用单元有哪些划分的具体原则呢？应用的划分原则可以参考以下：

1、业务划分原则

最关键的是参考应用服务的划分边界。如果需要提高应用的粒度，可以参考业务域和业务子域的划分。

将相同业务变更因素的功能和数据整合，提升系统内聚性。同时，把不同业务变更因素的功能和数据分开，减少系统耦合度。

2、技术划分原则

在业务初期，尽量从单体应用开始，避免过早划分应用单元，以减少分布式数据库事务和数据不一致的问题。

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

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

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

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

应用层定义软件的应用功能，它负责接收用户请求，协调领域层能力来执行任务，并将结果返回给用户，核心模块包括：

• C端履约服务
  • 预计送达时间：为消费者提供订单的预计处理时间、配送时效等，通常基于订单处理时间、配送情况、配送距离等多种因素计算。
  • 实时订单状态查询：允许消费者实时查看他们的订单所处阶段。包括订单待接单、拣货、打包、已发货、配送中等状态。
  • 配送轨迹跟踪：提供订单从出库到最终送达的完整路径跟踪，消费者可以查看订单的当前位置和过往的配送节点，了解配送进度。
  • 配送信息修改：在订单还未最终发出之前，消费者可能需要更改配送信息，如地址或配送时间。
  • 配送费用明细：显示消费者的订单配送费用的详细分解，包括配送费、包装费、服务费等。
  • 确认收货：消费者可以通过系统确认收货，是完成订单流程的最后一步。
• B端管理模块：
  • 订单派单：接收来自销售平台的订单，并按照既定规则自动分配给对应的门店/仓库。
  • 订单管理：全面管理订单的生命周期，包括订单的确认、处理、状态跟踪、修改和取消等管理操作。
  • 拣货管理：管理仓库内的拣货操作，确保商品被准确无误地从货架上拣选出来，并进行打包和发货。
  • 发货管理：全面管理发货单的生命周期，根据订单的地址、商品大小、重量和客户选择的履约方式，匹配合适的发货方式，并对发货流程进行跟踪。
  • 逆向履约：当客户不满意或需退换商品时，逆向履约模块负责处理退货请求，并管理退货退款和换货流程。

领域层是业务逻辑的核心，专注于表示业务概念、业务状态流转和业务规则，沉淀可复用的服务能力，模块包括：

• 履约服务表达：负责向客户提供履约服务的明确信息。包括预计的送货时间、费用计算、服务选项（如定时达、次日达等）以及履约可达性要求。
• 订单履约调度：提供订单履约调度的核心能力，确保订单被高效地处理和执行。它涉及订单从接收到最终准备配送的所有调度和处理过程，包括订单拆分、分配、拣货、包装、发货等。

订单履约系统与其他系统的依赖关系：

• 商品管理系统：提供的商品信息，包括价格、规格、描述、分类、SKU等。
• 中央库存系统：需要访问中央库存系统来确认下单商品的实物库存情况，包括库存数量和库存位置。
• 配送系统：一旦商品打包完成，将依赖配送系统来处理商品的实际配送工作，包括配送安排、跟踪和状态更新。配送系统提供的配送状态和时间信息，对于订单履约系统中订单状态的更新至关重要。
• 基础数据系统：提供组织机构信息、用户权限信息、服务商信息等基础数据。这些标准化的数据确保各个系统数据的一致性
• 数据分析系统：订单履约系统将产生大量数据，包括订单数据、履约过程数据、配送时效数据等，这些数据需传输到数据分析系统。数据分析系统基于采集到的数据，提供分析与洞察，帮助优化订单履约流程，提升客户满意度，并提供预测分析，来辅助库存管理和需求预测。

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

版权声明：本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！