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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如上图，PMO的管控示例。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

到这里大家是否觉得这样的中台建设演进已经比较完备了？

其实这些还都未能触及中台建设真正的难点重点，各位稍安勿躁，且看下文。