关于后端:微服务的战争统一且标准化

“微服务的和平”是一个对于微服务设计思考的系列题材 ????，次要是针对在微服务化后所呈现的一些矛盾 / 冲突点，不波及具体某一个知识点深刻。如果你有任何问题或倡议，能够微信搜一搜 【脑子进煎鱼了】 或我的博客进行沟通和交换。

在远古开天辟地时，大单体转换成微服务化后，服务的数量越来越多。每起一个新的服务，就得把我的项目的目录构造，根底代码重新整理一遍，并且很有可能都是从最后的 template 上 ctrl+c，ctrl+v 复制进去的产物，如下：

然而基于 template 的模式，很快就会遇到各种各样的新问题：

随着跨事业部 / 业务组的应用增多，你基本不晓得框架的 template 是什么工夫节点被复制粘贴进来的，也不晓得所对应的 commit-id 是什么，更不晓得先前的 BUG 修复了没，也不晓得有没有其余开发人员私下改过被复制走的 template。

简略来讲，就是不具备可维护性，绝对独立，BUG 可能一样，但却没有版本可规管。这时候，就能够抉择做一个外部根底框架和对应的外部工具（曾经有用户市场了），造成一个脚手架闭环：

通过根底工具 + 根底接口的形式，就能够解决我的项目 A、B、C… 的根底框架版本治理和公共保护的问题，且在遇到框架 BUG 时，只须要间接 upgrade 就好了。而在框架维护者层面，还能通过注册机制晓得目前根底框架的应用状况（例如：版本散布），便于后续的迭代和布局。

同时若外部微服务依赖简单，能够将脚手架间接“降级”，再做多一层根底平台，通过 CI/CD 平台等关联创立利用，抉择利用类型等根本信息，而后关联创立对应的利用模板、构建工具、网关、数据库、接口平台、初始化自动化用例等：

至此，就能够通过联合根底平台（例如：CI/CD）实现流程上的标准化管制，成为一个提效好帮手。

但，所有都有“开天辟地”那么顺利吗。实际上并不，在很多的公司中，大多数是在不同的工夫阶段在不同的团队同时进行了多个开天辟地。

更具现化来讲，就是在一家公司内，不同的团队里做出了多种根底工具和根底框架。更要命的是，他们几家的标准可能还不大一样。例如：框架在 gRPC 错误码的标准解决上的差别：

又或是 HTTP 状态码的差别：

粗略一看，单单在利用错误码 / 状态码这一件事件上，就可能玩出花色。而这件事又会导致各种问题，例如在监控平台上，因为不同团队所定义的状态码标准不一样，就会导致连根本的监控可用性都会有问题。

像是有的小伙伴会把业务错误码放在 grpc-status 属性中，而在规范 gRPC 的标准中 grpc-status 是和 HTTP Status Code 一样有特定状态码映射的。这时候就会让监控告警零碎非常难做，通用的告警规定到底是以哪份状态码为准？

往往最终演进的路线与企业的组织构造无关，也就是康威定律，一个零碎的技术边界反映组织的构造。业界常见的是两种状况：

显然，这其中利与弊就要各自判断了，多少厂外部有多少个框架，也有血汗厂根本一统江湖的，可能做基础架构适配的小伙伴会比拟有感触，不同框架的 Header 标准不一样，这样子即便是 Mesh 也防止不了一顿 if else。

更甚的是，在相似服务发现 / 注册、限流熔断、根底拦截器，各类 SDK 同个厂的每个外部框架都重现实现一遍。美其名曰框架反对了这些，就容许让他上，但这样子怕是在将来又造成了新的一波技术债权。

同时框架维护者，是有可能到职跳槽到别家去的，这在前端届也层出不穷，带着修炼好的真经走了，留下一个没有人保护的组内框架，这时候只能硬着头皮找 B/C 角来承受，顶上来的人指不定思维还不一样。

这单从公司层面来讲，是一个微小的挫伤，久远来看着实是劫难。

在本文中，主体分为了“开天辟地”和“公众翻新”两块内容，现实是饱满的，而事实怕是很骨感。微服务是一把双刃剑，带来益处的同时往往也带来了背面，架构的复杂度很难预知，因而实质上须要一个基架团队不忘初心，继续发现，继续解决问题。

但不论如何，及早的把主力语言、根本技术栈均根本对立起来，做好产品闭环，会是一个很好的方向。

如果具体到要做的事件，须要有一个明事理的下级，清晰的意识到同个子公司内的技术体系最好是基本一致的，由基础架构组或相干领头人拉齐外围 Leader，定义根本标准，构建对立框架，交融 CI/CD 平台。

当然，反之倒推也是能够的（横蛮成长），就是步骤更多了，更难了。

开天辟地