3000w人民币的学费——我的决策反思

我刚入公司时，集团下的一家公司系统问题频出、能力无法复用给其它兄弟公司，所以CTO提出了平台化服务化发展，我成了主要的执行人，而这就是我要说的问题的开始。

在平台化的基础是服务化建设，彼时（2017年中旬）集团各公司用的是dubbo框架，而dubbo已停止维护多年，所以我们以Spring Cloud为基础着手构建内部的微服务框架。

《人月神话》说 沟通成本 = n(n-1)/2 即人越多沟通会越加困难，微服务架构设计有一指导原则或是与其它架构比的优越性证明： 康威定律 ，对其解读中重要的一条是“什么样的组织产生什么样的设计”，所以目前的微服务架构都提倡将组织架构打散，将各职能角色划分到每个项目组中。

(来源)

(来源)

也许是我过于信奉这些理论，也也许是我理解有偏差，最终就是按这种方式开始了组织微服务化建设，并且也由于微服务本身对多语言、异构框架的友好性及不同项目组人员技术的特质差异，我容许在微服务架构下用多语言，虽然在内部为微服务构建的统一开发框架（Dew Famework）但也默许使用其它框架。经过一年左右的发展，各项目组分别研发了用户中心、消息中心、APP版本管理、资金中心等多个公共产品。

而这些公共产品也支撑了公司的一些核心业务，做到了能力复用。此时我们都觉得平台化是成功的。但一些潜在的问题却在逐步显现，在平台化建设的过程中我也有意识到，年度报告时我总结为“标准缺位”。

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

最后，所有产品看起来都是微服务架构的，但长得却各不一样。

为了解决这些问题，我从两点入手：

这些举措的确会起到一定的效果，但时间窗口已过了，没有使用Dew的项目改造有成本，推动不了。但如果错误止于此，那还算可控，大不了行政命令强制改造，一次性的重构成本也不过100万。

积重难返是缺乏服务规划，服务与服务间依赖不清、产品间部分服务功能重合。在业务忙时一些非核心的看似几个团队都可以实现的功能没有团队主动承接，业务闲时一些非核心的功能几个团队抢着做。平台化2年多产生了大量重复的建设，并且难以合并。 服务规划缺位导致产品间、服务间边界不清楚，耦合严重、资源浪费 。效率是企业永恒的诉求，微服务本应该是用于提升多部门、跨团队协作的效率，但事与愿违，效率不升反降。

那这块一开始没有意识到吗？实际上开始平台化、微服务建设时还真是预见到这一可能的问题，CTO提出了领域边界划分，只是从理念设计到实施落地落差太大，究其原因固然有执行不到的问题，但核心问题在于分子公司、部门间的利益斗争。 组织治理是服务化成败的先决条件 不久前我们开始了中台化建设，但组织架构没理顺，中台化也就无从谈起。团队利益、绩效梳理却最为复杂且难以实施，这块上我们做过多次调整，但效果很不明显。

下面我举几个案例进一步说明问题：

在业务蒸蒸日上时，很少有企业会去做研发治理，资源浪费点没问题，只要能快速支撑到业务，不出故障就可以，水大鱼大，所有问题都被业务的表象所掩盖。“只有当潮水退去的时候，才知道谁在裸泳”。一但业务下行技术的问题才会暴露、放大，这时我们才会发现想做资源节流，但 1）各项目技术架构差异大 2）项目人员划分过于清晰 3）项目重复建设，想合并又有这样那样的阻力，导致人员优化不了，服务器资源回收不了。最直观的感受领导看起来我们这块业务都快停了，为什么还要这么多的技术，这么多的云资源开支？

以前我们一直在做公共平台，提供都是基础服务，对应于中台化建设而言是其公共业务中台、数据中台及研发中台，但我们想要的是更贴近业务的中台能力，比如电商上的商品、订单、供应链等产品，因此我们近期也做了这些领域中台产品的研发，但问题在于这些领域中台没有做更高维度的抽象，比如商品中心、订单中心等产品只关注了电商业务的能力，但对保险业务下的保险产品商城、金融业务下的金融超市及综合业务下积分商城都无法实现复用，这种跨行业的复用才能确保产品价值的最大化，但这需要有一定高度的业务、产品、技术专家团队做好顶层设计。

以前我们所有的项目产品都是为集团内部的各分子公司服务，服务化后形成的各产品间的依赖问题不是很明显，但随着技术往外走，我们去服务一些传统企业，保险、银行等机构时他们需要的是本地化部署，这时客户可能只要一个业务产品，但由此牵出的依赖服务有一大堆，部署非常地重，这就是典型的服务边界划分不清、服务规划不明导致的问题。

总结上面的问题，我整理了一下这些年犯的错误：

这三个错误组合在一起最直观的感觉是人很多，事很多，但输出少、质量差，想要做优化，但却牵一发而动全身，改不动。