中台实践
写在前面
如果您所面临的业务规模不大或者业务复杂度没有那么高, 那么中台的意义就不大了。我的建议甚至微服务都不需要, 直接单体应用即可, 最多两层, 一个数据服务, 一个应用服务即可. 微服务大行其道的年代, 单体应用听起来倒反天罡, 但是在小规模的业务中, 单体应用的维护成本是非常低的。我这里有一个类比: 好比我家里进了一只蚊子, 我就会去消灭它, 你拉出一门大炮, 直接轰蚊子，且不说是否真的能轰死，单单就这杀伤范围, 也是不可承受之重， 远不及我手拿苍蝇拍，一拍子下去来的精准痛快。所以凡事无绝对, 合适的才是最好的.
另外也是很重要的一点, 即使你的业务体量足够大, 业务也足够复杂, 也要看 所在组织是否有这种大刀阔斧改革的魄力, 从0开始的中台化,基本就是一场组织架构的重构
导引
在讨论什么是中台之前，我们先讨论两个我们比较常见的场景:
场景一: 函数共享
我们在日常开发中, 一定遇到过如下问题: 某一个方法十分基础,且逻辑基本不会变化,比如说,数据查询,为了避免被遍历、被拖库等, 我们通常会将数据ID编码后输出,而这个编码解码的行为,就是一种稳定的逻辑,如果我们将其封装成一个方法, 那么在任何地方都可以直接调用, 而不需要重复造轮子。
场景二: 逻辑共享
假定我们现在再做一个电商网站, 那么一定会有订单退款的逻辑, 退款动作本身是一个固化的动作：A账户 -> B账户转款即可, 但是在实际业务中, 除了退款本身之外, 还需要记录很多的额外信息,比如: 退款原因, 退款金额, 退款时间, 退款状态, 退款比例, 退款订单, 退款发起方等等。退款场景下, 只要设置好上述信息，那么就可以直接调用退款类, 有退款类实现相应的固定流程。
场景总结
从上面两个场景中, 我们可以发现, 无论是代码共享, 还是逻辑共享, 都有一个共同点: 稳定的逻辑 + 共享。单一的固定逻辑封装成一个函数，通过基础方法库完成函数共享；单一的固定逻辑封装成一个类，通过基础类库完成逻辑共享。中台的共享方式与上述场景类似, 只不过 中台通过服务的方式对外部提供共享能力。
思考：中台的价值
通用化: 上文中频繁提到一个词共享, 既然可以共享, 那就需要是一种标准件, 既然是标准件, 那就需要有规范, 这种规范就是统一的标准。组件化: 中台提供的服务最好以组件化的方式让业务端可以即取即用。组件化设计可以避免系统间耦合性大，牵一发而动全身。这需要针对共用服务进行抽象设计。通过抽象出的组件化服务提供，前台业务端可以以组合挑选的方式“按需取件”，减少重复建设得以实现。可复用: 中台提供的服务是应该可以即取即用的。不仅如此，这次用完，下次还来。业务A用了，业务B也来用。一个中台提供出的公用服务的价值高低，是“可用”和“可复用”的区别。服务的高复用是对技术层级上针对共用服务的抽象设计能力的一大考验，需要尽可能近地靠近业务、靠近用户。可共用: 基础服务有了，那通过中台向前台提供“相应的服务”还是提供“一揽子的服务”？取决于服务提供的可开放共用的程度。就像我们看到，各大互联网决定中台建设的开始，总是要伴随企业层级的组织架构的调整。虽然各部门权限、各业务属权，恐怕不是一句“开放共享”的愿景就能完全解决和无差别共用的，但是通过开放共享实现“可共用”的目标终究是中台建设的原则可扩展: 在一揽子的服务都可输出后，业务量可能会短时间大大激增。能扛得住大流量高峰时期的高并发、高可用将成为一个大挑战。底层的可灵活扩展能力将非常重要。企业应当应用DevOps、Docker等先进的开发技术理念，在中台建设前就开启数字化的技术转型。