序章：中台起源
游戏公司supercell
2015年马云走访supercell公司。该公司里，10个员工就可以组成一个独立的开发团队，称之为cell。小团队自己决定做什么样的产品，然后推出市场，观察市场反馈；反馈不好的游戏，则会被毫不犹豫地砍掉。这样的开发模式使得Supercell公司开发的游戏大获成功，而这一切成功的背后，是Supercell的强大的中台的支撑。
马云访问完supercell公司后，在阿里集团推行”小前台大中台“战略。
如这家公司的名字一样，Supercell中每个项目团队规模都保持10人左右，这种团队称之为cell（细胞）。每个团队其自身都能决定要开发什么样的游戏，与最终是是否要面向市场发布它。而在侥幸活过原型阶段的游戏，会先登陆加拿大等个别国家进行测试，再基于数据表现与玩家反馈，决定它是下架关服，还是在验证玩法可行之后，继续推向全球市场。
——《小团队、独立性是我们开发游戏的关键》 Jim Supercell大中华区总经理
是什么支持supercell快速创新快速试错？
基于“强大（Super）”的平台，以小型“细胞（cell）”团队的方式推进工作；
美军作战模式
前线小分队 + 中台炮火群，美军是广义上践行”中台“理论的祖师爷
在一线战场，美军通常以班为单位组织军事行动，这种极小型团队行动敏捷，容易捕获战机，一旦发现敌情就通过指挥系统呼叫强大的炮火和空中支援给敌军以重创。美军的这种战场组织阵型与中台架构的思想是一致的，战斗小组就是“小前台”，强大的炮火群和空中力量是“大中台”。在强大中台的有力支撑下，前端在进行业务运营和创新时会变得非常高效且灵活，企业可以根据最新的市场动态展开各种尝试和调整，一旦发现并验证了新的市场机遇，就可以调集中台的强大能力迅速跟进，抢占市场。
一 阿里业务平台BU发展史
烟囱式架构 -> 中心阶段
烟囱式架构的痛点
- 重复建设，重复造轮子，人力成本浪费
- 系统间数据难以打通
- 业务创新时间成本高昂，所有业务基建得从头搞一遍。无法快速响应市场需求
鉴于以上问题，2009年，阿里成立了共享事业部（现在改名为业务平台BU）解决这些痛点。
平台阶段
合并后的痛点
-
业务与业务耦合，大量的if else，狗皮膏药代码泛滥（TP交易平台2016年支撑了50+个业务）
-
业务与平台耦合，业务与平台你中有我我中有你
-
平台准入门槛高，小业务、轻业务也要跑完所有的流程，新小业务无法快速试错占领市场，无法快速高效支撑新业务
-
细粒度的业务没有沉淀，无法复用
业务架构的诞生 -> 中台阶段
引入业务架构解决平台阶段的痛点，BU内部诞生了如TMF，GPF等业务架构框架
前台：能直接触达用户的系统
中台：可复用的业务系统
二 业务中台的基石：业务架构
设计目标
- 业务与业务间隔离，A业务修改不能影响B业务，改一个业务回归全网
- 业务与平台隔离， 业务需求开发时无需修改平台代码，而是使用平台暴露的可扩展点
- 业务能力组件化
- 业务流程可编排，可配置
实施时的技术
- 业务身份
- 微内核架构
- 基于spi技术的扩展点
- Spring IOC的思想
如何做到灵活易接入的中台化产品/平台和业务隔离
仅仅达到业务代码解耦并不够，商品发布系统要做一个中台化的产品。能够快速的支持新业务接入，让新的业务一起共建甚至新业务的同学独立的在XPF框架上接入他们的业务，是我们的目标之一。要做到高扩展，快速接入新业务，这里不得不提到“微内核 + 插件化”技术。
微内核技术：
微内核是内核的一种精简形式。将通常与内核集成在一起的系统服务层被分离出来，变成可以根据需求加入插件 这样就可提供更好的可扩展性和更加有效的应用环境。使用微内核设计，对系统进行升级，只要用新模块替换旧模块，不需要改变整个操作系统。
微内核技术源于操作系统，但是在互联网产品“中台化”的大浪潮之下，这个技术依靠高扩展性得到了广泛的应用。
GPF微内核会暴露一系列的SPI(Service Provider Interface)接口，不同的业务按需去实现这些插件接口。系统启动时，程序扫描出所有实现了SPI接口的插件，并集成到系统中对外提供服务。当新业务需要接入时，定义好一个业务身份，同时实现需要的SPI接口，即可完成业务的接入，同时做到业务的隔离。
如何做到业务隔离
我们给每个业务身份建立一个模型，并配一个业务id。业务模型包含这个业务要用到的组件，扩展点，流程配置。所有业务身份构成一个业务身份列表。每个业务模型都有一个业务识别逻辑——当前用户请求是否命中该业务。用户请求进来时，都会走一遍这个路由算法，以确定唯一的业务身份。
业务间隔离方案
通过上述可以发现，平台通用的扩展点和组件是代码复用的！并没有达到之前的代码隔离要求。解决方法也简单：系统初始化时，每个业务身份id都会new一份通用组件和扩展点，并merge自己的定制组件和扩展点。于是，内存里，每个业务身份id都会有一套运行时的独立且完整的组件和扩展点集合。系统真正运行的时候，取到的是组件和扩展点的对象，并不是代码。这样，代码复用，业务数据隔离。这才是最合理的方案。
业务架构的缺点
- 学习成本高，需要弄清整个架构的机制才能上手
- 对维护工程师要求高，普通工程师无法胜任。尤其是写了多年MVC架构风格代码的工程师，很难理解插件式架构的运行原理。
适用场景
如果一个系统同时支撑的业务量很少的话，并不适用。没有银弹，没有万能的架构，每种架构都有其擅长的地方。业务场景少的情况下，写if else维护成本更低。