架构设计-业务中台的方法论

参考：

https://www.sohu.com/a/331004369_692515

http://blog.sina.com.cn/s/blog_493a84550102z8uw.html

https://zhuanlan.zhihu.com/p/94941463

学阿里中台，就要学最值钱的部分：中台建设方法论！

阿里研究员--玄难，曾在《从应用到中台--业务平台的演进》的分享中提到，阿里中台化主要解决4个问题：

1、信息获取成本高

2、互联互通成本高

3、服务具有不确定性

4、低水平重复建设

如何来解决这些问题呢？可以去看一下传统的建筑行业和互联网本身的基础设施建设。基本上靠三个东西来共同解决一个复杂生态的协作问题：

1、协议标准、运行机制。

2、满足标准的分布式执行单元。

3、中心化的控制单元。

比如说移动互联网，我们现在之所以上网能用手机，它的根本是什么呢？网络的协议，就是我们整个对网络的理解，它是最基本的思考。

然后我们有很多设备，不管是什么品牌的手机，只要满足3G协议、4G协议，就可以插上卡上网。也就是通过这张sim卡确定了我们的身份，从运营商控制网络上获取了控制信息。知道我们是谁，能不能上网，网络速率等等信息。

阿里中台建设的基础协议

回头来看阿里的电商生态，就是要根据对商业的理解，把一些基础协议梳理出来。例如什么是业务？什么是业务身份？各个业务领域的边界是什么？每个领域提供的基础服务是什么？领域服务和领域服务之间的流程链接标准是什么？再在这些思想的指导下去建立业务平台化的实施标准和业务管控标准。

电商业务中台由一系列：业务能力标准、运行机制、业务分析方法论，配置管理和执行系统以及运营服务团队构成的体系，提供各业务方能够快速，低成本创新的能力。

中台基础设施：中心化控制单元

中台建设需要一个中心化控制单元，就是我们的运营平台。它主要由协议标准、能力地图、业务需求结构分解、全局业务身份、业务全景图、业务度量等构成。能让我们有一个地方纵观全局，把控细节。

其中能力地图是一个最基础的设施，要能把电商生态里面的能力都呈现出来，并在过程中不断的优化完善。就象我们现在出行离不开XX地图一样，今后所有的业务方需要做业务规划，业务创新，都可以到这儿来寻找需要的基础能力。

为了能将业务逻辑本身与实现逻辑分离，可以将业务逻辑下发给不同实现的执行系统，引入竞争，方便业务平台的改造升级，我们要将控制信息从业务平台中抽离到业务中台，以业务身份为主线来进行组织管理和呈现。并以生态角色的视角来重构信息架构。这样的变革对我们原来的系统架构提出了更高的要求。

通过业务中台化，我们把所有业务的数据汇集沉淀。每个业务它是怎么出来的，出来之后做了哪些业务需求，业务活动，每个业务活动的效果是怎么样的，都可以沉淀下来。

当一个新业务来了之后，我们就可以让他看到前人成功和失败的经验。逐步可以做一些系统建议，建议他怎么去做营销活动，怎么做效果分析。这样我们能通过数据最终反过来支撑我们的业务创新。

业务平台是在最基础技术和前端大家能感受到交互技术中间的一层。这一层不是外部消费者和入门级技术人员能直接感知到的。但是这一层才是真正制约我们整个商业发展速度的核心地带。业务平台如何能支撑几千种业务，几万人在同一个时间里面进行变更，这个对业务业务的抽象能力和系统架构能力的要求都是极高的。

中台化的核心目的是降低成本

阿里中件间&业务中台总监，谢良纯，在采访中提到，中台化的核心目的是降低成本。成本可以从两个维度看，一个是资源浪费方面的成本，即公司有三四个业务线都在做同样的事情了，那技术上实现能不能融合可复用的部分？另一个则是时间成本，即新业务能够足够敏捷地去使用既有的技术模块去做探索。

实际上，实现中台化的环境是相当苛刻的。连Supercell 的 Paananen 自己都说，他认为Supercell 的经验不是对所有公司都有效，有它自己的特殊性。他觉得 Supercell 的每个员工，都是能在外面成立公司自己当老板的，因此这种精英文化和中台化在公司得以保持。

国际知名咨询公司罗兰贝格高级合伙人王欣曾表示，当企业发展到一定规模，一定会开始思考两个问题：第一，组织是否存在重复建设和资源浪费；第二，如何沉淀企业核心竞争能力，以更好地支撑新业务的发展。这也是许多企业选择中台的原因，中台在本身定位上，具备了以上先天优势。

有了前台和后台，为什么还需要中台？

行业观察员王健，曾撰文分析企业为何需要中台，企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题。

大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。

我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。

总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。

中台就像是在前台与后台之间添加的⼀组“变速⻮轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。

中台很像Pace-Layered中的SOD，提供了比前台（SOI）更强的稳定性，以及⽐后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。

中台作为变速齿轮，链接了用户与企业核心资源，并解决了配速问题。

有了“中台”这⼀新的Pace-Layered断层，我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应⼒；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”⽀援。

所以，企业在平台化的过程中，需要建设自己的中台层（同时包括技术中台，业务中台和组织中台等等）。

中台建设要避开哪些“坑”？

阿里专家谢良纯在采访中曾提到，现在在中台建设里面，常见的一些“坑”，有以下几个：

1、要真正树立一个认识：中台是企业IT 变革的一个起点，而不是单纯认为，我就是做一个项目，我搞一个采购中台，就解决了所有的问题，非也。你要深刻意识到它是变革的关键，认真去做战略规划，应该采用什么样的技术、什么样的平台、什么样的人员的配套？需要有这样统一的规划。把一个项目当成一个中台去做，这是不合适的，但如果倒过来，我规划了一个中台，做一个项目的试点，这是对的，所以这就是一个认识的问题，不见得多投多少。把项目当成中台去做，这个“坑”是很多人容易踩上的，这是一个最大的坑。

2、第二个“坑”发生在选择中台的技术平台时，很多人想，我先选一个便宜的能用的平台，以后我再选一个复杂的、更全面的平台。事实上，他们不知道，这就跟“种菜”似的，一旦菜长起来了，你要把底下土壤换了，这几乎是不可能的事情，一般要推倒重来。你一定要相信一点，如果开源软件就能简单解决这么复杂的大问题，阿里还养那么多技术专家干什么？在选择技术平台这一块，这是一个大家踩的最多的一个“坑”。

3、第三个坑，我认为也是一个坑，我觉得大家对试点、试点项目这块不太重视，往往会抱有这样的想法“反正是试点、就试一试“。在中台建设里头，我觉得试点项目是非常重要的，你一定要抱着必胜的态度去做试点。因为中台的建设会涉及到技术升级、业务升级、组织升级等很多变化，你只有抱着必胜的这样一些态度去做试点，那这些相应的变化，你才能应对好，否则到最后你就凑合做个试点，大概率是失败的。

中台建设难题一：中台团队离业务远

公众号作者刘飞曾撰文指出，中台团队离业务远的问题。

为什么中台化的难度是：技术<数据<业务<组织？因为越往后，越需要业务团队的介入，越要有业务认知才能做到中台。而中台团队，天然就是离业务远的。

各公司跟中台团队的协作，都存在很大的低效问题，一线的前台业务团队，要反复与中台沟通，才能讲清楚业务需求的背景，在大公司，跨部门协作都会徒增成本。另外对于中台业务团队来说，长期离业务很远，没有成长性，在判断需求时也不准确，很难获得前台业务团队的信任。

久而久之，就变成了中台团队纯支撑、被动接需求的状态，成为“鸡肋中台”。更大的问题在于，中台团队的价值就是整合需求、抽象能力的，在对用户和业务不够了解的前提下，这块就会做得特别吃力。如果是多个前台业务的需求有了冲突，中台团队未必能做好协调，多方要反复沟通扯皮。

针对这个问题，通常有两个解决方案：

第一，中台职责直接由最大业务方来担任

像某找房App的中台模块，就是由二手房先行推进的；而大多数通用的乘客司机产品流程，在滴滴也都是快车先发起的。最大的业务方离业务足够近，能自己决策判断大多数需求，更加高效。

这样以来，就从“硬找一个中台团队来收集大家需求”变成了“老大哥发挥余热，把自己的能力共享出来”，具体要怎么用，仍然是各自团队来决策和执行。

第二，让中台团队做业务闭环

这只适用于少部分情况，即中台业务本身可以自闭环。常见的比如各公司的账号体系（包括注册登录）、阿里的支付和订单流程、滴滴的地图和导航。这些业务与其它业务的关联度不大，可以解耦，可以自己完成从用户到业务的认知和决策，那就可以独立出来自己做，其它业务希望使用的时候，对接通用接口就可以了。

而大多数中台团队负责的业务不太容易自闭环。比如滴滴不同业务线的接单流程，就很难抽象出来让中台团队直接闭环自己做；或者像阿里不同业务线的商品部分、订单流程部分和支付部分可以抽象，但用户体验方面，不同前台业务差异太大，则很难抽象。

中台建设难题二：中台需求优先级难排序

互联网技术和管理专家黄哲铿，曾撰文阐述过这个问题主要的两个解决办法：

建立以价值为导向的需求治理机制
基于OKR的需求聚焦与创新

第一，建立以价值为导向的需求治理机制

以价值为导向的需求治理机制，其目的是把有限的开发资源，投入到更有价值的项目上，该机制分成几个部分：

建立需求管理闭环。以价值为导向的需求治理机制，是在需求提报环节，提出该需求的价值预估，即这个需求将给业务带来什么样的价值，这些价值要能够量化、能够追踪。比如，一个结算系统需求，价值是：提升客户对账效率20%，上线后会来验证效果，看看是否达到预期。

整个闭环，分成：提交需求、排期开发、上线运营、需求调整，4个环节。

在提交需求环节，需求提报方要给出可量化的价值预估。

在排期开发环节，开发团队将需求池里的需求按价值大小进行PK，价值高的需求会排在前面，优先安排开发资源。

上线运营环节，对该需求的价值进行验证，验证的结果将影响需求提出方的信用等级，信用等级将用于需求PK阶段，作为加减分项。

需求调整环节，也将价值做相应的调整，形成新的需求，反复迭代，形成流程的闭环。

制定需求优先级的准则。从紧急程度、重要程度将公司的需求分成三个等级，P0为优先级最高，P2为优先级最低。如下图所示，横坐标按重要程度，分为三类：公司战略项目、各部门重要项目、非核心业务项目。

例如：公司战略项目和部门重要项目，同时又非常紧急的，这类项目是P0级项目。其它类型项目，你可以轻易的对号入座了。

开发资源冲突解决办法。在协商未果的情况下，自下而上层层升级，直到问题解决。此外，跟业务方的月度需求沟通会，季度需求复盘会，这类正式沟通会议要形成常态。

第二，基于OKR的需求聚焦与创新

什么是OKR？

OKR是一种战略目标任务体系，是一套明确目标并跟踪其完成情况的管理工具和方法，由英特尔公司发明。
OKR由一个需要极致聚焦的明确目标和量化该目标的数个关键结果这两大主要部分组成。
O是Objectives，KR是Key Results，OKR就是Objectives and Key Results，即目标与关键结果法。

OKR由英特尔公司发明，安迪 · 格鲁夫解释道：

这种目标管理的两个关键词是 “目标”和“关键成果”，它们分别对应着两个目的：目标是方向，关键成果需要得到评估，但是最终结果显而易见，根本不需要出现 “我做了这个吗，或者根本没做？” 那样的争论，是或否，就是这么简单。

英特尔按OKR方法，制定战略，并将其转化为可实施、可协作的项目。

简而言之，OKR让决策者和公司的其他成员总是能够把时间和精力聚焦在最重要的任务上，从而完成公司的使命。

在OKR的目标和关键结果制定过程中，有一个非常重要的环节，叫做“对齐”，指的是每一次制定完OKR之后，要看看你上级的OKR，跟你定的OKR，是不是方向一致的，这叫“向上对齐”。

一旦出现了开发资源冲突，就把大家拉到一起，把各自的OKR列出来，看看我们是否在同一个方向上聚焦，如果不能达成一致。就把上级领导的OKR拉出来，看看他的OKR聚焦哪个方向，甚至看公司CEO的OKR，通过聚焦目标、对齐的方法来解决开发资源冲突。

本文要点小结

中台建设的基础协议

就是要根据我们对商业的理解，把一些基础协议梳理出来。例如什么是业务？什么是业务身份？各个业务领域的边界是什么？每个领域提供的基础服务是什么？再在这些思想的指导下去建立业务平台化的实施标准和业务管控标准。

中台的基础设施：中心化控制单元

就是运营平台，它主要由协议标准、能力地图、业务需求结构分解、全局业务身份、业务全景图、业务度量等构成。能让我们有一个地方纵观全局，把控细节。

中台化的核心目的是降低成本

一个是资源浪费方面的成本，即公司有三四个业务线都在做同样的事情了，那技术上实现能不能融合可复用的部分。另一个则是时间成本，即新业务能够足够敏捷地去使用既有的技术模块去做探索。

有了前台和后台，为什么还需要中台

中台建设要避开哪些“坑”

1、中台是企业 IT 变革的一个起点，而不是单纯认为，我就是做一个项目，我搞一个采购中台，就解决了所有的问题

2、第二个“坑”发生在选择中台的技术平台时，很多人想，我先选一个便宜的能用的平台，以后我再选一个复杂的、更全面的平台。

3、第三个坑，就是大家对试点、试点项目这块不太重视，往往会抱有这样的想法“反正是试点、就试一试”。

中台建设难题一：中台团队离业务远

有两个解决方案：

第一，中台职责直接由最大业务方来担任。

第二，让中台团队做业务闭环。

中台建设难题二：中台需求优先级难排序

有两个办法：

第一，建立以价值为导向的需求治理机制。

第二，基于OKR的需求聚焦与创新。

业务中台建设方法论

今天准备分享下业务中台规划建设方法论对传统企业架构规划方法的改进。对于中台建设方法论简单来说应该结合如下几个方面的核心思想，具体包括：

SOA思想：重点体现纵向到横向，服务识别和基于服务编排和组合
微服务思想：体现构建的时候传统单体进行微服务化，大拆小
中台思想：体现在构建业务和应用架构的时候，共性业务能力下沉
云思想：重点体现由传统的接口服务集成，转变为集中化建设和能力服务开放

对于传统企业架构思想可以看到基于业务驱动IT思路，从端到端流程分析出发进行企业核心的业务流程活动，业务对象识别，然后再规划业务架构，数据架构，应用架构和技术架构，在应用架构中又包括了我们常说的集成架构规划。

传统企业架构方法核心说明

从顶朝下和从底朝上结合

在企业架构规划中，架构分析的入口点，我们认为合理的方式是从整体的端到端流程分析入手，细化到各业务域的端到端，经过不断的流程分解到3-4级流程，最终细化到最底层流程（如EPC流程，它是流程，本身也是业务功能）。另外的一个方式是直接从业务活动信息收集入手，如根据组织架构和岗位职责直接收集业务功能点。

第一种方式既看到面又看到点，从上到下层层推进；而第二种方法则是容易只看到点，但无法贯彻整个企业端到端流程。

当然，流程分析并不一定能够涵盖所有的业务功能点，因为有些业务功能本身便是最底层的EPC流程，往往并不是从高端的端到端流程分解而来，如用章管理是一个业务功能和EPC流程，但并不一定能够挂接到高端流程上面。

这也是端到端流程分析要注意点，即从顶朝下和从底朝上要相互结合。高端流程分析和分解是建立全局思维，但是仍然要借助第二种方法收集完整的业务和活动。

从业务活动分析中发现业务对象

流程到子流程，再到业务活动，业务活动中承载的是业务单据和业务实体。需要对业务实体进行抽离，进行数据层面的数据建模和分析。分析在流程各个阶段和活动中产生的业务实体之间的关联和依赖关系。业务域对应到数据域和数据分类，进一步可以分析到具体的概念模型或逻辑模型。

流程分析偏业务操作和事件，而数据正是业务操作的对象。SOA中强调操作和数据解耦，则正好是分析的两个维度。

业务组件划分-微服务的雏形

业务架构中的业务组件划分强调的是业务本身的高内聚和松耦合原则。

对于任何一个业务域基本有两种类型，一种是数据驱动型，一种是工单任务型。如资源、资产等核心数据对象，业务操作层面重点是对数据对象实现全生命周期管理。因此业务组件划分基本遵循底层为基础数据支撑层，上层为生命周期管理层，覆盖该数据对象的核心生命周期阶段。这是业务组件划分的一个基本思路。

对于业务架构的构建，特别是我们对某个业务域并没有深入的理解前，最好的方式就是流程驱动分析，抽离数据进行数据建模，然后进行CRUD矩阵分析，分析数据和业务功能的关系。对底层的业务功能进行组合满足高内聚松耦合的原则，然后从底向上的对细粒度的业务功能进行组合，形成高内聚的业务组件。当然在整个过程中往往我们会参考业界标准的业务架构参考模型，如供应链的scor模型，电信行业的etom模型等。

业务架构完成后，将会过渡到应用架构，业务架构和应用架构基本是对应的。

其中较大的差别点在于业务架构只关注业务，业务本身分为功能性需求，非功能性需求。非功能性需求中包括了平台层面的支撑需求，即应用的集成支撑和数据的集成支撑，公共平台层功能等。另外还包括了纯技术层面的非功能性需求。对于前者需要体现到应用架构中我们往往会分为技术支撑平台和应用支撑平台。

技术支撑平台包括了安全，管控等；而应用支撑包含了数据平台，集成平台和流程平台等。应用架构一般会分为支撑层，应用层和决策层。

服务架构需要考虑业务系统间的集成点。这个集成点的分析我们期望可以将端到端流程结合应用架构中的业务系统，CRUD矩阵分析形成跨业务系统的跨系统交互流程图。这种流程图已不是纯粹业务层面的流程图，而是做系统交互分析的跨系统交互流程图。所有的跨系统交互点则为流程驱动下的业务集成点。而CRUD矩阵分析则帮助我们分析出数据驱动的数据集成点。前者为业务服务为主，而后者即以数据服务为主。两者在分析完备后最终都体现到应用集成架构中。

业务中的平台级和非功能性需求转化到应用架构中的底层支撑层，对底层支撑层中的核心技术进行抽取，最终转化到一个完整的技术架构。技术架构和业务无关，它所提供的是底层技术支撑层能力。

技术架构逐步转化到公共的平台层，提供核心的资源池能力。业务组件本身转化为能力单元，业务组件由平台资源承载，提供业务服务能力。业务服务最终又可以通过灵活的配置形成完整的业务应用。因此我们所说的解耦不仅仅是业务组件间的横向解耦，还包括了业务组件到底层平台，业务组件到上层应用间的纵向解耦。

对传统企业架构规划方法的优化

从上面我们对传统企业架构规划方法的核心逻辑说明来看，传统EA企业架构规划方法仍然相当完整，但是我们也需要看到在整个SOA和云架构思想下，在中台和微服务思想逐步演进的过程中，传统的企业架构规划也需要进行优化和调整。

传统企业架构规划方法仍然是按照传统遗留大单体应用垂直纵向建设的模式来进行的规划，同时很少考虑到了集中化的云平台建设模式。然后在当前企业的信息化规划建设，平台+应用构建模式已经逐步成为主流。

同时在平台+应用分层构建的模式下，进一步将传统应用大单体拆分为多个独立自治的微服务进行独立建设和管控，而对于平台层则进一步融入云平台建设思路，包括最近1到2年我们谈的最多的面向云原生的解决方案。

这个云原生已经从传统的IaaS云平台过渡到了完整的PaaS云平台和技术服务能力提供。

基于以上分析，可以看到传统企业架构优化点主要体现在

从纵向到横向：架构规划分析需要从纵向过渡到横向分层规划设计
数据库拆分：业务架构和数据架构结合分析，在规划阶段形成数据库拆分
业务和应用架构融合：在剥离了平台后，进一步融合业务和应用架构
基于业务组件规划设计微服务
技术架构规划新增加PaaS和技术中台服务内容

以上即是我们考虑需要进行优化的一些关键点。基于上面的思路，我们可以看到中台规划和建设的方法论可以进一步简化为下图。

从上面图可以看到，对于流程分析和数据架构分析仍然无大变化，核心都是为了划分业务组件和微服务模块。但是对原来的业务架构和应用架构可以合并，原因就是传统应用架构的平台层已经将其移到技术架构规划中。其次就是技术架构不再是单纯的IT基础设施架构，而且需要包括我们当前说的PaaS云平台和面向云原生的整体解决方案。

在整个中台建设规划中可以看到业务中台规划简单的重点仍然体现在两方面：

其一是业务中台中的微服务如何拆分
其二就是微服务究竟应该暴露哪些独立的可复用API接口

对于中台微服务粒度究竟应该如何拆分才合适，参考我前面的文章：

中台规划中微服务粒度究竟应该如何划分？你可以从以下几点考虑

而对于技术中台可以看到，实际上包括了多个方面的内容，这个在我们前面的文章也有提到，即微服务开发框架和环境，DevOps支撑平台，容器云平台，共性技术服务能力，API网关和能力开放平台，运维监控平台。这些才构成一个完整的技术中台，如下图：

中台构建思路-横向分层和纵向拆分

大家都比较清楚，中台架构咨询和建设来源于互联网企业，然后逐步转入到传统企业内部，对于互联网企业基本也给出了中台建设的初步思路和方法论，但是如果简单的照搬这些思路到传统企业内部，往往行不通。那么我就需要首先分析互联网企业和传统制造类企业在业务和IT建设中的一些差异。

初步比较关键点如下：

1. IT系统受众：互联网后台管理用户少，而外部用户多；而传统企业大部分为内部用户。
2. 前台应用的敏捷性：互联网对前台敏捷度要求高，而传统企业前台应用敏捷度要求并不高
3. 业务逻辑复杂度和强事务要求：互联网相对低，而对于传统企业IT系统业务逻辑更复杂

当我把上面几点想清楚后，实际上对于传统企业中台构建的差异点或思路基本就想清楚。对于第1和2两点刚好对应到我们在进行横向分层构建上的差异，第3点对应到纵向拆分上的差异。具体为：

1. 横向分层上：不是所有传统IT都要转为中台+前台模式，而是需要考虑受众和敏捷性要求
2. 纵向上：不是微服务拆分的越细越好，而是要考虑业务逻辑和事务处理需求

如果企业内部中台构建不考虑上面两点，而是完全照搬互联网企业的中台多个中心+前台应用的构建模式，那么就是走极端，为了中台而中台。因此在企业中台构建时候一个关键点即：企业中台的构建不能脱离实际业务需求和场景，所有技术选择一定要追溯业务需求和目标。

1. 横向分层：中台和前台分层构建思路上的思考

首先我们来看下横向分层上面的思考，即中台+前台构建思路上的差异思考。

前面已经谈到过了企业内的IT系统建设更多的是面向企业内部员工或业务部门，其受众相对来说比互联网应用小很多。那么在这种情况下如何来构建中台，或者说中台+前台分层构建的思路从哪里入手呢？

1.1 企业业务需求从内朝外扩展和延申的时候

第一个思考点就是企业内部业务从内到外延申的时候，比如企业需要自建电商平台直接服务于外部的C端客户，比如企业需要和外部的上下游，合作伙伴对接的时候。当出现这种延申的时候，我们就可以理解为可以参考中台+前台构建思路来进行。

其核心原因就是，延申业务本身业务敏捷性述求高，而且延申业务不会产生企业需要的核心业务对象和数据，仅仅是产生中间过程对象。在这种场景下最合适进行中台+前台模式进行构建。

即当企业构建自建电商平台的时候，你完全可以参考互联网电商平台中台+前台的构建方式来构建。其次企业内部的围绕ERP为核心的IT系统需要开放能力给业务系统用，而这个时候你可以将企业内部的业务能力整合后形成一个能力中台再开放给电商平台使用。

这个能力中台可以理解为企业内部IT系统能力服务的代理和整合。

1.2 对应企业内部面向全体员工的业务系统建设

企业内部有很多IT系统，其中类似采购，财务等核心系统往往只面向供应链，财务部门。而对于人力资源，办公，报账平台等业务系统往往则是面对全体员工。正是由于人力资源管理，报销平台这些系统受众广，我们才看到企业内部业务架构和IT架构优化转型的时候会提出共享的概念。即经常看到的企业财务共享中心，企业人力服务共享中心。

面向全员的系统受众广，往往导致了业务敏捷诉求高，再业务敏捷述求高的情况下我们就可以考虑优先采用中台+前台的建设模式进行构建。提升前台应用的敏捷响应度。

1.3 企业新构建的核心业务系统的外围系统，本身无核心业务对象数据产生

最后一种常见就是企业新构建的核心业务系统的外围系统，这类系统的特点就是本身无核心业务对象数据产生，更多是产生输入到企业内部核心业务系统的正式数据。

比如我们常见的企业招投标管理系统，这个系统存在的价值就在于产生招标评审通过的供应商信息导入到供应商或采购系统中，其他都是招投标过程业务数据。还有类似的就是我们常见的员工报销系统，员工报销系统同样不产生核心数据，更多是生成中间过程的报销单据，形成最终的应付凭证信息导入到企业内部的财务系统。这类系统本身往往就适合采用中台+前台模式构建。

2. 纵向切分：从单体应用到微服务化的思考

首先我想说明下，在中台和微服务的概念还没有提出的时候，我在企业私有云PaaS平台构建中就在谈企业内部信息系统建设的组件化拆分，提出了平台+应用构建，业务能力组件化，组件能力服务化。

在拆分后不再强调业务系统的概念，因为业务系统的概念和边界已经模糊了，业务系统已经被打散为多个微服务模块。对于这种思路我们再来回顾下更多的是纵向的思路。即：原有业务系统拆分为多个业务组件，每个业务组件从数据库+中间件+业务逻辑和前台完全独立并松耦合。

也就是说原来的一个采购系统可能拆分为了招投标，供应商物料管理，采购订单，采购执行监控，配额管理6个微服务组件。这6个组件都对应独立拆分后的数据库。这个和我们现在的微服务架构完全纵向拆分独立的思路完全是一致的。

但是我们仍然发现了一些问题，即业务组件间耦合性很强，导致后续应用开发，团队协同困难。其次，拆微服务必须是横向和纵向两个维度结合共同来拆，而不是监控的模块划分，这个我在后面几篇文章还要详细谈。

那么对应纵向拆分，从单体应用到微服务化，我们实际需要考虑的关键点有哪些？

2.1 以是否拆分数据库的粒度来考虑业务组件粒度

在这里我提出以是否拆分数据库的粒度来考虑业务组件的粒度。比如供应商和物料两个核心对象的管理，我们发现两者耦合性相当强，因此我划分为一个大的业务组件为采购基础数据中心组件。

对应采购基础数据中心组件里面，我们的思考如下：

a. 只存在一个独立数据库，不再根据对象继续拆分
b. 只存在一个中台逻辑层提供服务，不再拆分
c. 可以构建多个前端或前台应用，这个粒度可以灵活拆分

即我们打破原来我们经常谈到的前端前台，中台，数据库必须1对1的模式。这样既兼顾了底层的数据库逻辑处理和事务管理要求。同时又满足了前端的细粒度构建。

2.2 对外服务提供和上层应用支持逻辑层组件拆分

这个也是我这次提出的一个观点，即在构建中台的时候，我们将对外服务能力提供作为中台层的核心模式，而对应上层应用支持的逻辑层不再纳入到中台层，这个逻辑层可以和上层应用紧绑定，可以走类似RPC或直接的jdbc模式进行数据库访问协同。

这种拆分的好处是我们真正将应用功能的逻辑层，和中台服务逻辑层关系和边界划分清楚。在这样划分后我们更加清楚后续中台的范围，包括在性能出现瓶颈后组件的弹性扩展范围。

中台构建方法论整体说明

在前面我们已经给出了中台建设方法论对传统企业架构规划方法的优化和改进关键点，在这里我们进一步做详细的描述说明。

1. 业务流程分析，通过业务流程分析识别业务功能和业务对象

这个点和传统企业架构规划思路基本一致，从业务流程分析入手，从最顶层的业务流程和业务价值链模型，逐层分解到三到四级流程，找到关键的业务活动单元和业务对象，然后从下朝上构建业务架构。

在整个流程建模和分解过程中，我们找到两个关键内容

其一：业务活动或业务功能点
其二：业务对象或数据对象

注意，在传统业务架构建模方法上，我们务必要分析到最底层，最底层的意思可以理解到了最下面的一个业务功能点的业务操作过程说明。为什么要分析业务操作说明？因为通过业务操作分析，实际上你会发现关联或依赖的数据对象才能够识别出来。只有这样业务对象或数据对象才能够识别完整。

2. 基于高内聚，松耦合原则来拆分业务域或业务模块

在业务功能和业务对象都识别出来后，接着重要的一个步骤就是业务域的划分，你也可以理解为中台规划中的一个关键，就是业务组件或微服务模块的划分。划分的原则是高内聚和松耦合，但是核心的方法仍然业务和数据各种交互矩阵分析。其中包括

业务组件交互矩阵：横向和竖向都是业务组件，内容单元格里是具体的业务交互接口点，通过此矩阵可以看出业务组件的划分是否会导致大量的业务接口存在，分析每个业务接口产生的原因，以进行组件的合并、业务功能转移等。

业务对象和业务交互矩阵：横向是业务组件和业务功能，纵向是具体的业务对象，内容单元格是具体的CRUD信息（即传统的CRUD矩阵分析）。对于同一个业务对象，CUD操作尽量减少分离，而读操作则可以共享，以减少业务对象的多头管理和维护，将业务表单和数据的维护尽量控制在同一个业务大组件中完成，减少数据间的交互和传递。

流程交互分析矩阵：横向是具体的流程信息，纵向是具体的流程活动信息，在这个矩阵图上可以看到同一个流程活动或流程片段往往存在于多个不同的流程。该分析的重要作用是对流程建模中可复用的流程片段或流程活动进行抽象和分析。

功能业务组件分析矩阵：横向是具体的业务组件，纵向是业务功能，在该交互分析上重点是分析具体的可复用的业务功能，以对可复用的业务功能进一步进行抽取，形成可复用的服务。

注：对于具体的企业架构规划咨询方法，可参考我近期会出版的《SOA与大数据-企业私有云平台规划和建设》一书。在京东和当当书店均能购买。

当我今天重新回顾这个矩阵分析方法的时候，我发现了一些变化点。

比如我们原来谈到的CUD操作尽量减少分离，而读操作则可以共享，这个并不绝对。即我们的矩阵分析方法优先要解决的不是业务功能模块然后拆分的问题，而是要优先思考数据库拆分问题，即哪些数据对象应该聚合在一起。

简单来说在业务对象和业务功能的矩阵分析图中，我们需要进行一些特殊标志。

对应业务功能需要同时操作多个数据对象并同时入库的进行红色标注。
对于业务功能需要同时查询多个数据对象并返回结果的进行绿色标注。

这个分析的核心目的就是通过业务功能的分析来评估业务和数据对象之间本身的耦合性。对于耦合性高的实际上在进行数据库拆分的时候并不建议拆分开。

在前面一篇文章我就谈到拆库是基础，以拆分完的数据库粒度来作为实际的业务组件或模块的粒度。但是单个业务组件本身仍然还可以在前台或前端构建多个微服务模块。这个也是我近期思考提出的一个重要观点。

因此我们看到业务数据的交互矩阵分析重点是数据拆分，而不是哪些业务功能要聚在一起。

上层的业务功能，比如有10个业务功能，你可以打包为5个微服务，也可以打包为10个，这个不是关键。在这个思考清楚后，我们再来看上层的业务模块如何划分，即哪些业务功能点应该打包在一个也业务模块里面。那么这里的分析方法又该是如何的呢？

在讲解这个前，我们首先将CUD操作拆分为四个操作，即增加一个Import操作，变化为ICUD操作。对于Import操作理解为业务功能在完成后形成正式的业务对象，作为流程末端的输出写入，即Import操作。比如招投标管理里面有一个功能供应商认证，该功能在认证和审批通过后会形成一个合格供应商数据，写入到供应商管理模块。那么这个供应商认证功能对于供应商对象即是Import操作。

因此，我们可以将对数据对象的CRUD操作全部打包在一起形成一个完整的业务模块。对于R我们理解为基础查询功能，而非其他业务功能实现中的类似Reference的引用查询功能。

3. 数据架构分析-逐步弱化并和业务分析融合

对于数据架构分析，我们可以看到进一步和业务流程和业务架构分析方法融合。即数据架构的作用首先是找到所有的业务对象和数据对象。而对于数据域的划分本身意义不大，因为我们在前面业务模块分析中已经看到通过业务交互分析本身就已经在做数据库拆分和拆库的事情。

数据架构一个重点变成识别出所有的数据对象和业务对象，然后补充进矩阵交互分析中。因为我们常规的业务流程分析可能会持续识别遗漏的情况。

要注意到对于业务架构我们只分析到业务对象模型，没有进入到逻辑模型和物理模型阶段，因此在后续数据库拆分清楚后具体的数据模型设计，仍然是传统的数据架构分析方法进行。

在数据对象分析里面有一个重点就是主数据识别和分析。

这个仍然保留，因为前面业务分析方法有可能出现主数据或基础数据识别不全的情况。其次将所有的数据对象仍然纳入到业务数据交互矩阵分析中。对于基本上大部分跨域业务功能都需要使用到的数据纳入到主数据或共享数据的范畴，并将这部分数据拿出来单独拆库进行处理。企业内部信息化建设模式，主数据就一个大数据库，而新的架构模式下我们可以看到主数据也可以拆分为多个基础数据库。

注：今天讲的分析方法里面我们可以核心是业务流程驱动，通过业务流程分析业务功能和业务数据，因此在整个分析和规划过程是弱化了数据架构的。

4. 应用架构规划

应用架构规划会出现大变化，基于前面分析完成后构建的应用架构重点需要体现两点，第一是横向分层，第二是纵向的微服务划分。

我们可以参考下当前企业中台架构图可以看到，实际上前面分析的业务模块基本都属于中台的概念，虽然这些业务模块本身也带了前台功能界面操作。而实际上互联网中台架构里面谈到的前台更多是面向C端用户的，对于企业中台可以理解为三个方面的可能，这个我前面也解释过。

a. 面向对外的C端用户的，比如企业自建电商平台或APP应用
b. 面向企业内部所有员工自服务的，例如自服务报账应用
c. 面向产业互联和上下游协同的，类似和供应商，合作伙伴的一个协同平台等

因此当前的应用架构规划需要体现出横向分层。前台和中台之间通过能力开放平台进行协同，实现前台和中台能力的进一步松耦合。

对于应用架构中的中台各个业务模块，需要进一步拆分，包括体现出中台微服务的三种不同呈现方式，这个我原来讲到过。需要区别出一个中台模块是否有前端，是否对应有自己Owner的数据库等。

a. 只有业务逻辑层并暴露服务接口
b. 业务逻辑层+Owner数据库+服务接口暴露
c. 业务逻辑层+Owner数据库+前端
d. 业务逻辑层+Owner数据库+前端+服务接口暴露

在前面谈到过，对应d这种模式是否拆分为b和c两种模式需要进一步考虑。

同时我们谈到，在新的中台架构规划中，我们完全可以将业务架构规划和应用架构规划进一步融合为一个规划，要明白在融合统一后，业务架构规划中的业务组件规划即是中台架构中的微服务模块。唯一的差异点，即在于应用架构规划中有前端应用层的概念。

阿里巴巴架构师：十问业务中台和我的答案

一切业务数据化，一切数据业务化。

“中台”概念这几年非常火，特别是阿里、腾讯、百度、京东等互联网公司最近频繁的基于中台调整组织架构，把“中台”的热度又上升到另一个高度，甚至有这样的声音， 90 年代不做 ERP 会死，现在不做中台也会定企业生死。中台的概念起源于阿里，也发展于阿里。笔者有幸参与阿里业务中台方法体系建设，也主导参与一些阿里云新零售业务中台项目，经常被问到如下问题。本文作为“阿里巴巴业务中台”专题的第一篇，和大家分享一些思考（本文内容仅代表作者个人观点，欢迎交流）。

什么是业务中台？

中台起源于阿里，2015年，阿里提出了 “大中台，小前台”战略，灵感来源于芬兰的一家游戏公司Supercell，仅300名员工，却在短时间推出多个爆款游戏，成为全球最会赚钱的游戏公司。其实，阿里早在 2009 年建设“共享事业部”开始，就已经开始了中台的探索，并通过十年上百个客户的实践，阿里也将自己的技术和业务能力沉淀成为一整套解决方案和方法论体系。

中台是什么？不同的人有不同解读。我认为，中台是一套结合互联网技术和行业特性，将企业核心能力以共享服务形式沉淀，形成“大中台、小前台“的组织和业务机制，供企业快速低成本的进行业务创新的企业架构。中台又可以进一步细分，比如业务中台，数据中台，xx中台。本质上，都是对企业通用能力在不同层面的沉淀，并对外能力开放。

业务中台将企业的核心能力以数字化形式沉淀为各种服务中心。业务中台的目的是“提供企业能够快速，低成本创新的能力”。业务中台的核心是“构建企业共享服务中心”。业务中台的过程是通过业务板块之间的链接和协同，持续提升业务创新效率，确保关键业务链路的稳定高效和经济性兼顾的思想体系，并突出组织和业务机制。业务中台也包含技术和组织两大部分，通过“方法+工具+业务理解”加以实现。

数据中台通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。数据中台建设的基础还是数据仓库和数据中心。

那业务中台和技术中台的关系是什么呢？阿里有句话非常形象，“一切业务数据化，一切数据业务化”。业务中台源源不断地从业务造数据，把业务实时在线的交易数据进行统一记录和沉淀，这就是“业务数据化”；而数据中台对沉淀的数据进行二次加工，通过数据标准及算法，产生进一步的分析型数据服务，这些数据服务反向又服务于业务，将业务固化，形成业务闭环，也就是“数据业务化”。比如天猫淘宝的用户实时在线的交易信息，存放在业务共享中心的交易中心当中；而数据中台基于这些用户历史信息，并通过数据分析后的用户画像和标签属性，提供服务给到前端，形成千人千面。这就是我们一直讲的数据驱动、数据闭环、数据价值。

阿里业务中台核心架构是什么？

阿里巴巴超过数十个业务单元（如淘宝、天猫、聚划算、阿里巴巴）均不是独立构建在阿里云之上，在后端阿里云技术平台和前端业务之间有“共享业务事业部“（也就是这里讲的“业务中台”），将业务当中公共、通用的业务沉淀下来，包括用户中心、商品中心、交易中心、评价中心等十几个共享单元，是“厚平台的真正实现“。而后端的阿里云提供计算资源和中间件PaaS云服务能力做载体。同时，使用集团近十年的双11、双12的高可靠、可稳定的运维保障能力，对整个系统进行支撑。中台的使命是从下到上逐步完善阿里的整个体系，从阿里云、数据、中间件、算法，到上面支撑的各种业务解决方案，构建阿里自己核心的能力。

谈到中台，不得不提阿里共享服务事业部的由来，在淘宝初期，主要面向C2C的电商领域，整个系统都是围绕一套“烟囱式”的淘宝技术框架进行。随着业务的不断扩张，集团成立出天猫事业部主抓B2C电商领域，又形成了一套烟囱式发展。这种烟囱式的架构体系带来了诸多不足，比如成本的重复投入和维护、数据之间打通复用的难度、几年之后推倒重建的风险。为了解决这些问题，集团已经开始构建共享服务体系，来沉淀和复用业务能力，但是由于没有过多的业务话语权，共享服务体系的建设一开始并不顺利。之后，随着“聚划算”团购项目的启动，各种系统的流量都需要通过聚划算，这时，共享服务中心得以大展手脚，逐步将集团核心的业务能力构建成用户中心、商品中心、交易中心、评价中心、店铺中心等等数十个共享服务。可以说整个阿里中台的革命也是共享服务中心的革命，各共享服务中心聚焦核心业务单元能力的构建，协助目前集团上百个前台业务的快速创新。

我的企业需要业务中台吗？

阿里业务中台如此强大，那对于传统企业，在做数字化转型的过程中，是否需要业务中台呢？我认为，如果你的企业有以下问题的任何一个，有必要考虑建设业务中台：

业务具有不确定性：创新困难，无法支撑市场高速变化。如渠道扁平化管理，统一会员营销，全渠道等。
业务不在线：企业信息化程度不足，大量人工统计，核心业务没有做到实时、在线、统一。比如会员订单不完整，经销商进销存数据不在线等。
烟囱式系统多：系统割裂，数据孤岛，端到端无法实时协同，更无法基于现有系统进一步构建数据中台。
系统重复建设：内部大量重复建设，缺乏业务核心的固化沉淀，系统服役到期只能推倒重建。
业务与互联网紧密：业务与互联网紧密相关，特别是面向市场消费者，系统的弹性不足，需要支撑不确定的用户数量。

有些同学认为业务中台是大公司要考虑的，而对于业务不复杂、人员也不太多的中小公司不适合。我有不同的观点，其实，无论业务复杂与否、人员庞大与否，只要你的业务与互联网相关，需要快速应对消费者带来的不确定需求，需要打通烟囱林立的系统，需要业务在线来提高企业创新和协同，都应该考虑建设业务中台；同时，业务中台也不一定彻底推到整个系统，首先要改变意识，分步实施、小步快跑，有很多可落地的途径和方法。

那业务中台对企业有什么价值呢？这里我们先简单罗列一下。

1、激发创新：让企业通过核心能力的沉淀，给予快速创新机会，拉通业务整体的点线，降低了试错成本；
2、高效协同：中台侧重的是跨部门跨团队的深入合作，激活了组织创新；
3、业务在线：服务中心化的构建打破了烟囱式的IT架构，提高核心数据实时/在线/统一；
4、人员提升：业务沉淀中台提升了IT人员能力，提高业务运营以及全局意识，成为既懂业务又懂技术的核心战略人才；
5、变现营销：会员资产化，全渠道下沉，补全客户画像，提升精准营销；
6、智能商业：业务数据化+数据业务化的闭环模式，构建了商业智能的基础；
可以看出，业务中台无论对企业战略发展、商业模式创新，还是内部高效协同、人员培养提升等都会带来很多好处。

如何规划和建设业务中台？

很多人认为业务中台落地难，其实难在具体的规划和落地实施上，我们对业务中台的建设路径有这样的一些看法：

1、决心变革：企业内达成战略共识，一把手牵头，业务/技术等团队全局共识。做总体战略规划、分步实施，找准切入点，解决具体业务问题。比如会员营销、经销商门店、全渠道、采购供应链，不同的切入点策略不同。
2、成功试点：通过业务和系统分析调研，明确业务目标和范围，完成技术平台引入、中台建设方法论宣导，并选择验证过的技术平台和实施团队。进行试点，梳理标杆，积累经验。比如从新的业务系统尝试，或者改造现有系统，步步为营。
3、持续融合：总结出适合企业自身的理念和规范，优化组织、提升中台效率。并全面迭代和构建企业业务能力生态。

现有系统如何改造？

前文讲到业务中台在分步实施中，讲究总体规划、分步实施。面对现有系统，并不一定都要进行中台改造，我们建议“外松内紧”：

外松：面向市场和客户方面，以精细化运营为驱动，这些系统更适合建设业务中台。对外市场，快速应变，敏捷创新。比如电商、客户管理、全渠道、营销、创新业务。

内紧：面向内部和员工，以标准化流程为驱动，这些系统更适合保持不变，与业务中台进行对接。对内管理，流程严谨，标准规范。比如PLM、MES、HR、OA、财务。

共享中心如何建设？

在企业的中台能力中心建设中，核心是共享服务中心的建设，不同行业的业务中心有所不同，比如新零售领域，一些参考可以有用户中心、会员中心、营销中心、商品中心、库存中心、交易中心、结算中心、渠道中心。中心设计需要关注如下几点：
1、共享中心是核心业务通用能力沉淀，需要考虑能力地图，产品整体规划，以及协议标准、业务需求构建标准等；
2、共享中心目的是复用和协同，需要通过领域模型，对业务场景流程进行有效建模；
3、共享中心要考虑能力开放，通过API接口、配置管理、或者low-code的高可配置运行机制；
4、共享中心实现前端应用和后台的解耦，需要一定组织机制和考核倾斜，制定沟通机制和冲突升级机制。

业务中台与前台/后台/平台的关系？

业务中台与前台和后台，我认为，主要是这样的配合关系：

前台：敏捷创新，面向不同用户的触点，“点”状繁花似锦。比如2C的电商应用、2B的门店管理等，使用中台开放能力快速变化满足市场的不同业务场景。

中台：核心能力共享沉淀， “面”状协同复用。比如交易中心，正常的交易下单、双十一的预复购、团购秒杀的拼团场景，都可以通过公用的交易中心统一配置。

后台：强大的支撑能力，比如支撑系统稳定高效运行的各种后端系统，以及前文提到的面相内部标准化管理的系统，由中台统一协同和对接。

比较晚前中后台，我们来比较一下中台、平台和中心化。

中心化类似烟囱式架构，一个中心解决整个技术堆栈，而平台和中台都是为了去中心化而生，具体的区别如下：

1、中台是面向业务的能力组合和复用，提供集成化的解决方案：中台的目的是提高研发效率、降低创新的成本。中台包括人，组织，平台，数据，标准，规范，是人和系统的一整套体系。
2、中台是平台的自然演进：平台是单一团队、部门、系统的效率提升，而中台是多领域、多BU、多系统的负责协同。如果说平台的目标为高内聚、低耦合、职责边界清晰；中台是平台化的自然演进，这种演进带来“去中心化“的组织模式，突出复用、协调、业务创新差异化构建。
3、中台不是系统，中台是一种体系/生态/方法论：中台有标准和机制，解决顶层领域下各业务子域的高效协同和资源复用问题。各部门、业务域共同建设，是中台能力的使用方也是提供方。同时，中台提供整个业务快速响应的一种理念和方法，对上层业务支撑。

业务中台建设的关键要素

我们认为，企业在业务中台建设当中要关注4个升级：

1、战略升级。通过中台建设，落地企业数字化战略。中台一定是“一把手工程”，整体规划分步实施。
2、组织升级。组织架构需要与中台架构相匹配，根据企业实际情况优化组织效率，提升效能，数据化运营，更好支持业务发展和创新
3、流程升级。将企业现有流程进行梳理，优化及固化企业流程，提高企业共享复用能力，提升企业运作效率。
4、技术升级。通过互联网技术，对企业基础技术设施进行升级，降本增效，达到企业IT部门整体技术升级。

业务中台需要哪些核心技术来支撑？

业务中台落地中需要一些核心技术，我们也叫“技术中台”，有一些通用的建议：

1、尽可能拆分，共享中心建设：企业应该尽可能地拆分自己的应用，进行共享服务中心的建设，将核心的业务能力复用和沉淀。共享中心的拆分也可以有层次，可从从基础主数据、核心业务、流程规则等角度来进行拆分。
2、去中心化，线性扩展：企业需要采用去中心化架构，没有核心流量汇入点，服务中心尽量无状态，便于水平扩展。这样平均分担压力，负载均衡，对单个中心带来的负载更小，故障影响的范围也更小。
3、数据化运营：去中心化也会面对系统运维和管理成本上升的问题。企业需要对自身的运维运营过程进行积累和沉淀，整理出数据化、自动化运维的经验，同时增强监控告警、限流降级、性能分析诊断等方面的能力，精准定位目前系统中存在的问题，并提出相应的改善方案。
4、异步化，最终一致：在大量的实践中，大部分业务流程不需要强一致性，而使用最终一致来平衡。我们需要使用异步解耦，如使用消息队列来完成业务逻辑，缩短相应周期。
5、尽可能自动化：企业进行中台改造，要求企业尽可能提高自动化能力，比如自动部署、自动弹性扩容、自动升降级、自动限流降级，降低运营成本，也提高系统的稳定性和业务连续性。
6、尽可能使用成熟组件：中台的建设要求企业将重心放在服务中心上，对于底层组件，尤其是中间件层面，尽量使用成熟的云原生组件来提高系统稳定性和性能。目前，阿里巴巴中间件已经将多年经双十一购物狂欢节的严苛考验的技术沉淀，以阿里云标准云服务的方式输出给外部客户，其中包括多款阿里云云原生中间件产品（比如K8S/EDAS/MQ/DRDS/ARMS/PTS/CSB/GTS/MSE/ACM），阿里与流行的云原生技术完整融合（比如Dubbo/SpringCloud/K8S/RocketMQ/Nacos）。

阿里在业务中台建设上能提供什么？

阿里是最早提出中台概念，并成功实施落地，阿里中台所配套的中间件是经过阿里多年双十一洗礼的成熟产品。阿里内部几百个业务应用，共享一个技术中台底座，服务新的业务场景，带来更好的用户业务体验。同时，阿里云通过为上百个外部客户实施业务中台，培养了一大批具备中台实施交付能力的行业ISV，同时沉淀了大量行业最佳实践。

阿里云提供一整套“业务中台技术解决方案”可以解决的问题有：

将企业核心能力下沉共享，加速企业创新速度；
规范IT全生命周期管理，提升研发效率与质量；
提供行业最佳实践，助力企业快速落地中台战略。

架构优势

云原生：支持弹性调度、微服务化解耦，自动化运维；
高可靠：阿里中间件产品支持，历经多年双11考验；
高并发：支持按流量线性扩展，支撑海量用户。

更为重要的，阿里基于近十年的最佳实践，沉淀了一整套业务中台实施的方法论，包括中台架构设计、微服务架构设计、中台开发规范、全链路压测等方面的最佳实践。这些全方位的中台建设方法论、阿里商业能力、阿里云技术支撑，不仅仅是技术红利的分享，更重要的是整个阿里中台战略思想的传播。

更多可以参考“阿里云业务中台技术解决方案官网”。

小结

本文希望通过笔者在阿里业务中台方法体系建设及项目中的一些经验，为企业在业务中台建设过程提供一些帮助。同时本文是“阿里巴巴业务中台”专题的第一篇，后续我们还会有中台方法、中心设计、典型场景、最佳实践等更多精彩内容，敬请期待，欢迎与我交流。

参考资料：

阿里云业务中台技术解决方案官网
https://www.aliyun.com/solution/bme/index
阿里架构总监一次讲透中台架构，13页PPT精华详解
https://yq.aliyun.com/articles/717505
互联网时代的企业必定都要实现中台
https://yq.aliyun.com/articles/717505

作者信息：王思轩，花名宇升，阿里云业务中台&云原生架构师，博士留学期间发表论文10余篇，多年大型分布式系统架构设计经验，现主要参与阿里云业务中台方法体系建设，以及新零售业务中台和云原生技术咨询工作。

本文作者：王思轩

原文链接