对架构复用理解分析
目录
一、复用的基本理解
二、订单服务复用构架举例
（一）基本背景
（二）一般高复用共享服务的关键
清晰的边界划分
内部的抽象设计
（三）明确订单服务的职责和功能-边界问题讨论
（四）内部状态抽象设计
数据模型设计
主状态管理
子状态开放给应用
三、一号店微服务改造案例
（一）基本背景问题和目标
（二）改造架构图
（三）改造过程简述
（四）准备阶段
圈表
收集SQL
拆分SQL
（五）实施阶段
构建库存微服务
接入库存微服务
数据库独立
（六）库存微服务架构改造图
四、中台-实现企业级能力的复用
（一）聚合外卖订单架构
（二）小程序下单架构
（三）统一订单服务架构
（四）业务中台
参考文章
一、复用的基本理解
复用是软件开发中一个重要的概念，能够显著提高开发效率、降低维护成本。在架构设计中实现系统的高可复用性需要考虑多个方面，一般包括技术复用和业务复用。
- 技术复用包括代码复用和技术组件复用；
- 业务复用包括业务实体复用、业务流程复用和产品复用。
从复用的程度可以依次划分为产品复用>业务流程复用>业务实体复用>组件复用>代码复用。
| 复用层次 | 特点 | 体会 |
|---|---|---|
| 产品复用 | 整体性，涉及整个产品或产品的大部分功能模块。 高度复用，允许在不同项目中完整地复用整个产品。 一致性，保持产品的一致性。 |
最高级别的复用，适用于公司内部产品线的开发。 |
| 在不同项目中能够保持一致的品质和用户体验。 | ||
| 业务流程复用 | 通用性，针对通用的业务流程，可在不同项目中被调用。 逻辑统一性，提高业务逻辑的一致性。 模块化，将常见的业务流程抽象成可独立调用的服务或模块。 |
提高业务逻辑的一致性和重用性。 |
| 通过模块化设计，降低开发重复业务流程的成本。 | ||
| 业务实体复用 | 数据模型，关注通用的业务实体，如用户、产品、订单等。 一致性，保持数据模型和业务逻辑的一致性。 灵活性，在不同业务场景下重复利用通用的业务实体。 |
通过抽象通用的业务实体，提高数据模型和业务逻辑的一致性。 |
| 在不同业务场景中重复利用通用的业务实体。 | ||
| 组件复用 | 技术组件，利用现有的技术组件，如开源框架、库、SDK等。 加速开发，降低开发成本，提高开发效率。 模块化，将通用的功能抽象成可重复使用的组件。 |
通过使用成熟的技术解决方案，加速项目的开发过程。 |
| 模块化设计，将通用的功能抽象成可重复使用的组件。 | ||
| 代码复用 | 代码逻辑，将通用的代码逻辑抽取成函数、类或模块。 可维护性，提高代码的可维护性和重用性。 基础层次，是复用的最基础层次。 |
最基础的复用层次，提高代码的可维护性和重用性。 |
| 避免在不同部分的项目中重复编写相似的代码。 |
二、订单服务复用构架举例
（一）基本背景
简易的O2O（Online To Offline，线上到线下）交易业务中，订单的生成渠道主要包括自有小程序/App和外卖平台。用户可以通过小程序或App进行线上下单，也可以通过外卖平台下单，这些线上产生的订单需要被同步到门店的收银系统，以便门店能够进行接单和进一步的处理。具体而言，自有小程序或App过来的订单以及外卖平台过来的订单都需要经过订单服务的处理，确保它们被有效地同步到门店的收银系统中。这个流程的关键步骤包括：
-
线上下单： 用户通过我们的自有小程序或App完成线上下单，提交订单的详细信息。
-
外卖平台订单： 可能涵盖多个外卖平台，订单以标准化的方式传递给订单服务。
-
订单服务处理： 订单服务负责处理这些不同渠道的订单，进行数据标准化和处理，确保它们符合门店收银系统的接口要求。
-
同步到收银系统： 处理后的订单信息被同步到门店的收银系统中，使门店能够在实体店面及时接单，并进行后续的交易处理。
-
实时更新： 为了保持订单信息的实时性，订单服务可能会采用异步通信或实时更新机制，确保门店的收银系统能够及时获得最新的订单信息。
通过以上流程能够有效管理线上产生的订单，确保它们能够快速、准确地同步到门店的收银系统，为线下交易提供便利和高效的支持。
（二）一般高复用共享服务的关键
打造可高度复用的共享服务的关键在于清晰的边界划分和内部的抽象设计。
清晰的边界划分
-
业务场景了解： 在设计共享服务之前，对相关的业务场景进行充分的了解是至关重要的。深入理解业务需求、各方利益相关者的期望以及未来可能的变化，为服务的边界划分提供基础。
-
划分边界原则： 制定划分边界的原则和做法，确保服务的职责明确，避免后续的争论。明确服务的功能范围，同时清晰说明服务不包括的功能，避免功能模糊和不必要的依赖。
-
基础服务不主动调用其他服务： 基础服务应该避免主动调用其他服务，以维持服务的独立性和职责的清晰。
内部的抽象设计
-
数据模型设计： 对服务内部的数据模型进行良好的抽象设计是关键。确保数据模型具有通用性，同时对外提供足够的灵活性以适应不同业务场景。
-
状态管理通用化： 在处理状态时，提供通用化的方案。可以开放状态定义，允许调用方自定义状态，或者在应用和服务共同管理状态的基础上，抓大放小，通过主状态管理把控核心业务规则。
-
接口设计规范： 为外部系统提供规范和统一的接口，确保接口名字能够望文生义。提供不同粒度的查询接口，根据返回字段的不同数量，提供粗、中、细粒度的接口，以满足多样化的查询需求。
-
异步消息通知： 提供异步的消息通知，采用“胖消息”和“瘦消息”的设计，实现订单信息的实时传递，避免服务主动调用外部系统的接口。
（三）明确订单服务的职责和功能-边界问题讨论
订单服务边界划分的核心在于明确服务的职责和功能，确保服务的边界清晰，避免不必要的依赖和职责重叠。
订单服务的核心功能包括
-
基本信息管理： 管理订单的基础信息，包括下单用户、下单商品、收货人、收货地址、收货时间、堂食或外卖、订单状态、取餐码等。考虑到多个下单渠道，需要定义通用和特定渠道的订单信息。
-
订单优惠管理： 处理订单的小票信息，包括商品金额、折扣和减免等。这些信息需要展示给用户，也可能用于后续订单成本的分摊。
-
订单生命周期管理： 管理订单的状态变化，支持通用和可定制的状态定义和状态转换过程。订单服务的状态设计要能够适应不同下单渠道和行业的需求。
订单服务不包括的功能
-
不主动调用其他服务： 订单服务作为基础服务，不直接调用其他服务。相关信息的整合可以由上层应用调用相关服务实现，或者在基础服务之上创建聚合服务来实现。
-
不负责和第三方系统的集成： 不处理和第三方系统的同步问题，这些同步功能由额外的同步程序实现，通过调用订单服务或订阅消息通知获取订单信息。
-
不提供优惠计算或成本分摊逻辑： 不执行具体的优惠计算，只负责存储和查询优惠结果。具体计算和成本分摊由专门的促销系统和财务系统负责。
-
不提供履单详情和详细物流信息： 不负责存储详细的履单信息和物流信息。订单服务可以存储外部系统的单据号码，但不解释这些信息的含义，留给上层应用或配送系统进行关联和解释。
通过这样的明确划分，订单服务的职责变得清晰，边界明确，有助于团队更好地进行服务内部设计和协作。这种边界划分的方法也可以应用于其他服务的设计过程中。
（四）内部状态抽象设计
对于共享服务，通用性是一个关键的设计目标。在订单服务这样的共享服务中，通用性的实现通常需要通过对内部数据模型和外部接口进行良好的抽象设计来实现。重点看下状态的抽象：对于订单状态管理，实现应用和服务各自承担一部分职责的具体做法是通过引入主状态和子状态的概念，从而实现状态管理的通用性和灵活性。
数据模型设计
- 订单服务的数据模型包含两个字段，主状态和子状态。
- 主状态由订单服务管理，子状态由上层应用管理。
- 子状态的具体取值由应用方定义，提供灵活性。
主状态管理
- 由订单服务负责定义和管理主状态。
- 包括主状态之间的转换规则，例如已完成的订单不能变为已取消。
- 主状态数量有限，变化关系明确，由订单服务掌握核心业务规则。
子状态开放给应用
- 由上层应用方负责定义和管理订单的子状态。
- 子状态细化了主状态，提供更具体的业务场景。
- 不同应用可以根据自身业务需求定义不同的子状态。
通过主状态和子状态的结合，订单服务在定义和管理核心状态规则的同时，为不同行业和企业提供了灵活性。不同的应用可以根据自身特点和需求，定义适合自己业务场景的子状态，而订单服务保持对核心状态管理的掌控，使得共享服务在通用性和灵活性之间找到了平衡点。这种设计思路有助于订单服务的高度复用，适应不同的业务需求。
三、一号店微服务改造案例
（一）基本背景问题和目标
商品在电商业务中扮演着核心角色，几乎所有前后台系统都需要频繁地访问这个产品库。在早期，大多系统开发人员更注重如何实现业务功能，对于数据库表的访问更注重方便性。因此，一些SQL语句可能对多张表进行Join关联。
1号店也不例外，作为一个网上超市，销售涵盖数十万种商品，包括1号店自营和第三方商家的产品。由于历史原因，所有商品相关的表都存储在一个名为产品库的数据库中，包括产品、分类、品牌、组合关系、属性、商品SKU、商家和供应商信息、库存和价格等多张表，总数量超过上百张。
尽管系统在架构上具有分布式的特征，但数据库仍然是集中式的。这种集中式的数据库访问方式带来了多方面的问题，包括系统的可维护性、性能瓶颈和对数据库的高度依赖。主要问题提炼：
- 系统开发存在功能重复建设，例如多个系统直接访问库存相关的表，导致库存逻辑分散在多个地方。
- 对数据库的访问方式导致牵一发而动全身的情况，修改一个表可能影响多个系统。
- 数据库的可用性差，慢查询可能拖垮整个产品数据库，同时数据库连接数不够用。
为解决这些问题，1号店决定进行架构改造，将大数据库进行垂直拆分，构建微服务，通过接口的方式支持数据库表的访问，以提高系统的可用性、可维护性和性能。确定目标提炼：
- 对大数据库进行垂直拆分，按照业务维度划分为产品数据库、库存数据库、价格数据库等。
- 基于拆分后的库构建微服务，通过接口的方式支持对数据库表的访问。
- 将各个业务系统统一接入微服务，实现整个商品体系的微服务化改造。
（二）改造架构图
在大型系统的微服务化改造中，涉及到多个团队和各种技术方案，良好的沟通和协作能力对项目的成功至关重要。系统改造通常需要投入大量的人力、时间和资源，而且在初期阶段，业务开发团队可能无法立即看到直接的业务价值。这种情况下，项目推进需要一定的技术领导力，以及对整个业务和技术愿景的清晰认识。
通过以往的工作经验，和上面这个案例的学习：个人认为，在系统改造中，业务和技术之间存在平衡。技术改造可能是为了提升系统的可维护性、性能、扩展性等，这些是为业务提供更好支持的基础。然而，在推进项目时，需要确保业务的正常运作，同时逐步引入技术改进。同时与业务开发团队保持透明的沟通，清晰地解释为什么需要进行系统改造，以及这将如何影响整个系统的长期健康。理解业务开发团队的需求，并提供合适的支持，以减轻他们的负担。
（三）改造过程简述
改造选择从库存微服务开始，主要原因如下：
-
库存业务重要且复杂： 库存在电商业务中是一个关键业务功能，而且库存规则通常相对复杂。通过对库存逻辑进行优化，可以带来明显的业务价值。这也符合微服务改造的初衷，即优先选择对业务影响较大、有复杂性的服务进行拆分和优化。
-
电商库存相对独立： 电商的库存概念相对独立，涉及的表也比较少。这使得库存微服务相对容易从现有体系中剥离出来。选择一个相对独立的业务领域作为切入点，可以降低整个改造过程的复杂度，有助于更好地理解和验证微服务架构的可行性。
整个改造过程分为两个阶段，分别是准备阶段和实施阶段：
准备阶段： 这个阶段主要是为微服务改造做前期的准备工作。通过圈定相关表、收集SQL、以及进行SQL拆分，团队能够更好地理解当前系统中库存的现状，为后续的实施阶段做好准备。
实施阶段： 在这个阶段，实际落地了库存微服务的开发和接入工作。通过微服务开发、服务接入和数据库独立这三个步骤，逐步完成了库存微服务的改造。每个步骤都有明确的负责人和具体工作，以确保改造的有序性和可控性。
（四）准备阶段
圈表
对于现有系统的改造，服务的边界划分主要从"圈表"入手，而不是从确定服务应该具备哪些功能入手，这有两方面的原因：
-
高效性： 通过确定服务包含哪些表，就大致确定了服务的功能。表是现成的，从表入手比从业务功能入手更为直观和高效。这种方式更贴近底层的数据模型，使得改造更容易理解和实施。
-
保持一致性： 通过从表入手构造服务，服务的边界与表的边界直接对应。这种方式避免了出现一个表的一部分字段属于库存服务，而另一部分字段属于其他服务的情况。这样的一致性有助于简化服务与表的关系，避免表字段拆分引入的额外复杂性。
需要注意的是，由于这是对现有系统的改造，为了避免引入过多的变化，对库存的表结构不会立即进行调整。表结构的优化将会在服务的升级版本中进行，以最小化对业务系统的影响。
收集SQL
在微服务改造的第二步，即收集SQL：确定库存服务包含哪些表后，收集所有业务系统访问这些表的SQL语句，包括业务场景说明、访问频率等信息。随后，库存微服务将针对这些SQL进行封装，为业务系统提供相应的接口。
在这一步，服务开发团队负责提供SQL收集的Excel模板，而各业务系统开发团队则负责具体SQL的收集。这种分工协作的方式旨在确保全面搜集系统中与库存相关的SQL语句，以便后续的服务封装和接口提供。
这一步的主要任务是建立一个全面而详细的SQL清单，涵盖了业务系统与库存相关表的所有SQL语句。在这个过程中，每个业务系统的开发团队需要积极参与，提供其系统中与库存表相关的SQL语句，同时附带详细的业务场景说明和访问频率等信息。
这种协作的方式有助于确保收集到的SQL语句是全面的，包括了系统中实际运行的各种业务场景。收集到的SQL将成为库存微服务封装的基础，需要保证其准确性和完整性。
拆分SQL
在微服务改造的第三步，即SQL拆分阶段：针对收集到的SQL语句，有些SQL不仅仅访问库存表，还涉及与产品库中的其他表的关联。为解决这种情况，需要对这些SQL语句进行拆分，确保最终提供给服务开发团队的SQL只包含对库存相关表的访问。
例如，商品详情页的SQL可能一次性查询商品基本信息表和库存表，而通过拆分，可以分为两个步骤，先查询商品表获取商品基本信息，再查询库存表获取库存数量。通过这样的拆分，库存表和其他表的直接联系被切断，业务系统在微服务落地后可以通过接入微服务完成现有SQL的替换。
SQL拆分阶段需要各个业务团队积极参与，进行相应的SQL拆分工作，以确保提供给服务开发团队的SQL符合对库存相关表的访问。虽然在这个过程中性能可能会受到一定影响，但通常问题并不会很大。
（五）实施阶段
构建库存微服务
构建库存微服务阶段，包括了接口设计、代码开发、功能测试等步骤。服务开发团队会对业务方提供的SQL进行梳理，然后对接口进行通用化设计，以确保服务的复用能力。避免为每个SQL定制一个单独的接口，以此保证服务的灵活性和可维护性。
这部分工作主要由微服务开发团队负责。第一版的服务注重接口设计和核心业务功能，以确保服务能够顺利落地，业务系统能够无缝对接。在服务迭代的过程中，可以进行内部的技术性优化，只要服务的接口保持不变，就不会对业务系统产生影响。这有助于确保微服务的稳定性和长期可维护性。
对现有系统的改造中，通过圈表的方式进行服务边界划分，以表为单位更直观地确定了服务的数据模型和功能范围。而在新服务设计中，服务的功能和边界划分通常是从业务需求出发，更注重功能的划分和设计。
接入库存微服务
一旦库存服务完成了功能和性能验证，各个业务开发团队就会逐步接入该服务，替换原来的SQL语句。这个过程主要由业务研发团队负责，虽然难度不大，但需要投入相当多的时间。
这一步的关键在于确保业务系统顺利切换到新的库存服务，同时保持原有功能的稳定性。因此，每个业务系统的接入过程需要进行仔细的验证和测试，以确保整个系统的正常运行。随着各个业务系统逐步完成接入，整个库存微服务的改造也会逐步生效。
数据库独立
一旦库存微服务接入完成，所有的SQL语句都已经被替换，业务系统不再直接访问库存相关的表。此时，可以将这些库存相关的表从原有的产品库中迁移出来，形成一个物理上独立的数据库。由于业务系统通过库存微服务来访问这些数据，因此，对于业务系统而言，这个数据迁移是透明的，业务团队甚至无需关心这些表的新位置。
通过将库存表独立成独立的数据库，在物理层面上切断了业务团队对这些表的直接依赖。同时，这也大大减轻了产品库的负担，特别是在大型促销活动期间，库存的读写压力非常大。数据库独立为库存服务后续的技术优化奠定了基础。这一步骤的完成标志着整个库存微服务的改造过程的顺利收尾。
（六）库存微服务架构改造图
改造完成后的库存微服务架构如下图所示，库存微服务一共包含了15张表，对外有30多个接口，几十个业务系统接入库存服务。平时，库存服务会部署50个实例，大促时很容易通过加机器的方式，实现库存服务的水平扩展。
针对以上总结下微服务改造过程阶段和步骤
| 阶段 | 步骤 | 负责人 | 具体工作 |
|---|---|---|---|
| 准备阶段 | 圈表 | 服务开发团队、数据库团队 | 圈定与库存相关的表，明确库存微服务所需的数据模型。 |
| 收集SQL | 服务开发团队、数据库团队、业务开发团队 | 收集现有系统中与库存相关的所有 SQL 语句，全面了解当前系统对库存数据的访问方式。 | |
| SQL拆分 | 服务开发团队、数据库团队 | 对收集到的 SQL 进行拆分，将其分为适用于微服务的独立的 SQL 查询。 | |
| 实施阶段 | 微服务开发 | 服务开发团队 | 开发库存微服务，包括定义服务接口、实现业务逻辑、确保微服务的高可用性和性能。 |
| 服务接入 | 服务开发团队、业务开发团队 | 确保业务系统能够顺利地接入库存微服务，可能涉及修改业务系统的代码以适应新的库存服务接口，并进行充分的测试。 | |
| 数据库独立 | 数据库团队、服务开发团队 | 将库存相关的表从原有的产品库迁移到新的独立库存数据库，包括数据迁移、确保数据一致性、调整微服务连接的数据库配置等。目标是使库存数据库能够独立运行，不再依赖于原有的大型数据库。 |
四、中台-实现企业级能力的复用
通过案例学习可以看到如何从订单业务出发，引入统一的订单服务，并通过共享服务和中台架构来实现业务能力的复用，从而逐步升级整个系统。演变过程如下：
（一）聚合外卖订单架构
用户在三方外卖平台（如美团、饿了么）下单；然后外卖系统通过外卖平台的API拉取用户的订单，把订单落到本地数据库；最后，门店的收银系统访问外卖系统提供的接口获取订单，在门店内部完成履单。门店履单后，收银系统会反过来同步订单状态给外卖系统，外卖系统再同步订单状态到第三方外卖平台。
外卖系统是一个单体应用，内部包含外卖同步接口和POS接口两个模块：
- 外卖同步接口负责和第三方外卖平台对接，它主要是针对不同的外卖平台做接口适配；
- POS接口负责和门店的收银系统对接。这两个模块都是使用同一个外卖订单数据库。
从数据模型上看，系统的订单模型也是完全按照外卖订单的需求设计的，订单状态管理也相对比较简单，因为这些订单都是用户在第三方外卖平台已经完成支付的。所以外卖系统主要是负责管理门店履单过程中带来的订单状态变化。
从系统架构上看，外卖系统从外卖平台接单，然后把订单推送给后面的收银系统，只需要一个应用、一个数据库、两套接口就可以支持，使用单体架构就能很好地满足外卖的接单需求。
（二）小程序下单架构
随着公司业务的升级提供了自有小程序的下单服务，不同于三方外卖订单，小程序下单平台是一个完整的业务，它包括小程序用户注册、商品和菜单浏览、商品加购物车、在线支付等等。
小程序订单被当作一个特殊的外卖渠道，把小程序订单推送到外卖订单库里，最终还是由外卖系统来对接收银系统，也就是相当于小程序订单直接借用了外卖订单的履单通道。
小程序的订单处理就嫁接在已有的外卖系统上，小程序下单平台和外卖系统相对独立，同时为了更好地解耦，小程序订单服务和外卖系统之间是通过消息系统同步订单数据的。
通过复用外卖订单的履单通路实现了小程序订单的闭环处理。表面上看节省了重新搭建系统的成本，也快速落地了小程序交易这条新业务线。但这样的架构实际上是一种妥协，引发问题问题：
- 两套订单系统，一套针对小程序订单，一套针对外卖订单。两者的字段属性和订单状态定义都有不同，把小程序订单套在外卖订单模型中限制了小程序订单能力的扩展。
- 小程序订单处理链路过长，从小程序服务端->订单服务->小程序订单数据库->消息系统->外卖同步接口->外卖订单数据库-> POS接口->收银系统，一共包含了8个处理环节，系统整体的性能和可用性都存在很大问题。比如，取餐码已经从收银系统同步给了外卖系统，但由于消息队列堵塞，外卖系统不能及时同步给小程序的订单服务，这样导致了小程序用户不能及时地看到取餐码。
- 为了使两套订单系统解耦，使用了消息队列在两个库之间同步订单数据，这降低了系统整体的稳定性。实践中会发生过多消息队列故障导致的线上事故。
这些问题的根源是把小程序订单硬塞给外卖系统，一方面订单数据模型不匹配，另一方面由于两个系统的简单拼接导致系统调用链路很长，影响了业务的扩展和系统的稳定性。
（三）统一订单服务架构
把小程序订单服务提升为统一共享的订单服务，由它来落地所有类型的订单。对于统一订单服务来说，外卖订单、小程序订单，或者是其他的新订单，都是它的下单来源，所有订单汇总在订单服务里，然后统一提供给收银系统进行履单。
系统架构升级的关键特点和优势
| 特点 | 描述 |
|---|---|
| 多渠道支持 | - 支持多个下单渠道，包括聚合外卖服务和小程序等。 - 可轻松增加新的下单渠道，如支持App下单。 |
| 灵活的后台履单处理 | - 各下单渠道的订单处理方式灵活，支持新增电子卡券类订单可直接由企业的OMS系统处理。 - 实现业务时只需新增一个适配应用与OMS系统对接。 |
| 全渠道交易平台 | - 不仅是外卖订单和小程序订单处理平台，演变为全渠道交易平台。 - 能够适应不同渠道的订单处理，保持整体灵活性。 |
| 订单处理链路优化 | - 订单处理链路从小程序服务端->订单服务->订单数据库->POS服务->收银系统，缩短至5个节点。 比之前减少了3个节点，提升了系统的可用性和端到端性能。 |
| 统一订单服务的优势 | - 统一订单服务实现了订单属性定义和订单状态管理的统一。 - 订单数据集中存储，提供便利的数据访问接口。 - 为后续的BI分析和数据中台建设提供有力支持，简化了数据处理流程。 |
（四）业务中台
上面的统一订单服务整合了外卖和小程序的订单，并且为新的下单渠道预留扩展。按照同样的思路，可以构建统一的商品服务，同时满足外卖和小程序上商品的管理；可以构建统一的促销服务，同时支持线上和线下的促销活动；也可以构建统一的库存服务，实现线上和线下库存的同步和共享等等。
通过构建这样一系列的共享服务，就实现各个渠道业务规则和业务数据的统一管理，最终落地了一个强大的业务中台，可以很方便地扩展各个业务，实现企业整体业务能力的复用。
参考文章
1.架构实战案例解析_架构案例_后端架构-极客时间
2.08 | 可复用架构案例（一）：如何设计一个基础服务？-CSDN博客
3.架构设计之复用性概谈-腾讯云开发者社区-腾讯云
4.四种软件架构：单体架构、分布式架构、微服务架构、Serverless架构 | 戴树谦的博客
5.服务怎么划分 - 微服务架构设计
6.架构设计：为什么说复用是邪恶的？-阿里云开发者社区
7.微服务业务体系内对复用的深度探讨 | QCon+-腾讯云开发者社区-腾讯云
8.8. 案例：从 0 到千万级用户亿级请求微服务架构历程 — zjt-blog 文档
9.从复用、架构和业务管理视角下看中台的对与错 - 知乎
10.微服务架构设计模式（一）逃离单体地狱 | 俺的部落格
11.架构（二）：如何对现有系统做微服务改造？_单体系统 微服务改造步骤-CSDN博客
12.1号店交易系统架构如何向「高并发高可用」演进_wx61d83844dd579的技术博客_51CTO博客
13.前1号店技术总监黄哲铿揭秘：微服务架构在千万级别日调用量、亿级别海量数据场景下的应用实践-腾讯云开发者社区-腾讯云
14.1号店11.11：从应用架构落地点谈高可用高并发高性能_语言 & 开发_张立刚_InfoQ精选文章
15.10 | 可复用架构案例（三）：中台是如何炼成的？-极客时间
16.企业中台建设需要哪些能力？
17.我对中台的定义：企业级能力复用平台 | 人人都是产品经理
18.关于中台建设的理解及建设策略-阿里云开发者社区
19.进击的中台，组织的砺炼：互联网大厂的“中台战略”剖析-36氪
20.啥都复用不了，还谈什么中台？ - 环信
21.一文读懂什么是中台？什么是数据中台？-腾讯云开发者社区-腾讯云
22.大厂拆中台，你的企业还需要中台吗？-茅庐学堂
23.中台是企业架构的又一次实践吗？_中台_涛哥 数字产品和业务架构_InfoQ写作社区
24.构建知识中台，赋能业务场景-深蓝KMPRO软件
25.业务中台、技术中台、数据中台、AI中台-亿信华辰
26.阿里为什么开始拆”中台 - 锦囊专家 - 数字经济智库平台
27.中台是什么意思？一文读懂互联网中台概念 - 爱盈利