多城市落地中台的问题和标准化

当前接触到中台和微服务项目技术支持和落地的城市有多个，涵盖一二三线城市，以下为自己一些思路总结。

于2020年下半年，贵阳的一个项目二期整体上线，使用最新的AI技术路线，几乎都是新的试点尝试，完全互联网思维落地政务项目，快速交付，快速落地，又是完全另一种打法。 从二线城市项目技术支持和规划过程中，联想其它城市项目技术支持过程中的一些中台经验总结，我有我思。

关于中台落地项目建设的情况

针对于多个城市的情况，每个项目基本上都带有较为完整的业务体系。

有基础软件平台的体系雏形

中台建议从技术引入、试点、建设、运维，整个结构有了软件平台的原型，从操作系统、控件、第三方、中间件、技术、基础组件、知识积累等都有较为完善的体系，包括目前多团队接触，消化的情况都较为良好，市场教育和人才培养基本上都有基础；

有大量的基础包

从每个项目建设到现在，积累了很多的基础控件，基础控件指的是常用的基础包、工具、统一变量等，以前的，包括现在的项目都积累很多的基础包和工程，而这些工程包又有很多是重复的，同样的；

有较为完善的基础组件体系

从业务组件的规划过程中，有较为完善的基础组件，公共组件，公共服务，业务组件，同时存在很多的业务组件，重复的基础工程组件，比如短信、ORC、打印、公共、统一桌面，这些基础组件体系都存在，且具有成熟性（并涉及多个业务场景，多个项目场景，并不代表没有bug），但是一样存在重复的，不可共用的情况；

有较为完善的业务组件体系

从几个城市项目工程，每个行业项目基本上都积累了较为完善的业务组件体系， 成百上千的业务组件，上万的外部接口 ，信息管理类项目（如管理系统、OA），这些组件都包含有业务性，涉及和比较完整的政务行业业务，甚至可以理解（可能自己业务理解不够深入的理解）成较为完善的政务行业信息体系模型；

不足之处及问题反思：

正是以上的情况，才导致引出问题点所在。

微服务规划的缺陷和技术债问题

差异化项目规划有太多的服务，而服务之间不能通用，导致产生重复的服务规划而不能共用，而产生很多的重复技术债问题（这点在开发人员在过程是比较难有体会，比如开发某模块出问题了就调试，精力都会往调试技术比例加重，业务调试比重降低），服务规划之间并不能完全符合我们目前团队场景和业务场景而进行共用（比如一个实际场景：多城市、多项目、多团队、跨地域开发）。

基本上都是沟通相当难，而且过程支持也不容易，特别是跨地域，跨团队

没有明确的里程碑目标和稳定版

一直在微服务，总是在微服务。

这个问题最明显，同样也是最实际，当前的工程一直是快照版，至今没有基础稳定版，这个问题会导致一个很明显的问题，开发一更新就有可能出错，即使之前的项目已经上线稳定。有一个稳定版，开发在使用的调用的时候，开发就会用这个版本或者加强，而不是多个城市或者项目的复制，在团队资源有限的情况下，很难消化每一次“复制”带来的几十个工程的维护，甚至有些苦涩。

原架构设计存在缺陷

原单个项目的技术架构设计或者整个平台架构设计，组件规划，在单个项目，或者在小型项目上，具体一定的先进性，但是在与我们实际团队与项目中时，出现水土不服或者说是未能达到预期效果，甚至可能出现部分不理想效果，比如硬件、软件、技术债上都比较难消化 ，架构师的设计，包括网上（互联网）存在一定的先入为主，很多原接触的名词未必符合我们的场景，如高并发，高可用，微服务，多服务，分布式。

平台体系不完善

体现在没有合理的基础环境建设，比如租户隔离，环境隔离，容易产生互相影响问题。缺少技术上（而非业务）自动化运维建设，服务的检测、发布和监控，还是较为被动的接受，而多数是人工很难做到这步，技术运维和业务运维两个比重权衡考虑。

中台标准化建设思路 ：

提取出业务核心元素，整体低阶业务平台，推进形成行业业务标准化。

调整平台架构设计，重点往业务SaaS建设：

业务和平台架构设计使用的是着重于业务架构建设，提升稳定性，维护性，快速迭代性，在基础组件和控件完善的条件下，调整原有的平台架构规划和组件规划，往业务组件建设，基础组件，基础控件与开发人员做一定的隔离（另一个词叫透明）。 在目前的完善的业务组件体系下，提取业务组件的核心业务元素，重点在业务的SaaS建设，减少业务切入成本（如新人学习业务成本，调用api即可，不符合再继承单独实现），减少技术债成本（如业务api，维护提取的只维护SaaS），减少运维风险成本（即稳定版和快照版的问题）。

在看微服务架构和中台架构时，工程有这样的设计趋势，但是在对于差异化业务服务时，但是没有将原设计精华提取，消化并整合到整体架构设计中。

制定稳定版本，调整服务规划为API规划：

一个明显且事实的现象：在我们的业务场景里，每个城市业务规划的服务在多城市之间，多项目之间是不能共用的，都是复制。

设计规划往上再进行一层抽象，调整服务规划转变成API规划，项目在SaaS的API上层改造，而不是在服务上进行改造，服务只是依赖api。比如业务系统系统api，新的项目只是在业务系统的api上层改造，而不是复制整个业务工程，api有版本号，而不是一直是快照版，有快照版的应该是工程，而不是api。减少工程泛滥的情况，同时减少组件维护成本。至于服务规划，只是在项目时再做规划即可，与t规划无差异。

完善运维体系和建设目标：

使用云基础环境方案，市面上已经有很多成熟的云基础方案，比如CloudStack、Kubernetes、OpenStack等，解决资源的不合理使用问题和租户问题。自动化运维建议尝试使用能用的检测方案，如批脚本监控，自动检测端口，常规自动巡检等。

总结

从多城市技术支持过程中联想到的平台的经验总结和一些建议，包含有一定的主观和客观，请参考和了解 。