阿里中台设计流程及方法.docx

阿里中台设计流程及方法.docx

《阿里中台设计流程及方法.docx》由会员分享，可在线阅读，更多相关《阿里中台设计流程及方法.docx（11页珍藏版）》请在冰豆网上搜索。

阿里中台设计流程及方法

数字化转型案例

阿里中台设计流程及方法

在过去几年中台项目的实践中，我们团队积累了一套成熟的中台服务中心建设思路，该思路包含了从业务调研到中台设计开发的标准流程和方法论，值得企业在进行中台建设时参考。

我们把业务中台的落地方法总结为一个流程图，如图4-1所示。

从业务的调研与规划开始，到产出中台设计，大致步骤包括：

1）调研与规划。

2）需求分析。

3）中台设计。

4）开发实现。

（1）调研与规划

业务的调研与规划目标是，从发展角度去看企业当下的业务运营情况和未来的业务规划。

这一步非常重要，业务规划的长远度决定了业务中台的高度。

所以这里要求业务方综合考虑企业自身的特性、新技术应用、新业务发展趋势等方面。

这里列举一个零售行业某企业的例子，如图4-2所示。

从这个业务规划中，能明确看到企业中台建设的总体规划，在不同阶段对于会员、库存、营销以及供应链方面的业务诉求。

有了规划，接下来的中台分析设计就更加有的放矢，不会出现目标混淆和不可持续发展的问题。

（2）需求分析

业务规划之后就是需求分析，单纯从中台设计的角度来说，需求分析更关注粗粒度核心业务流程，并不关心业务层面具体的用户交互和功能细节需求。

一般业务系统和中台架构设计的需求调研都是同步进行的，所以这里也不用分得太清晰。

需求分析的目标是，从业务规划的各种业务场景出发，梳理核心业务流程。

业务流程的粒度需要包含这几类：

业务角色、业务实体、业务规则、已经存在的业务系统的接口、外部系统或者平台的服务和接口。

这个过程是边梳理业务流程边识别业务实体，两者相辅相成。

（3）中台设计

从需求分析到中台设计有两条路径，如前面图4-1所示。

路径A是从业务域分析开始的完整过程，经过流程分析、时序图分析和聚合分析，最后得出中台设计方案；路径B针对业务比较明确和相对简单的场景，或者行业已经有类似的业务沉淀（行业模型库），可以基于这些模型库进行迭代，直接基于已有的方案开始迭代推演。

下面我们演示路径A的方法和过程。

这时就会遇到企业客户经常提出的问题—我们的公司到底需要几个中心？

这些中心怎么出来的？

这些中心是什么样子？

中台设计一般分两个阶段：

业务中心分析和业务中心设计。

业务中心分析是从业务流程纷繁复杂的业务场景出发分解出目标业务中心，业务中心设计需要完成中心的概要设计和详细设计。

阶段1：

业务中心分析

这一步需要架构师具有深度的行业业务理解能力和软件分析设计能力，中台既是前台业务的基石，也是衔接前后台业务的中枢，所以中台设计一定要从企业核心业务场景和流程出发。

第一步，识别整个体系中最核心的业务流程，如图4-3所示。

从这些流程出发，分析流程中参与进来的关键业务和数据实体，一一列举。

从核心到边缘，从前台到后台、从后台到前台，正向流程、逆向流程，正常流程、异常流程，完整分析之后，你会得到一个企业业务实体的全景图，这个图包括用户、会员、企业组织架构、商品、交易（批发、零售），等等。

这个过程做得越细越好。

在这个过程中，不要给自己设定用户中心、商品中心的概念，这时候你的眼里应该没有中心和业务系统的边界，只关注流程和实体本身。

流程梳理完全是从具体业务场景出发，忠实于用户期望的业务需求，不要被现在实际的流程和系统所束缚。

图4-4展示了O2O场景下一个线上下单、线下物流送货的处理流程中，把所有跨系统流程全部梳理后得到的流程全景图。

第二步，把第一步分析的业务流程全景图聚合分析，从不同业务领域来归纳分析产生的业务和数据实体。

这时你会发现，整个大图中最关键的那些业务实体与绝大多数的流程都有关系，而且和绝大多数的业务场景都有交互。

通常，这时你所要找的适合纳入中台的业务领域就呼之欲出了，比如会员域、商品域、交易域、库存域，等等。

这时就可以初步确定中台的基本轮廓。

图4-5是从上面梳理的业务流程全景图出发，分析流程中的主要业务对象，归类整理形成核心业务域，这些业务域将成为下一步服务中心设计的基础。

第三步，对这些初步确定的业务域进行进一步分析，分析业务域相互之间的依赖关系、复杂度、实体之间的亲密度等。

不同业务场景得到的结果可能大不一样，例如，有的企业积分营销活动还不是很规范，也不成熟，在第一、二步的分析中可能会把积分账户放在会员域，因为用户注册时会赠送初始积分，这是很自然的事情。

而有的企业营销活动非常成熟，会员消费行为会导致积分账户变化，同时积分营销活动又会消费积分，所以会把积分账户放在交易域。

这一步需要基于一些服务化设计原则（参见后面的“服务化设计原则”部分）把这种初筛后的业务域的边界清晰化，有些需要把某些实体从A业务域放进B业务域；有时需要去伪存真，把一些噪音型的对象剔除，让它们回归本来的前台或者后台；还有一些需要火眼金睛，把本该进入但是却由于业务场景覆盖度不够暂时没有进入业务域的业务实体有预判性地拉进来。

这一步需要架构师有丰富的分布式架构、服务化设计、中台设计的经验。

基于上一步的产出再用时序图的形式分析应用与业务域之间的关系，如图4-6所示，如果做得细致一点，这个过程可以进一步细化出调用过程之中参与的业务实体。

注意，这里的时序图是基于业务域得出的，不是旧有系统依赖关系的时序图。

分析业务规划中的业务场景和用例会产出完整的基于中台业务域架构的调用关系，再把这些时序图按业务域进行分类归集。

时序图中和业务域的每一次交互算一次“触点”，按业务域把所有触点进行聚合，如图4-7所示，通过触点数我们可以直观地看出来这些“业务域”的活跃度以及与业务场景的依赖程度。

这时可以结合上节介绍的判断标准、团队的资源以及业务规划，定义出第一批可以升级到“中心”的业务域。

通过业务域与实体对象之间的依赖关系、业务域复杂度、业务实体之间的亲密度对业务域做进一步的聚类，这样就可以将每一个业务实体归类到合适的业务域。

通过这三个步骤，基本可以确定在当前规划的业务场景下，我们的中台到底应该有几个中心，分别是哪些中心。

从业务调研得出中台服务中心的设计，这一步现在很多企业做得非常随意，一般都参考一些互联网公司的实际经验或者基于自己对中台的理解，看到相关的流程就照搬过来，结果很可能会“水土不服”。

在这里，我们推荐的方法是从企业的实际情况和具体需求出发，进行科学分析，从客观分析中总结得来。

阶段2：

业务中心设计

阶段1分析出了有几个中心以及中心边界，这一阶段要完成中心的详细设计工作。

在这个阶段中，不是简单地根据业务需求划分模块后把这些模块落到中台层就是中台了，这样设计出来的中台只是具体的业务模块下沉，缺乏抽象建模的过程，让中台的能力和扩展能力都非常有限，这不能成为称职的中台。

业务中台一定要经历从具体到抽象的建模过程，中台设计的核心是对业务抽象建模。

服务中心是业务中台最核心的架构元素，看起来和原来的应用系统的模块名称差不多，但是在本质上提升了维度。

中心是拉通所有前后端系统的相关功能模块，进行统一抽象设计，用一个统一的模型去支持前后台不同业务场景的需求，如图4-8所示。

我们从三个维度来描述一个完整的业务中心设计：

业务模型、数据模型、服务能力，一个服务中心通过业务模型描述业务承载逻辑，通过数据模型描述数据的底层规范，通过服务能力描述服务接口契约。

通过这三个维度明确一个服务中心的设计，每个服务中心设计说明书要产出这三个核心概念。

图4-9是一个会员中心的设计示例。

维度一：

业务模型

业务模型是一个比较难直接定义的概念，我们拿一个实际的例子来说明。

一家多业态经营的房地产企业，旗下有传统的商业地产、住宅、物业，随着业务的拓展也有酒店、旅游门票，甚至会发展出社区零售的业务。

如果这家企业选择中台架构，那么商品中心应该是什么样子？

从任何一个单一维度去看这家企业对商品的需求，可能差异都非常大，商业地产类的商品是租售的铺位，住宅类的商品是商品房，物业是服务类商品，酒店和旅游门票是类似于电子凭证类的虚拟商品，社区零售是通常意义上的百货商品。

我们对这些商品模型进行每种业务场景的建模，都会面对这些模型的业务术语、模型结构，它们完全不一样。

地产商品属性特别多，商品描述复杂但是模型结构单一，需要支持复杂组合查询；社区零售类商品种类会比较多，变化比较快，用户并发量较高，商品描述结构都比较简单；酒店和旅游门票类商品要求分类特别清晰，简单易管理。

如果基于“烟囱式”架构来设计，针对这几种商品都可以推导出相应的模型。

如果用中台架构，就需要对这几种业态的商品模型需求进行再一次抽象，用一个通用的模型支持多种场景需求。

可以用主子类目来满足商品分类管理需求；用产品、属性、属性值、子属性来满足多业态商品多样化描述需求；用标签来支持商品离散化管理需求；用前后台类目分离来满足基于前台类目的营销和基于后台类目管理的需求。

通过这样的抽象，我们建立了如图4-10所示的业务模型。

注意，基于这样的方法设计的业务模型，需要与上层业务对接的业务术语做一个统一。

比如，对于地产类业务，如果原来是基于项目、分期、楼栋建立的树形结构，就要对应到现在的类目体系上（对地产业态建立业务约束规范实现对接）；如果原来是社区零售业务，应该对应到现在的商品类目管理体系下，这就是中台的业务模型。

商品偏于主数据模型结构，但是不要因此就误以为服务中心的模型都是主数据模型，交易时要统一交易流程，营销时要统一规则：

针对不同的业务领域，有不同的建模诉求；基于业务但一定要高于业务。

如果做不到模型层面的抽象统一，那就只是具体业务形态的模块下沉，中台的价值难以发挥。

维度二：

数据模型

数据模型是服务中心底层的数据层实现，包括OLTP和OLAP两种场景。

根据业务的需求，可能需要结合分布式数据库技术。

与交易相关的业务场景中，最常见的数据模型方案是定义实体关系模型，如果对扩展性有要求，则可结合分布式数据库技术形成方案。

数据模型的第一个职责是明确数据的业务规范，为业务数据化和数据中台建设做好基础准备工作。

维度三：

服务能力

服务能力是中台业务能力对外的服务契约，外部系统通过接入中台的服务来使用中台。

服务列表包括两部分：

第一部分是针对中心的外部用户部分，这部分要明确服务的接口契约，包括使用的通信协议、安全鉴权方案、服务的请求报文和响应报文、服务的具体业务含义以及调用的上下文、异常情况等；第二部分是服务的开发实现，这部分内容需要设计者画出服务的业务流程、业务边界、异常处理等。

上面已经完成了中台的设计，在进入具体的开发之前，为了保证设计的中台模型能满足真实的业务场景，最好将中台的服务放入具体的业务流程中进行验证，也可以基于服务的mock实现来进行验证。

这个过程可能比较烦琐，但是通过这个验证过程，可以发现中台的业务模型抽象是否正确，使用是否方便，服务是否完整，发现设计中模型的问题，再快速迭代修改。

如果所有的业务场景都能通过这样的验证，那么中台的设计方案是可行的。

（4）开发实现

开发实现基于服务接口规范、数据模型和业务流程进行，当数据模型和服务能力都具备后，开发者就能进行详细设计和开发了。

这里并没有特殊之处，但需要开发人员掌握分布式、服务化相关的一些开发原则和技术，特别是在分布式体系下，引入了一些在传统一体化架构体系下不太关注的技术原则，比如分布式事务、异步、幂等问题。

相关技术可参考《企业IT架构转型之道》一书。