微服务的痛：你的微服务还好吗？

在前面我们说了微服务的两个痛点：微服务的职责划分和微服务的粒度拆分痛点，这里接着聊剩下的痛点：

一、没人知道系统整体整体架构的全貌

不知道大家有没有碰到过这种情况：每隔几个月或半年，大领导就会发话让我们汇报下每个部门的微服务数量、公司微服务总数量、每个微服务都用来做什么等情况。因为企业微服务数较多，所以每次给大领导汇报时，都是长长的一条清单。

然后大领导开始抱怨：“几百个微服务？系统这么复杂了吗？谁能知道所有系统的全貌啊，如果出现问题，我们如何快速定位问题点呢？”此时负责人们只好乖乖地低着头，其中一个同事偷偷嘀咕：“我连自己部门的微服务列表都没搞清楚呢。”

在以前，我们首先会把公司的整个架构系统全貌搞清楚，之后一旦出现问题，也就容易定位故障点了。可是自从来到这家使用微服务的公司后，便再也没有这样的冲动了，只要求搞懂自己的一亩三分地就行，如果出现问题临时学习一下相关系统就好了。

因此，在实际工作中，很难找到这么一个人，他能知道系统整体架构的全貌，这就是微服务的一个痛点。

二、重复代码多

在以前的公司，我们把所有的代码放在了同一个工程中，如果发现某些代码可以重复使用，把这些代码抽取出来存放在 Common 包中就行。但是这种代码设计在微服务中经常会出现问题，这里我还是举个例子说明下。

比如某个团队做了一个日志自动埋点的功能，它能自动记录一些特定方法的调用。其他团队知道这个功能后，感觉很不错，想直接拿来用，于是埋点团队开心地给出了 Maven 的声明。但是第一个吃螃蟹的团队使用后，立马报出了一个 JAR 版本冲突问题，这时如果他们将冲突的 JAR 进行升级，原始代码就不能使用了。为节省人力成本，他们只好询问埋点团队如何实现版本兼容。

为了兼容这个螃蟹团队的 JAR 版本，自动埋点团队又重新设计了一版埋点的 JAR，并去掉了一些特定 API 的使用，最终 2 个团队终于可以正常使用了。

不过呢，第三个使用埋点的 JAR 的团队又汇报了一个 JAR 版本冲突问题，此时自动埋点团队从投入产出比角度考虑，不得不放弃维护这个公用的 JAR 了，并直接告知其他团队：代码就在 Git 上，你们自己直接 fork 修改吧。因此，这个代码在不同团队的微服务中最终存在了多个不同版本。

后来我们复盘了下，得出结论：重用 JAR 本身没有错，错就错在我们使用的 JAR 版本太多了，必须改变这个局面。

于是我们将所有 JAR 版本进行统一的项目正式立项了。第二天，因紧急业务需求下来了，大家都忘掉了这回事。又过了一段时间，有人提起了这个中心级项目，结果又被紧急的业务需求 PK 下去了。后来大家逐渐明白，这个项目没法做，因为投入产出比不高。

其实微服务之间存在重复的代码也没事，因为部门之间的重复代码比比皆是，而且技术中心每个部门都有自己的 framework/Common/shared/arc 的 GitLab subgroups，它们可以实现对部门内部的通用代码进行重用。

不过，维护这些小小的重复代码总比统一排期做重构、统一评审 JAR 版本的成本低得多。

三、耗费更多服务器资源

曾经了解到一个小公司。他们原来使用的是单体式架构，一共部署了 5 台服务器，后面他们一直抱怨系统耦合性太强，代码之间经常互相影响，并且强烈要求将架构进行迁移。

于是，根据业务模块，把原来的单体式架构拆分为了 6 个微服务。考虑到高可用，每个服务至少需要部署在 2 个节点上，再加上网关层需要 2 台服务器，最终，一共部署了 15 台服务器。（因为其中一个服务比较耗资源，为了保险起见，多加了一个节点。）

在这个拆分过程中，业务没有变，流量没有变，代码逻辑改动也不大，却无缘无故多出了 9 台服务器，为此事还发生过争执，当时的争议点是如果是这种情形，就不应该一台服务器只部署一种服务，比如我们可以把服务 AB 部署在 1 个节点，BC 服务部署在 1 个节点，AC 再部署在一个节点，如下图所示：

可是这个方案很快就被大家否定了，因为如果每个服务器只部署一种服务，服务器的名字直接以服务的名字命名就行，之后运维排查问题时也比较方便。可是如果我们把不同的微服务混合部署，服务器又该怎么命名呢？

于是，有人提议：“要不这样吧，反正服务器比较便宜，多几台也无所谓。”大家纷纷附和赞同。公司的钱就被这帮程序员浪费了，不过你别以为只有小公司这样做，大公司同样如此。

过了几天后，CTO 召集所有研发人员正式开会：“这个季度，我们的服务器预算太多了，财务部门审核不通过，你们需要想办法缩减一下服务器数量，把不用的服务器都下掉。”

会议结束后，大家各自回到工位，开始对每个服务进行检查，于是就有了下面这段对话。

A：“这个服务怎么使用了这么多台服务器？很耗资源吗？” B：“不是，主要是公司强制要求我们实现多数据中心部署。” A：“这个服务很重要吗？内部使用的吗？” B：“是，这个目前只是开发人员在使用。” A：“那干吗做负载均衡，下了下了，只留一台。” B：“好吧。” A：“现在我们缩减了多少台服务器了？” B：“……”

在大部分公司中，这种情形很常见，因此不得不说微服务真的很耗服务器。