无共享架构 - 大烟囱架构
共享架构模式1 - IaaS 架构
共享架构模式2 - PaaS 架构
共享架构模式3 - SaaS 架构
共享架构模式4 - 中台架构
理解中台概念 - 业务中台
业务相关
业务中台是企业内部业务相关的能力共享，IaaS、PaaS、SaaS 都不是中台。
跨业务
业务中台肯定是跨业务的，单个业务不需要中台这个概念。
相似业务
相似的业务才可以构建在同一中台上，差异太大的业务，中台没有意义。
业务中台，是将企业内多个相似业务的通用业务能力沉淀到平台，以减少重复建设，提升业务开发效率的一种架构模式。
价值：
相似业务的能力共享，避免大量重复开发，提升开发效率。
1. 业务相似度越高，业务中台价值越大，建议相似度达到
60%以上的多个业务共建中台，例如“快车+专车”，“淘
宝+天猫+咸鱼”，”火山 + 抖音 + 西瓜“。
2. 评估业务相似度，需要依赖业务专家，而不是一个单纯的技术工作。
3. 强行将相似度低的业务塞进一个中台，不但不会提升开发效率，还会大大降低效率。
理解中台概念 - 数据中台
所有业务
数据中台应该是支持所有业务的。
数据打通
业务间的数据需要打通。例如通过“统一用户 ID”来关联同一用户在多个业务上的数据。
数据复用
不同业务间的数据可以复用，提升整体的运营效率。例如：美团可能根据你看电影的数据来向你推荐外卖的商品。
数据中台，是将企业所有业务的数据沉淀到同一平台，支持业务间数据打通以及数据复用，提升企业运营效率的一种架构模式。
价值：
数据打通和复用，避免数据孤岛，提升运营效率。
1. 使用数据中台的业务越多，数据中台价值越大。
2. 数据中台的价值体现在：统一数据平台、跨业务的数据打通、跨业务的数据复用（挖掘）。
3. 跨业务的数据复用：理想很丰满，现实比较骨感，受限于业务熟悉度和组织结构的相关约束。
中台带来的问题
中台与业务的边界难以明确
【现象】
1. 没有任何明确的规则，都是靠人肉讨论。
2. 在已有业务基础上比较容易提炼，创新业务几乎无法判断。
3. 创新业务对中台 KPI 没有帮助，大部分情况下都会被拒掉，由业务自己实现。
4. 中台适合做“组合式创新”，没法做“颠覆式创新”。
【应对方法】
目前没有
中台的全流程效率并不高
【现象】
1. 每个业务功能都要讨论边界；
2. 每个业务功能都要考虑对所有业务的影响。
【应对方法】
大家想想吧。
微服务搭建业务中台
微服务不一定是中台，中台一定是微服务！
用 Pipeline 封装不同业务流程
用 SPI 封装不同业务
SPI 全称 Service Provider Interface，是 Java 提供的一套用来被第三方实现或者扩展的接口，它可以用来启用框架扩展和替换组件。
SPI 的作用就是为这些被扩展的 API 寻找服务实现。
用 SPI 封装案例
