中台化架构思路及原则

架构思路及原则"/>

中台化架构思路及原则

中台化架构思路及原则

中台起源

2015年年中，马云带领阿里巴巴集团高管拜访了芬兰移动游戏公司Supercell——《部落战争》《海岛奇兵》《卡通农场》等多款知名游戏的创作者。
Supercell的模式给了集团高管们很大的感想：在Supercell内部以小团队（cell）形式作战，小团队最多不超过7人，小团队对整个项目周期负责，
从项目策划到研发再到向市场推广，如果产品没有受到市场欢迎则迅速放弃产品，从中吸取经验后再进行新的尝试。这样的快速试错、不断创新的模式使得Supercell成为了一家年税前15亿美元的游戏公司。
透析Supercell的模式，它的成功离不开其自身在多年游戏研发中积累的"中台"能力，这个能力使得几个人的小团队在几周时间就能研发出一款新游戏，

中台的定义

“中台"是强调资源整合、能力沉淀的平台体系，为"前台"的业务开展提供底层的技术、数据等资源和能力的支持， 简单来说就是"中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑”。

中台建设的一般方式

通过在一个业务领域对公共的素材、算法、引擎等资源进行沉淀并提炼各个业务线的共性需求，并将这些打造成组件化的资源/能力包， 形成一套可复用、易扩展、稳定的业务单元集，并以接口或者平台的形式提供给前台各业务部门使用。
从架构方法来讲，中台架构建设采用渐进式的演进原则。

中台建设的目标

“中台"的设置就是为了最大限度地避免"重复造轮子"的问题，也让每一个新的前台业务创新能够真正意义上的"开箱即用”，而不用每次开辟一个新业务
都像新建一家创业公司那么艰难。这样可充分鼓励团队进行试错、创新，降低试错成本，提升创新效率，使得团队能以最快的速度找到受市场欢迎的产品，
为奠定其行业地位打下了坚实的基础。

例子

类比美军作战模式，就可进一步感受中台的作用。美军在二战时期，以军为单位作战；越战时变成以营为单位作战；中东战争时期进化为7人或11人的极小班排作战。
之所以美军的"小前端"如此灵活，因为有强大的中台能力，给前端军队提供各种资源支持以及中台炮火群支持打击。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MA7SIO8Q-1602742675373)(file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image002.png)]
阿里巴巴中台战略实现了对多条业务产品线的支撑，并提高了新业务产品建设的效率，模型描述如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4xnAkB1l-1602742675375)(file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image004.png)]

中台化实景分析

以一个电商中台的架构模型为例，展开中台化各层次建设原则的论述，架构图如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pXaC6tqr-1602742675377)(file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image006.png)]

基础组件

技术类的工具集，为各种业务功能提供支撑，可以是自主研发的，也可用选用一些市面开源、成熟的产品，如：google的guava工具集，SpringClou d体系下的各类家族产品等；
这些组件并不关注业务本身，可以服务本项目、本团队，也可以开源出去服务更多的人。举例说明：
数据访问组件： 抽象封装分库分表访问，读写分离，主备切换。
消息中间件组件：这块的选择非常多，就开源的就有ActiveMQ/RabbitMQ/RocketMQ/Kafka等等, 再加上阿里云、AWS、腾讯云等提供的各自的云版本，会非常多；
如果不对这块做封装，对其上应用做透明化处理，后期做这块的适配调整就会非常痛苦。

业务中台

中台服务是对业务价值的可复用封装，打造一个业务中台的过程，可以想像成在定义一个Facade类，它依赖了很多资源， 最终帮助用户处理了一系列的事务，但是处理的过程对用户是无感的，只是对用户提供了一些操作资源的方法。

基础能力层

聚焦于稳定收敛的业务模型和基础服务本身，只关注每种业务领域内的数据；
对外提供原子化的数据访问和操作的能力，不会随着业务和前台产品的调整发生变化，可以理解成业务模型的DO+DAO层； 领域层中的各个实体高度内聚，实体间相辅相成，共同构成了业务域的基础能力；
各个能力之间业务独立，进程和数据也是隔离的（并不一定是独立的数据库，而是强调各自领域内的数据的变化，不会影响到其他领域）；
领域的业务范畴要根据业务实景进行划分，如：车辆和车型可以考虑在一个业务域中，用户+角色+访问资源共同构成了权限域； 能力层要确保数据一致性；
业务域之间不会出现相互调用，或者异步通知，如：发布/订阅的情况，因为它们只是一种能力的提供者， 应由真正的流程和场景的串联者这类上游角色来决定如何组织。
在中台边界划分尚不清晰的情况下，允许上游应用，如：BFF层直接呼唤能力层，构建自己的业务形态，但是随着业务逐步积累和成熟， 最终要将BFF一些共有、内聚的特性"转移"到中台。

平台产品层

产品层面向特定的业务领域，自身包含的业务特性一定是存在业务价值的。
专注于通过流程编排类的技术手段，将基础能力构建成业务的解决方案，解决共性和个性化的问题；
这就需要根据对业务的不断探索和积累，抽取出一套业务能力集，在该业务范围内，提供各种能力的支撑。
产品层的每个平台之间应设计成松耦合的，甚至说它们之间没有调用、依赖关系，如果出现了此类情况，只能说明不是高度内聚， 或者说设计上并没有将产品层的业务功能充分抽离，未能从不同实例的场景中解放出来；
产品层的底层数据都来自平台层，但是会根据自己平台所涉及的业务范畴，建立完整的的业务数据，并为上游提供一站式服务；
基础能力层在整个链路的充当服务的provider，产品层充当consumer，二者之前是多对多的关系，调用方式不仅仅限于同步/异步/MQ。原则上，产品层组织一次业务场景，从开始到处理结束，要确保数据的最终一致。

层次划分

拿一个具体的场景举例来说明下中台化架构如何进行设计演进：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QVdpsK0U-1602742675379)(file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image008.jpg)]
1、对于优惠平台，只关注如何产生一种优惠方式，并且使这种优惠方式在不同的场景中兑现即可， 这就需要对业务场景进行高度抽象，提炼中场景内依赖的各种业务域模型。
如：可自定义一种优惠方式，它可能由下面这几个维度共同构成：名称、优惠策略，应用渠道，可用时段，发送的时机，优惠维度等。2、有了一种具体的优惠方式（在我们的应用领域也就是优惠券），需要将优惠券兑现，即：发放给某个具体的对象，
该对象可能是用户、可能是团体、还可能是其他主体，但是对于业务中台，应当设计成并不关心它具体给"谁"使用， 而只关心给"谁"，"谁"能用，怎么用，使用结果等就可以了。 3、一个优惠中台内部，会由很多个业务域（基础能力）共同支撑，具体如何组织和编排根据中台本身的业务决定。
如：一个功能相对完备的业务中台，一定有多种体制和形态，过程中一定会产生自己的业务日志，同时具备了一定的告警机制， 和通知机制，包括需要依赖字典来建立自己业务内的静态数据。 4、平台层想提供一种通用的解决方案，要经过合理的识别，通过配置、聚合、api开放等结合的方式，向接入方提供
一种一站式服务。 5、对于一些特殊的场景，业务中台的当前版本暂未提供相应的能力，应暂时交给接入方应用去实现，甚至这部分数据
也需要自己管理和维护，当随着业务的延展和沉淀，这种"特殊场景"成为领域常态的情况下，要考虑将这部分能力下沉到中台体系，这种分治->提炼->下沉，是一种周而复始的过程，更证明了中台化宜采用渐进式架构的演进原则。

列举了一种简单而具体的应用场景，来说明中台化如何提炼，通过一种技术手段实现复用，并与接入方解耦。

向某一个特定用户发放优惠券场景的调用时序：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0q3QzhmL-1602742675381)(file:///C:\Users\ADMINI~1\AppData\Local\Temp\msohtmlclip1\01\clip_image010.jpg)]

用，并与接入方解耦。

向某一个特定用户发放优惠券场景的调用时序：
[外链图片转存中…(img-0q3QzhmL-1602742675381)]