中台之路，从平台到中台的思考与实践（一）

lupkpu9

关于中台的介绍可谓是汗牛充栋，笔者也会写一些中台相关的文章，但包括本文在内一定会写出差异，从笔者自身的实践出发，带各位发现中台的“另一面”。

本文是中台系列文章的第一篇，先谈一下笔者亲身经历的从平台到中台的演进之路。

与某些文章介绍的中台演进不同，我们算是一路“摸爬滚打”地过来，并没有高明到一开始就规划好每一步如何去走，所以接下来笔者会从一个个问题出发，讲述我们如何在不断地“填坑”中前行。

背景介绍

笔者之前服务的是一家集团化的公司，旗下有金融、电商、保险、区块链等多家公司，整体的研发团队最多时有近300号人，但由于缺乏集团层面的统筹规划每家公司及各个业务线的IT系统都各自建设。

填坑之路问题：烟冲式建设

在笔者入职时，研发体系上的问题已很明显：

• 各家公司及各个业务线的IT系统各自建设，存在 大量重复投入
• 各项目人员质量参差不齐，各项目 交付质量低 ，线上Bug频出
• 项目缺乏复用，导致项目开发周期久，交付速度慢
• 项目间难以形成数据与能力共享， 无法实现跨行业的业务打通
  ! y" x3 T( l0 b5 F

) Z, b8 k8 I) U) ^: u- ?& `& K3 Y

如上图，用现在流行的话来说就是“烟冲式建设”。

填坑：组建公共服务组

“烟冲式建设”的解决方案很简单，有大量的路径可寻，我们顺势组建了公共服务组：

• 剥离重复建设的服务到公共服务组统一维护
• 建立统一的技术支撑体系，提升交付质量
  8 A  d! F7 i# G4 E( G" T# c) {

6 v& \: ^/ h$ ^5 K

如上图，我们最先把用户、权限、消息（用户触达，微信、短信、站内信、Push、邮件、钉钉等）、APP版本管理等业务服务；分布式事务、调度、规则引擎等技术服务上收到公共服务组实现。

在支撑上形成了SAAS化、多租户支持，同期基于Spring Cloud研发了Dew微服务框架。

这个过程大概持续了半年左右，基本上解决了前面提到的问题。

演进：平台化战略

公共服务组的建立及相关公共服务的研发很大程度上减少了重复投入、提升了交付质量，缩短了交付周期，并且基本实现了业务线之间的互联互通。尝到“甜头”之后CTO提出了平台化建设的技术部战略方向：

• “公共服务组”升级成“平台服务部”
• 鼓励各业务线研发公共服务
  7 l* H: m& Y' @1 X* ], Z

$ a, ^9 |/ v: d; C3 a1 g

3 [6 P$ g# h; `! D

如上图，平台服务部将工作内容划分成三块，分别聚焦于业务平台、数据平台、技术平台，从零开始着手搭建大数据体系。

又经过了半年左右的建设，原来的三个平台细化成四个平台（技术、业务、数据、研发），新增研发平台关注研发流程的建设。

当时平台服务部产出了20多个服务，各业务线贡献了40多个公共服务，公共服务达到了60多个。

问题：做得多用得少

公共服务建设从数量的增长上看似如火如荼，但笔者已经意识到潜在的问题：做得多用得少。我们开发了60多个服务，但落地使用得很少。

如上图，这是我们当时部分服务的业务接入情况，白底的表示已接入，60多个服务中有很多服务只有单一业务在使用。

笔者反思这一问题的原因如下：

• 业务线研发的很多平台服务只是为了响应平台战略而开发，本身不具备业务需要的通用性
• 平台服务部研发的平台服务过于关注技术与业务脱节，导致业务接入困难
  3 q8 W# h6 n8 }' ]

填坑：中台化转型

要解决上述问题中台化的转型是大势所趋，于是笔者提出了以下三点要求：

• 贴近业务，研发符合业务需求的可复用的中台服务
• 所有中台项目立项时都必须找到两个及以上的业务需求
• 中台人员主动参与业务系统的改造与接入
  

Note

关于中台与平台的区别有很多介绍性的文章，这里不连篇累牍地介绍。

从平台到中台只是换了个叫法还是有实际性的改变？这里举一个例子加以说明：

7 W& M- h1 y# k

7 |  N* e# i) q/ l+ {

如上图，用户权限中心是我们其中的一个公共服务，业务方有个很强烈的需求要求我们实现免凭证注册，什么意思？我们的用户权限中心支持手机号+验证码、用户名+密码、OAuth等多种认证方式，但有一个业务方说他们的用户很多都是强势的三方机构直接推过来的，要无条件地信任这些三方机构，即需要认可这些用户的合法性，这些用户可以免凭证登录（比如用户在三方机构侧的APP已登录了我们只能直接认可这些用户在我们这边也登录了）。

在平台思维指导下我们一直拒不接受这种方式，因为租户间可通过OAuth授权“共享”用户，这种做法存在巨大的安全风险。

但在转型中台之后我们思维是：首先用户及认证相关的需求在用户权限中心的责任域内，其次这一需求有其业务场景，因此我们必须接纳，至于如何解决安全问题是我们内部的事情，不能因为这一问题而拒绝合理的需求。所以在中台思维的指导下我们通过了“应用级凭证等级”模型解决了安全问题，实现了符合业务需求的免凭证注册。

这是一个典型的转型中台之后的变化，类似还有好些，做贴近业务的公共服务成了我们接下来的重点。

演进：中台化战略

又经过了一段时间，我们基本完成了中台体系的建设，包含了四个中台：

• 业务中台，实现通用型及行业性的服务
• 数据中台，挖掘数据价值，实现数据驱动业务
• 技术中台，规范核心技术堆栈、研发基础中间件、把握及预研技术未来
• 研发中台，从项目流程、质量管理、运维监控等多维度提升产品交付能力
  

下面是我们中台服务的一些示例（仅做中台能力展示，与本文关系不大，不展开介绍）。

/ _7 n+ n  L& }+ Y( C2 l+ d

0 r7 ?5 A2 P  D: X/ y; _0 n9 P

6 O& `0 V; V( Y- B

/ Y; R6 F4 l0 Z1 V

- h, A; `4 j5 @" n9 x3 g

如果各位觉得我们中台建设到此就完备了那就太过简单了，事实上这还只能算是问题的开端……

问题：技术侧：开发语言、框架不统一

在标准化上为了统一各服务的规范，一开始我们就着手研发了内部的微服务架构（Dew Framework），后来虽有部分项目使用了，但也有部分项目特立独行，程序员会有自己的习惯、风格，有些人就不认同你搞的那一套，这方面笔者不想强求，但却埋下了隐患：

• 开发语言不同，Java、Node、Scala、PHP都有
• 依赖中间件不统一，如Redis、RabbitMQ的版本，数据同步中间件的选型
• 开发框架各有千秋，有用Hibernate、也有用Mybatis，也有用Spring Data JPA封装的
• API参差不齐，文档格式、API风格各不相同
• ……
  , ^7 ^/ \5 l0 `

随着项目的增多，这些问题已越发棘手。

填坑：统一使用Dew Framework

笔者意识到过度的自由不见得是好事，有时候不能太顾及开发人员的个人喜好，于是做了如下要求：

• 新的项目必须使用Dew Framework，这是强制执行的
• 遗留项目逐步过渡，这需要评估、改造
• Dew Framework由内源转向开源以更好地吸引开发人员关注（开源地址：https://github.com/gudaoxuri/dew ）
  

Dew Framework 基于Spring Boot 2.x，在微服务能力上支持Spring Cloud 及 Istio，提供的核心功能与能力如下：

• 统一分布式操作（缓存、锁、Map、领导者选择）接口，支持Redis、Rabbit、Kafka、Hazelcast、MQTT等
• 统一认证模型
• 统一事件消息通知，支持钉钉、短信、邮件等
• 支持无感知的幂等处理
• 更优雅的API支持
• ……
  ) J" r8 F6 e. @8 B# H, ?7 E

问题：技术侧：发布、部署、监控缺乏规范

在解决开发语言、框架统一的同时我们关注到发布、部署、监控等环节缺乏规范：

• 发布部署方式各异，有用配置中心的，有用本地化配置，配置的拉取方式也不同
• 自动化测试怎么与发布流程结合没有标准
• 依赖服务重复，运维为了稳妥，几乎一个项目一套依赖服务
• 监控告警不同项目各不相同
  % z. E# g  P) O8 |4 h- a5 k

填坑：Dew Microservices System

原Dew Framework只解决了开发时的能力统一，但对后续的发布、测试、部署、监控缺乏有效管控，于是笔者将 Dew Framework升级为Dew Microservices System，新的Dew微服务体系重点引入了DevOps及容器化支持，实现了研发流程主要环节的规范。

% Z' R; k0 `4 C+ \6 r. Y+ E

如上图，是Dew对DevOps的支持示例。

Tip

我们对DevOps做了一些创新性的设计，后期会有专题介绍。

问题：管理侧：项目研发流程不规范

技术侧填坑的同时，管理侧的问题也逐步浮出水面，项目研发流程的不规范导致：

• 不同项目研发流程各异，有用敏捷方式的，有用传统方式的
• 什么步骤产出什么，什么格式没有明确标准
• 项目怎么交付，如何评定项目实施的成败没有标准
  / b2 I6 d- k) X: \

填坑：PMO+敏捷指导

在流程管理上我们引入了PMO制度，由PMO统一管控、考核各项目的流程规范。

如上图，PMO的管控示例。

流程上大家都想敏捷，很多项目也都标榜自己是敏捷开发，但实际上敏捷成功的案例少之又少，究其原因是因为不做裁剪的敏捷实施成本很高，所以我们对敏捷流程做了裁剪，做了培训。

如上图，我们的敏捷流程裁剪。

Tip

关于敏捷开发笔者会另辟文章介绍，本文不过多介绍。

问题：管理侧：中台建设标准缺位

当我们技术侧在不断优化，管理上项目研发流程也在逐步规范的同时还发现了管控上严重的问题：如何评定中台建设的好差？平台也好，中台也好，我们建设了多年却发现我们并没有一套标准去衡量成果的优劣。早年，建设初期集团抱着“宽容”的心态允许我们去试错，不设立过多的考核指标，但现在中台已日渐成熟，是时候需要有一套中台建设的评价体系了。

填坑：中台建设的6S标准

中台建设的投入很大，周期很长，在这过程中我们要形成标准化的评价体系，一方面是为中台自身的建设指明方向，另一方面也是能给决策层讲清楚我们的目标是什么、现在的进度如何、什么阶段能解决什么问题，避免把中台建设算成一笔“糊涂账”。

为此，笔者提出了“中台建设的6S标准”，如下图所示。

  `5 B- F% j: \. y0 f

Tip

这块很重要笔者也会另辟文章详细阐述。

问题：各服务如何整合协作

我们上线了几十个中台服务，但各服务间没能形成有机的整体，比如：

• 每个服务都有独立的地址
• 每个服务的API、SDK风格迥异
• 每个服务的SLA（服务等级承诺）标准不统一
• 每个服务运营支持由各提供方独立支持，没有统一的入口
• 每个服务没有形成统一的服务质量评价体系
  " I5 n' B3 {, Y7 ]/ A' h

这些是典型的多项目整合协作问题，有了ESB及衍生产品我们不用担心项目间的调用，但如何让我们的服务更好用、更易用，进一步地说，如何让我们各系统（包括中台之外的各类应用）都可以有机地整合，形成统一的对外能力一度时间成了笔者思考最多的问题。

填坑：业务信息化操作系统

4 t6 {8 I  |  H  {! ]% ~4 }

如上图，左边是目前绝大部分企业的现状，我们研发中的项目会依赖一个或多个云服务（比如阿里云、七牛等），也会依赖到自身已有的服务，而后者可能又会依赖另外的服务。这会带来如下问题：

• 网络出口分散不利于管控
• 不同三方服务账户体系、调用方式不统一，徒增开发成本
• 已有各服务自成一体，企业信息化缺乏体系建设
    \5 k, @4 z) |. T% E& ~

笔者经过一段时间地思考后成立了Galaxy试点项目，目标是建立一个服务标准化平台，如上图右侧所示，无论是企业自身的服务、云托管服务、本地化部署的云服务都统一向Galaxy注册，由Galaxy提供一致性的API、服务管控，所有项目只直接依赖于Galaxy。

乍一看读者会觉得Galaxy就是个ESB，但不尽然，Galaxy是服务整合平台，ESB算是其底层的一种实现。

作为探索试点，笔者将Galaxy升级成业务信息化操作系统（BIOS：Business Informationization OS），看起来很“玄乎”是吧，它的模块全景架构如下图所示：

这很有意思，笔者觉得这是中台建设重要的发展方向。比较可惜的由于某些原因的限制并未真正推广起来。

Tip

作为探索方向，业务信息化操作系统（BIOS）笔者也会另辟文章独立介绍。

小结回顾：技术、管理规范建设

笔者从一个个实际的问题出发，介绍了我们平台化、中台化的建设，这里做个小结。

3 A1 f; n8 v2 x, t; j5 x7 x: j  d

如上图，我们分别遇到了技术与管理两个方向的问题，技术侧问题的解决我们使用了统一的、覆盖研发核心流程的Dew微服务体系、各类规范、容器化环境；管理侧问题的解决我们制定了6S评价标准、设计了PMO监控、敏捷流程指导、着手研发服务标准化平台。

小白的白

管理侧问题的解决我们制定了6S评价标准、设计了PMO监控、敏捷流程指导、着手研发服务标准化平台。