了解中台架构在企业级信息化平台中所处位置以及其如何为整个平台赋能, 简单描述中台战略应用场景
中台架构在圈内最近被送上了热搜, 数据中台, 业务中台, 技术中台, AI中台….
个人理解上, 对此架构一直停留在SOA, ESB的概念上, 因为一直不能参透其中奥秘, 故翻阅大量文章帖子去钻研
数据中台的概念民间传说, 是由阿里首先提出, 为了应对双11这样的业务高峰, 把整体的信息化系统解耦, 去中心化(微服务), 以应对大规模数据的线性可扩展, 以及达到提供三高(高可用, 高扩展, 高性能)服务平台的目的, 从业务侧高度解耦, 进而在大量稳定而且可公共化的业务模块上, 做了一种能力下沉的操作, 其本质还是一种平台, 但是像面向对象编程一样, 高度封装了一些可复用的公共服务组件(技术, 业务, 数据), 阿里称之为SPAS(share platform as service), 基于面向服务的架构模式(SOA), 所有中台服务采用点对点的方式进行数据交互
题外话: 有兴趣的同学可以看一看SOA和微服务的区别, 其实不大 (摘抄) 微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
中台的产生
企业原有信息化架构大致分为前台, 后台
前台: 顾名思义, 直接面对客户的流量入口, 由各种应用组成的系统平台, PC门户, APP, 公众号都属于前台 后台: 由各种业务管理系统组成的后端平台, CRM, ERP, EHR, APM等都属于后台, 数据存储, 计算平台也属于后台类系统
从受众群体以及宏观信息化架构上来说, 后台是为了提升企业的办公效率, 以及统计企业各业务数据, 为了业务管理而产生的系统管理平台, 并不为前台直接服务, 而且维护成本高(人力, 物力), 可能一部分是采购, 一部分是自建, 不管哪种, 经历多次业务变动, 数据结构的升级, 往往打了好多补丁, 且后台相对来说是一个个信息孤岛, 数据并不互通, 即便是共用一个数据中心, 大多数情况下 也只会形成一个更大的孤岛, 所以希望从后台完美支持前台日新月异的业务变化, 几乎变得不可能
前台和后台的各自特性导致了二者之间的冲突不可避免, 一个是需求变化快, 推新需求高, 产品迭代快. 另一个是需要有序运行, 数据操作趋于稳定, 不可轻易推翻
我认为, 前后台之间在生产过程中, 并没有哪个企业真正的去把业务处理能力下沉到后台中, 因为两种平台边界清晰, 如果真的把后台赋能成为前台的业务处理中心, 那么维护成本将会急剧上升, 之所以产生中台, 往往是因为公司产品过多, 而多个事业部之间又在重复造轮子, 从程序员的角度讲, 大多时候, 希望拥有程序的完全控制权, 上升到部门的层次, 衍生出来了一个个信息孤岛, 技术独立, 数据独立, 阿里早年间就是把各个业务板块划分成单独的应用, 比如淘宝业务, 天猫超市, 天猫书店.. , 虽然实现了数据整合(只不过在一个数据中心, 其业务数据并未整合, 比如订单, 物流等数据), 技术框架的整合, 但在业务逻辑上, 还是存在造轮子的问题, 感兴趣的可以转到我的另一篇文章 服务端高并发分布式架构演进之路 了解更多..
之所以产生中台, 是为了把多个产品中重复造的轮子(业务代码), 沉淀出来, 把趋于稳定的业务下沉, 衍生出来中台架构, 这样既可以高度统一数据标准, 统一业务标准, 前台的个性化业务也得到 了满足, 把整个企业级的数据统一建模, 管理, 提供高可用一致性数据, 实现了三个统一, 业务接口统一, 业务数据统一, 业务实体统一.
小前台, 大中台, 满足了业务的千变万化, 玩法的花样百出, 最终多个小前台融合成大前台生态圈. 我们在用的微服务(我指的是真正的微服务架构, 并不是微服务技术)就是一种伪中台架构模式(业务单一), 区别就是所支持的前台业务是否多元化.
题外话: 数据仓库&数据中台的区别
数据仓库是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合，出于分析性报告和决策支持目的而创建。 数据中台是一个数据集成平台，它不仅仅是为数据分析挖掘而建，它更重要的功能是作为各个业务的数据源，为业务系统提供数据和计算服务。数据中台的本质就是“数据仓库+数据服务中间件”。