平台化建设思路浅谈

随着业务的不断发展，软件系统不可避免的走向熵增：复杂度越来越高、研发效率越来越差、稳定性逐渐降低等。这时抽象核心能力，走向平台化的道路成为很多系统的首要选择。笔者结合自己的经验，总结了平台化建设的几种思路，希望对大家建设平台化有所帮助。

平台化有以下优点

• 复用性强：复用核心逻辑，业务功能只在平台之上的业务层建设，降低建设成本；
• 研发效率高：平台服务作为通用能力基建，业务只需要关注需求，不用关心平台底层复杂能力实现；
• 降低复杂性：平台都有合理的职责边界和模块划分，对外开发的接口也都直观简洁；
• 稳定性：平台服务的稳定性是重中之重，一般有专门的团队维护，稳定性比一般的业务系统强；

平台化建设几种方式

1、嵌入式

平台提供类似容器的功能，业务方以Jar包形式嵌入到平台当中，类似于传统的多个war包部署在tomcat中。这种实现方式平台提供通用能力接口和业务扩展点，业务方实现业务扩展点来实现业务逻辑。一般有统一的入口（比如tomcat提供的域名+端口），根据租户标识来区分业务方（比如tomcat的serverPath），平台底层的存储及模型中也都有租户ID标识。

优势：

• 运维： 平台统一运维，业务方工作量降低；
• 对外接口：对外统一接口，调用者的工作量会降低；

劣势：

• 业务方功能受限：一般不能做重量级任务，平台以扩展点方式提供给业务方扩展，除此之外的能力都应该被限制；
• jar包冲突、类冲突问题：平台本身包含了很多依赖，业务方jar包也会有很多依赖，如果有冲突会导致整个平台不可用，下文会介绍几种规避方法；
• 业务隔离性差：不同业务方之间可能相互影响；

处理业务隔离的常用方案：

1. 每个业务方提供一个集群；
2. 使用类加载器隔离jar包，但可能依然解决不了jar包冲突的问题；
3. 业务方提供fatjar，更改所有依赖包的package路径，比如MavenShadePlugin插件；

2、接口依赖式

平台也可以通过远程依赖的形式来整合业务的功能。这样能避免jar包冲突、业务功能受限等问题。此方案也会有一些限制，比如原jar包依赖的方式都是本地调用，现在都是远程调用，对性能、事务保证等都提出了新的挑战；需要保证接口的兼容性；平台与业务的交互由原来对象交互变成RPC接口，设计到编解码等；

这种方案适合平台与业务层交互较少、扩展点比较固定的场景，比如API渲染服务，平台提供渲染模板接口，业务方实现接口填充字段。

优势：

• 隔离性：平台和业务完全隔离；
• 业务方方便整合其他业务：平台扩展点只是作为业务方的一种能力，可以在已有的服务上提供；

劣势：

• 接口变更复杂：如果要变更接口，所有业务方都需要迭代；
• 交互复杂：都是通过RPC交互，一些扩展字段需要编解码成String传输；
• 平台方兜底：如果业务方服务异常，平台方需要提供限流、降级、兜底的能力；

3、中台式

上面讲到两种模式都是以平台为主，对上层来说都是感知的平台，适合交互接口比较固定的场景，对交互差异性大的业务不是很适合。中台式的思路是提供业务通用能力，业务方基于中台能力快速开发自己的业务，并独立提供服务或页面。

中台和平台的区别：

• 视角不同：平台关注的是去重、整合；中台关注的是复用；
• 价值体现：平台直接对外提供服务，是一个功能大集合；中台是其他产品的一部分，为了其他产品更好的提供服务；

优势：

• 能力聚焦：只需要提供核心能力