1.中台，前台的本质
中台的本质为服务重用，通过松耦合的服务组件带来业务复用，通过服务组件的编排对业务前台的快速响应和共享。前台的作用主要根据不同项目的业务需求和产品的定位来构建，聚焦定制化业务与扩展，组装下游能力。大中台、小前台的设计，是服务重用的组织保证。
image.png
2. 云管平台迭代遇到的问题
云管从前期的csc演变到目前的wincloud，搭建开发一个全新系统不难，但要维护好却很困难，随着市面技术的不断更新迭代，一个软件产品的生命周期可能就那么几年时间，后期一旦因为技术因素推倒重来，如果前期没有管控规划好，最终会发现以前积淀的东西太少，可复用的组件太少，代价之大。另外由于大多数云管平台项目都涉及到定制化需求的开发，每个项目的定制化开发都交由不同的项目开发组负责，而当前的开发模式偏向“烟囱式”后台架构模式 。“烟囱式”模式主要体现在每个定制化项目由不同的开发团队独立维护整个项目所有组件，互不联系。如图：
image.png
“烟囱式”模式带来一定的问题：
(1)重复功能建设和维护带来的重复投资。云管大部分功能和业务在不同的项目中是同时存在，如果每个团队都需维护系统所有组件，仅从开发和运维两方面成本投入的角度，是一种很显性的成本和资源浪费。典型的场景两个团队很可能在同时开发同样的功能，重复解决同样技术问题，同时写差不多的代码；或者经常需要排期把产品某个功能代码移植到某个具体项目上。
(2)不利于业务的沉淀和持续发展。随着公司的发展，项目越来越多，业务需求与日俱增，每个项目的前线都要求后端进行快速响应，项目团队人数也跟随项目不断扩张，而这种模式的迭代周期终将导致项目组对业务的响应和支持会越来越吃力紧张，服务间耦合度越来越强，利用率低；同时每个项目成员得熟悉每个产品组件的业务逻辑，加深学习成本，不利于新人快速介入。
3.中台化的演进
云管并不是专门为了“中台”才进行中台改造。我们一直希望能够将底层技术栈统一和产品功能组件化，从而让产品在更新迭代、创新拓展的过程中研发更灵活、业务更敏捷，让定制化项目团队不需要每次去改动底层功能进行研发，而是在底层不变动的情况在更丰富灵活的各种服务基础上获取支持，让“前台”更加灵活敏捷。随着产品版本的迭代与架构探索，慢慢地发现这种演进思想更类似所谓 “中台化”思路。
我们逐步在调整架构，把云管平台的公共功能逐步收敛为基础的业务组件，下沉形成标准化逻辑，如多云管理，组织权限、服务目录，流程审批，计量计费等能力，这些基础的服务组件会将会被所有项目共享调用，维一由产品开发团队管理维护；同时推动各个产品线技术栈高度统一，例如开发框架统一用SpringCloud、消息组件统一用RabbitMQ、缓存统一用Redis、关系型数据库mysql，K8S、统一持续集成、持续交付等。调整后的架构图将如下
image.png
整体架构调整按照领域设计分层架构，严格区分应用层、领域层。相比之前区别，领域层聚焦可复用能力，专注策略、玩法的改进。整个架构增加一个应用适配层，应用层聚焦业务识别与扩展，组装下游能力，为上层页面提供灵活的响应，后续项目开发团队只需了解下游可提供哪些能力，无需关注组件具体实现细节。项目开发组专注定制化需求的开发，每个项目只需维护好相应的应用适配层与前端页面就可以，从而达到把主流程链路变短，出问题也更容易定位及解决。
相比之前的架构，新的架构将体现以下优势：
l 提高利用率，减少重复造轮子、重复探索的成本。
l 降低维护成本。
l 解除下层各类组件的依赖，又能将下层组件适当聚合，为上层提供灵活的响应。
l 产品开发组专注产品组件的开发，敏捷响应新形势、新挑战。
l 项目开发团队聚焦定制化需求，践行以客户为中心。
4.面临的挑战与问题
当前业务中台化的演进也将面临一些问题，如中台服务容易被前端带节奏、走捷径，导致最终服务变形；经常得评估确定相关功能点是否属于服务组件的基本能力，对产品需求的合理性与研发人员的能力将提出更高要求，同时需要每个产品版本与每个项目迭代有专人整体统筹考虑，统一规划，划清业务边界，导致依赖评审与决策流程。
image.png
网友评论