天下苦定制久矣，平台化建设到底难在哪里？

为什么需要平台

随着业务的不断发展，软件系统不可避免的走向熵增：复杂度越来越高、研发效率越来越差、稳定性逐渐降低等。这时抽象核心能力，走向平台化的道路成为很多系统的首要选择

平台的建设目标

产品的核心价值在于其有效性和用户体验，而平台需要支撑好业务构建和关键能力建设，这为平台提出了能力要求。平台需要提供好的业务构建能力和关键技术能力。

平台主要有解决以下几个：

避免重复造轮子

许多业务需求或功能需求高度类似、通用化程度很高，但是由于没有专门的团队负责规划和开发，大量的系统重复开发、重复建设，导致复用性低、效率低、产研资源浪费、用户体验不统一。

烟囱式架构

早期业务发展过程中，为了解决一些当下的业务问题，垂直的、个性化的业务逻辑与基础系统耦合太深，由于没有平台性质的规划，横向系统之间、上下游系统之间的交叉逻辑也非常多，这样导致在新业务、新市场的拓展过程中，系统没法直接复用，甚至没法快速迭代。

快速响应

因为在当今这样一个互联网时代，用户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。

平台的建设思路

平台建设的核心是分层、模型化分解、标准化接口协议。

分层是指在大的层面上要分好层，基础设施层、OS适配层、数据层、中间件及服务层，核心业务组件层，产品层。一般基础设施层、数据层、中间件和服务层由基础平台提供；核心业务组件层为业务平台提供；产品层由产品研发提供。

模型化分解是指，将现有业务模型化，分解为有限的、核心的、可复用的组件、中间件、系统。

标准化接口协议依赖于模型化分解，能最大程度解决管理成本、维护成本、沟通成本、升级成本的关键，大家基于有限的稳定接口定义开发。模型化和分解的合理性可以最大程度的保证接口的合理性、有限性和稳定性；

另外要聚焦可以被抽象和分解的部分，解决一部分问题而不是所有问题。达成业务组件中间件化。与代码层面的面向接口编程异曲同工。可以参照JDBC和对象存储等中间件的设计。

基于层次划分我们分别建设基础设施的基础平台、以及核心业务的业务平台。

基础平台：提供基础框架、脚手架、代码生成器、代码质量扫描工具、业务编排工具；提供Paas、CI/CD、自动化测试、监控运维、日志、等实施方案和基础设施。

业务平台：聚焦核心中间件和业务组件，不断加强组件能力支撑关键技术能力突破。

                                          系统由孤立的烟囱的系统转化为平台化的系统

总结

每个人心目中的平台都不一样，我们首先需要统一认识。我非常认同一个说法：架构师的根本职责是降低软件产品落地的复杂度问题，而软件产品复杂度的核心就是成本（工作量、复用度、质量、管理成本、维护成本、沟通成本、升级成本）。架构师的精力是有限的，不能事无巨细也不能全都从头建设，所以平台作为工具来降低成本。

    事实上，为了解决重复建设和工作量问题，我们建设过XX平台、XX平台等，但是在这些平台的建设和使用过程中，暴露了尖锐的管理成本、维护成本、沟通成本、升级成本的问题。

     这就体现了事物的两面性，在解决复用度和工作量问题时，带来了其他问题，这是不可避免的，但是也不是不可解决的。而解决之道正是平台建设的核心。