中台反思：技术中台设计架构

转眼间，在平台架构上笔者已折腾了 8、9 年，期间服务了四家公司，0 到 1 的交付过四个版本的平台/中台。本文将结合实际的工作总结、反思建设过程中新遇到的问题，探讨可行的方向。在阅读之前可先浏览《中台之路，从平台到中台的思考与实践（一）》(http://www.idealworld.group/2020/04/16/thinking-and-practice-from-platform-to-middle-platform-1/) 《中台之路，从平台到中台的思考与实践（二）》(http://www.idealworld.group/2020/04/16/thinking-and-practice-from-platform-to-middle-platform-2/)，这两篇文章中提及的问题本文不再赘述。

中台反思是一个系列文章，前后并不会有必然的逻辑关联，每篇文章反思一两个独立的问题，本文将从技术中台的设计架构切入。

技术中台的顶层设计

“技术中台长什么样子？”对于没接触过的同学而言这可能会是最需要解答的疑问，但对有技术中台经验的同学而言他多半会告诉你：技术中台是构建在业务中台、数据中台之下，为后者提供通用技术能力支撑的平台。如下图所示：

但是，真的仅仅是这样吗？我们知道“服务”是中台对外提供能力的核心载体，业务中台会向前台应用、后台系统露出操作型、事务型的服务，数据中台也需要将数据模型转成并露出分析型的服务。那么这些服务谁来管理？自然而然的这会落到技术中台。如下图所示：

技术中台除了其显而易见的提供开发框架、运行环境、监控预警等能力外，还需要提供服务管控能力，实现服务注册、发布、检索、订阅、编排等核心功能，进而实现中台能力的统一管控。

既然提到了服务，那么一些共性基础服务谁来管呢？技术中台必定当仁不让。因此我们会进一步演化成如下图所示：

所有的公共服务会沉淀在技术中台，一般而言，一个标准的技术中台需要提供如下服务：

• 用户权限：作为最基础的服务，提供租户化的应用/用户/角色/群组/资源管理、认证鉴权、安全审计等核心能力

• 服务管控：提供服务注册、发布、订阅、编排、分析在内的服务全流程管理能力；提供包含中台接入指南、服务介绍、API 文档、在线调试在内的服务商店能力

• 用户触达：提供短信、微信、钉钉、邮箱、站内信、Push 在内的多通道用户触达能力；提供智能流转，保障验证码类信息的触达率

• 规则决策：提供规则集、决策树、评分表等常规的决策形态；实现在线配置管理、实时调用监控

• 流程设计：提供可视化的流程、表单配置，实现复杂业务的流程管理能力

• 模型服务：提供模型/算法库管理能力，实现从需求到模型到调用的关联分析图谱；提供数据模型 SQL 查询转成 HTTP 服务调用能力

• 任务调度：提供分布式任务调用管理、执行、监控能力

除了这些常见的还有数据同步、多维监控、统一日志等各类更基础的服务。

到目前我们看到了最常见的技术中台架构：技术中台提供研发能力及公共服务以支撑业务中台、数据中台的服务建设。从云架构分层视角看实质是提供了 iPaaS 及 SaaS 层的支撑。那么这样有没有问题呢？

对于一般的企业而言，这样的技术中台足以支撑需求，但是随着需求广度、深度的扩展、下探我们会面临如下问题：

• 中台对前台应用及后台系统的支撑仅仅只能是服务形式吗？

• 中台要支撑前台应用的敏捷交付，有没有更好的方案？

• 中台除了支撑敏捷交付外能不能实现前台应用技术、架构、流程的统一？

• ……

笔者被问过很多这样的问题，究其本质是：想要的更多。对于领导、业务开发的同事而言，大家把中台想得太过“强大”了，觉得中台是解决 IT 问题的“万金油”，所以在你告诉他们我可以这样时总是被问及能不能那样。我们可以去科普中台的界限，但是我们为什么不进一步思考中台到底能不能给到更多呢？

业界也看到了目前技术中台的局限，也出现了一些解决的方向。比如阿里尚在研发中的 MSC（Middle-PlatformServiceComponents）就是其中典型的代表，它以四编排（模型、服务、流程、界面）引擎为核心实现可视化的应用构建。于是我们的架构会如下图所示：

在服务管控之上加入了能力编排，可用于开发简单的小应用。当然这种在原架构之上“硬生生”地添加一层必然存在缺陷，我们想做的本质是什么？我们希望的是加入低代码能力（LCDP)以支持应用级的交付而非服务级的支撑。因此我们需要强化研发能力，在架构上需要明确地划分出研发态与运行态。如下图所示：

可以看到几个明显的变化：

1. 提供了对应用开发全流程的支撑，可实现小型应用的在线可视化构建

2. 提供了原子服务补齐 PaaS 能力

3. 提供研发态的低代码构建平台补齐 aPaaS 能力

基于上述架构，技术中台有能力实现端到端的交付，为其提供了全面的 IT 研发支撑。对应的形成了中台对业务的四个支撑象限。如下图所示：

1. Coding BY: 使用中台基础技术能力实现应用开发

2. Coding ON: 在中台提供的服务能力之上实现应用开发

3. Coding IN: 在中台体系内实现全流程的应用开发

4. Building IN: 在中台体系内实现面向业务人员的应用构建与交付

如何设计低代码构建平台会在后续文章中介绍。

技术中台的团队架构

组织架构是中台建设成败的关键之一，这点笔者也是反复强调，下文将聚焦到技术中台内部的团队建设，聊一下架构上的变迁。

一开始，一般的技术中台会按面向技术及服务划分两个组：

1. 基础技术组：负责 IaaS、PaaS 层的产品建设，为上层服务提供基础技术支撑，包含但不限于服务支撑体系、DevOps、各云厂商中间件整合、特有技术能力研发

2. 公共服务组：负责 SaaS 层的产品建设，为各项目提供公共能力支撑，包含但不限于用户权限、服务管控、规则决策、流程设计、数据同步等各类服务

但随着支撑的深入后上述组织划分会受到如下挑战：

1. 业务支撑不力技术中台重研发轻运营，无法及时响应使用方的需求业务有优先级，无法按其权重支撑团队人员有限，无法应对突发的支撑需求

2. 能力沉淀不足中台需求无法很好地识别，需求边界模糊需求缺乏抽象，比较难补强产品力

3. 内控缺位质量管控缺标准化，没有独立的流程质量管控，两个组间执行的流程标准不统一技术架构缺体系化，没有对两组间的技术架构统一审查，导致技术选型不统一

为应对上述问题，我们优化了组织架构。如下图所示：

1. 基础技术组：负责 IAAS、PAAS 层的产品建设，为上层服务提供基础技术支撑，包含但不限于服务支撑体系、DevOps、各云厂商中间件整合、特有技术能力研发

2. 公共服务组：负责 SaaS 层的产品建设，为各项目提供公共能力支撑，包含但不限于用户权限、服务管控、规则决策、流程设计、数据同步等各类服务

3. 解决方案组：负责解决方案导向的针对各产品的整合，研发低代码构建平台，实现 aPaaS 层能力；编制面向不同行业、需求的技术解决方案，为使用方提供完整的能力支撑

4. 能力交付组：负责平台产品的顶层设计、使用反馈及能力输出，衔接平台能力与业务项目，包含但不限于需求收集与分析、服务接入、使用反馈、二次开发指导等服务

5. 架构管控组（虚拟）：统筹产品及技术体系架构设计，各产品迭代的需求及技术设计

6. 质量管控组（虚拟）：负责平台产品的流程、质量程控，覆盖需求采集分析、产品技术架构、迭代编码开发、测试修正发布等研发的全生命周期标准化管控

能力交付组用于解决业务支撑不力及能力沉淀不足的问题，由产品经理、中台开发及前台应用开发组成，产品经理划归到此组以获取一手的业务需求。该组衔接公共服务、基础技术组与需求方，避免未经验证的或是突发的需求打乱整体的产品研发节奏，对于边界模糊的需求可由该组开发，验证可产品化后再转入公共服务或是基础技术组完善。另外该组成员可动态增减前台应用开发，以解决中台资源不足导致的支撑问题。

质量管控及架构管控一同解决了内控缺位的问题。

解决方案组一方面通过低代码构建平台的研发，整合公共服务及基础技术产品；另一方面面向大客户编制定制化的解决方案以提升技术中台的产品力。

通过上述组织优化分别实现了横纵双向的组织贯通，提升了协作的效率。

关注我的公众号：

中台反思：技术中台设计架构​mp.weixin.qq.com