美团项目升级28： 升级微服务插件

业务背景

美团升级的时候，有一个插件需要升级。

聊聊什么叫做插件

有一天，你想增加一个新的、非核心业务的功能，比如打印日志。 于是，你使用了AOP技术，在服务中新增了一个切面来解决。

但是有的技术他实现起来更复杂：

• A、BC三个微服务部署完成以后
• 为了协助A、B、C微服务来解决一些边缘业务，实现了一个微服务D，通过类似反射的技术来实现采集ABC的日志/监控/调优等等等等

美团自研了一个框架。

问题描述

我不知道他是怎么实现的： 部署方式，代码实现，什么都不知道 我不知道修改这个服务是否会影响主业务的正常运行（理论上来说不会，但是实际上可能有副作用） 代码不是我写的。

我需要花好几倍的时间来了解业务流程和框架，才能保证万无一失。 工期至少要好几倍。

然后：使用该方案的时候，根本没有考虑到会升级这个场景。

解决方案

• 谁写的谁升级。这样就能快速的解决问题，跳过熟悉流程。bug率少

但是，升级这个事情是我负责的，交接人是美团的正编，我指挥不动。

• 我需要找到领导的领导进行汇报，然后他确认这个有风险
• 领导确认无误以后，告知美团正编，美团正编进行排期

第二个方案：加工期 + 完整测试

第三个方案：先搞比较好解决的，将难以解决的滞后。

• 这样给领导汇报好看
• 先搞好搞的增加经验，当经验足够以后就不是问题了

第四种方案：写的丑。 使用try catch + instanceOf这种方案来解决。

• 但是这种质量的代码，美团肯定没法验收

汇报

于是，我就和我的领导进行了汇报，表示这个升级不动。 领导：很简单啊，这是个插件。先升级了。

你这就相当于：你和Faker对线，你玩死歌。你只需要降低faker的血量到一个R就能斩杀的情况下放一个R就行了。

于是进行了沟通，提出方案：希望放在后面。 领导拒绝，表示请列出工期。

工期肯定也无法接受。

那怎么办？？ 僵住了。

后来：我不负责这个项目的升级了，实在是沟通成本太高，人力成本爆炸。

总结

美团自研框架，根本不熟悉也没文档，导致升级难度非常大。 插件生态，担心修改会有副作用。 代码非本人编写，完全不熟悉。 沟通成本太高，多种方案没有一个可行，导致项目无法按期交付