聊一聊什么是中台?
缘起
2015 年马老师去了趟芬兰,拜访了游戏公司 supercell ,这个公司并没有很多的员工却开发出了《部落冲突》、《卡通农场》、《海岛奇兵》、《皇室战争》和《荒野乱斗》等全球热门游戏;除了敏捷开发,快速试错,其构建的中台能力能支持几个人的小团队在短短几周的时间便能开发出一款产品,并进行公测。
服务化治理
那么这是一个怎样的应用服务呢?在微服务兴起的时候,很多公司将原有的应用拆分成一个个单独的小应用(微服务),将沉重的后台系统按照业务拆分,成为独立的系统,这样的改革使得热点服务能够得到更多的关注,部署更多的服务器,快速迭代升级而不需要反复上线那些调用较少的相关业务,我们把这称之为服务化治理。
中台理解
什么是中台呢,我的理解是将服务接口抽象化,抽取共性业务,将复杂的需求拆解为公有功能和需求功能,这些公共功能点一般又很基础,只有很少量的业务逻辑,配合原有服务化的理念,传统应用变成了两层,一层是面向服务端的业务系统,一层是面向数据层的支撑系统;
1. 在这样的架构下,负责支撑的系统包含了数据出口的职责,数据可以做到统一管理,数据出口入口都在支撑层。服务端业务系统只存储非核心数据。以前在某银行服务过一段时间,他们的设计包含了前置,服务端,核心三个大系统,服务端服务于客户端 app、微信公众号、小程序、H5,产品的主要数据来源通过前置系统,用户数据的存储、计算业务由核心处理,在这期间,我了解了各司其职这个理念(但当时只是做了服务化治理,并没有完成中台的设计)。
2. 服务化治理只是将应用按照业务模块拆分,并不能达到组件化的目的,我理解的组件化是单一职责,就像 supercell 一样理解为“超级细胞”,如何控制粒度大小就成了技术人员应该考虑的问题。
每个组件应该包含了对外 API 和对内 API,对外 API 提供给业务层,对内 API 支持的更多的是数据管理系统,也就是我们常说的后台管理系统。
拥有了大量的组件后,产品用户和内部运营所提出的业务需求,就需要一个个不同的服务应用来完成,因为这些粒度化的组件并不包含定制的个性化功能,所以针对这些功能需求,中台支撑需要进行提炼、抽象需求,对需求方提供最大限度的支持。
那么支撑层如何做到组件即拿即用呢?答案是:组件微服务化,搭配现在大热的容器化管理,部署迁移变得更加方便。
如何与业务层进行配合呢?支撑层要做到异常统一管理,制定统一的响应编码、接口规范、日志规范、文档体系就变得尤为重要,业务层只需要知道 API 的入参、出参即可判断是否满足需求。
3. 这样负责支撑业务层的技术方案有了,相应的数据库怎么设计呢?
对于这样模块化的系统来说,数据可分为原始数据和加工数据两部分,对于BI报表、用户智能推荐、算法应用这样的系统来说,对接了大数据部门,经大数据清洗、计算后得到的数据即为加工数据,就得到我们想要的数据中台。因为大部分的数据不是实时得到的,往往是通过计算、统计得到的;而大数据的数据库不应该被其他系统随意查询调用,也不利于数据系统管理、迁移、升级,对接这样的数据也需要开发响应的支撑层。
有什么好处?
各司其职,首先前面提到过,数据有了统一的出入口,这样在数据量增加的时候,任何扩容,分表对于业务层来说都是无感的,底层的数据系统升级也不会对业务方产生任何影响,业务层的开发变得只需要关注需求就可以,支撑层的开发更多的关注某个API是否可以分解提供给更多的业务。
系统可用性,不同的业务方各自调用支撑层实现自己的逻辑,不会产生交叉行为,在业务中穿插大量的判断逻辑,造成升级迭代困难。每一个支撑层的组件升级迭代可以使用平滑过渡的方式,并可以根据调用量针对性的升级,而不会对业务曾产生任何影响。
节省资源,大量的组件使我们在新增系统时,拥有了可用的工具、零件,系统开发只需要少量的人力和开发周期。
团队响应速度,组件化的方式,让整个项目对某个成员的依赖降低,在发生团队资源变化的时候,新人不需要关注大量的旧的、冗余业务,因为业务层中逻辑处理量已经降到很低,完整的文档系统使得开发之间的沟通变得简洁高效。
带来哪些问题?
团队管理,组件化的思想让每一个成员变得不再那么不可或缺,但对整体项目的管理人员变得更加重要,对项目熟悉度很高、业务抽象能力、能快速应对外部需求做出响应的管理人员提出了更高的要求。
硬件资源,组件化后,每一个大应用被拆解为很多小应用,独立部署、高可用造成服务器、带宽、存储等硬件资源的占用。对小型企业来说无疑是沉重的负担。
服务调用链过长,对于复杂业务,可能会需要更多的组件来支撑,就像原来一个人做的事情交给了多个人去完成,其中的不可控就增加了很多,所以对架构的设计要求变得更高。
本篇仅基于个人的理解完成,希望和大家一起来讨论更多的细节,后续会进行补充更改,请持续关注 gosling9527。
![](https://i-blog.csdnimg.cn/blog_migrate/dc9b265508291344c1a29ebddad95fa3.png)