一 背景 

整理这篇记录有几个原因，一是看到对 58 架构师沈剑的采访记录 业务架构设计迭代演进思路中对于业务架构设计和演进的一些观点；二是近期阿里要拆掉中台的消息。

二 关于业务架构

回到我们对一项新事物的分析方法（本文不做扩展描述，感兴趣可以搜索 6w3h 分析法）：是什么（what），为什么（why），怎么办（how）。那么第一个问题，什么是业务架构？

2.1 什么是业务架构

“架构”，英文单词为 architecture，来源于建筑词汇，指房屋的整体结构、框架。技术领域，我们比较了解或者说经常打交道的“基础架构”，是指偏底层，通用基础设施相关的架构。例如中间件、缓存、集群等等。基于这个理解，我们可以认为业务架构，就是基于业务场景去设计架构。

这里感觉这个描述还是比较模糊，个人认为，既然架构是指骨架，框架，那么起到的是对整体的支撑作用。那么业务架构，应该是指业务核心的抽象和设计，通过这样的设计，能起到支撑业务实现和发展的目的。

2.2 为什么要做业务架构

首先，我们要看是站在什么角色上看待这个问题。在讨论的时候，其实我们都有默认的假设，指的是开发人员。而作为一般的执行者，通常只考虑接受需求后，针对于需求去翻译为技术可实现的内容，这个过程也就是常说的技术设计。但大家都知道，这其实很可能是不够的。或者说，需要有一个大的前提，那就是技术设计是建立在良好业务架构设计的基础之上。只有这样，才能够允许开发在不需要关注整体业务的背景下，只针对于业务的局部（模块、子产品）去进行技术设计。

但即使是上述情况，设计也依然是不可能脱离业务的。“在做系统设计，在做系统架构的过程中，一定要先了解业务的特点，针对业务做系统；也一定要了解业务的痛点，通过系统架构设计去解决业务的痛点。”

如果参与的周期，包括了一个业务/子业务从开始创建到发展的整个过程，那么在不同时期/阶段、不同的用户量级、不同的发展预期，甚至不同的团队成员规模、技术水平，即使是类似的业务内容，也很可能会有不同的技术选择。那么这时，合理的业务架构设计就显得尤为重要，在一定程度上，能够屏蔽业务变更对技术的影响。尽可能是可复用、可扩展，而非一次次颠覆性的推倒重来。

2.3 业务架构该怎么做

2.3.1 具体场景

沈老师提到了三个具体的场景：

第一个场景，订单系统。早期快狗打车多个业务（2C、2B、直营城市、下沉城市等），每个业务更适合有自己独立的订单库，方便快速试错。而现在则需要统一订单中心，提升稳定性、保证扩展性，并维持较低水平的维护成本。

第二个场景，经纬度检索。司机的经纬度上报与检索，是快狗打车的业务核心之一。早期我们直接使用数据库来存储与检索经纬度，快速实现、快速迭代。如果现在还用数据库，肯定性能扛不住，所以现在则抽离了单独的服务来实现。

第三个场景，消息中心。早期 GPS 上报，快速实现了一套消息通道；订单推送，快速实现了一套；用户与司机聊天，快速实现了一套。现在，我们则把共性的需求抽象除了消息中心，以满足不同场景，在扩充业务场景的适合，能够复用系统。

2.3.2 业务架构迭代中遇到的典型问题和解决方法

“因为业务的不同阶段对架构的要求不同，在架构迭代或者重构的过程会比较痛苦，一方面要完成架构升级与转型，另一方面又不能影响业务需求的开发与迭代。”

要做到这点其实并不容易，可能出现多次拆->合->拆->合的过程。这都源于业务不同时期对架构的需求的不同。一次次升级的过渡期会很痛苦，因为涉及多个业务。多个团队的协同配合，而合作在很多公司/团队都不是一件非常容易的事情。而且每个阶段的调整，都是为了保证当前及未来一段时间的阶段性合理。

三 关于中台

3.1 起源与理解

自从几年前阿里提出“大中台，小前台”的概念依赖，就受到了不少公司的追捧。直到最近还有很多公司在开始实行中台化的策略。按照功能和角色，通常可以划分为业务中台。技术中台。数据中台 和 算法中台四种。（这并不是唯一的划分方法）

其中的业务中台，就是把各个项目的共通业务进行下沉，整合成通用的服务平台。示例如下：

3.2 业务阶段与中台选择

3.2.1 0 到 1，暂不考虑

业务初创阶段，最紧迫的是有一个可以快速展示、可用于验证的产品，所以此时需要快速实现、简单设计、很浅的封装，这时是不适合构建中台的

3.2.2 1 到 N，逐步沉淀，开始搭建

业务得到了验证，具备了一点的用户量和规模，也就是说已经处于一个相对快速的发展期，这个时候，保持业务稳定可用，支持快速迭代发展是主要目标。

为了避免继续野蛮生长导致复杂度过高到不可维护的地步，就需要逐步把业务的通用逻辑下沉，构建中台，以方便后续新项目的尝试和旧项目的迭代。这可用理解为是一个拆分，以及业务逻辑进化为能力的过程。

3.2.3 N 到 N+1，总体规划，中台成型

业务整体稳定，各组成部分迭代进化，核心业务逻辑稳定。此时适合完成比较成熟的中台系统设计与实现，支撑业务发展。

四 我们该怎么做？

首先需要明确，我们为什么要构建中台，中台的战略目标是什么？

阿里中台的战略目标：打造 统一技术架构、产品支撑体系、数据共享平台、安全体系等等。把整个组织“横”过来，支撑上层多种多样的业务形态。

中台适合场景和劣势：中台适合做“组合式创新”，没法做“颠覆式创新”。

这本身也是我们说在某些阶段适合中台，而非所有场景都适合的原因。组合式创新，是把现有几个能力进行组合，形成新的能力，它强调能力的标准化，这个恰恰是中台所擅长的。而颠覆式创新，是从根上做创新，它要打烂前台、中台、后台，颠覆现有模式和能力。无法在现有生产线上去创造，只有打破原有模式。所以，中台不支持颠覆式创新，这是中台的基因所决定的。

中台在提升组织效率、进行组合式创新等方面还是非常优秀的。所以，只要是符合这样的预期，并且我们的业务处于 1-N 或稳定阶段，那么依然可以考虑中台策略。但轻重程度可自行把控。

我们如何构建中台？个人认为，脚踏实地，一步步地做能力沉淀，多轮迭代的方式完成中台搭建是一种比较稳妥的方式。中台的实现不是一蹴而就的，不仅仅是业务的沉淀，还有组织、技术、业务层面的变革。阿里中台战略的成功，是多年服务化基础、深厚底蕴和积累支持下的产物。

从阿里中台的演进来看，中台将越来越薄，是中台发展的一个必然趋势。中台会越来越碎、越来越轻。但我们不需要恐慌，更不必跟风。阿里的策略选择是基于自己的基础、业务场景和未来的发展预期。而且，“拆中台”也只是的拆分而非拆除。无论何时，我们需要坚守自己的发展节奏，合适的才是最好的，这句话永远不会失效。对于阿里的各种战略调整，大家辩证地去看，从中汲取对自己业务有利的思想、方法、技术来完善和支持我们的业务发展就可以了。

参考资料：

https://www.163.com/dy/article/FUM7SIFQ051181GK.html