后端，大型的分布式系统下有啥好的依赖升级管理技术方案么？

[cubecube]

面试的问题，大概率挂了。
我大概说了说
1. 在组织内部统一标准化化依赖的版本管理
2. 对核心依赖升级进行评估协调处理
3. 让被依赖的技术 or 业务模块保持向后兼容性
4. 部分模块的 API 使用可以做适配器保持系统内部逻辑的稳定性
5. 升级过程优化，保证服务有序关闭和平滑升级。

以上貌似都没 get 到面试官的点，一直被强调要考虑技术上怎么去处理该问题。
这种针对技术基础依赖和某些业务依赖的管理升级过程，这块技术上有啥好的方案么？

[xuanbg]

1 、没有新需求，绝不引人新依赖。
2 、新版本新项目新依赖，老版本老项目绝不升级依赖包。

庶几，可天下无事矣。

[cubecube]

@xuanbg 面试这么答肯定不行啊。你看我说的统一标准化依赖管理，就是这个意思嘛

[lst2008]

parent?

[xuanbg]

@cubecube 在工程上面，弄个模板复制粘贴最省事。别的都是浮云，毕竟依赖管理这个事情太复杂。面试的话，人家想知道的是你能不能说清楚这个事情的核心是什么、解决问题思路是什么。

依赖管理的核心就是包的版本，核心问题就是版本冲突。然后，你会发现这个问题是没有普适的完美解的，总有幺蛾子。所以大家就都只能因地制宜，每个项目各管各的。做统一的依赖管理那是吃力不讨好……

[yuyu12]

找下阿里 Pandora 的思路。

[index90]

对于研发：
1. 有损服务
2. 接口兼容
3. 数据库兼容
对于部署：
1. 部署编排
2. 蓝绿部署
3. 金丝雀发布

[Oktfolio]

@yuyu12 一个 StringUtils 都不下二十个包路径。

[cubecube]

@yuyu12 我看了看，潘多拉的思路，还是基于 fatjar 这种固化依赖来弄的，感觉并没有解决因此升级的问题，就是不升级呗，可能我还是和面试官还是对于问题理解不一致吧

[cubecube]

@index90 差不多吧，哈哈，我感觉这么答貌似也不行。面试官可能想我回答容器化依赖隔离

[IMCA1024]

...emmm 太多名词不知道怎么说

直接问 什么问题，然后给出自己的解决方法。。

[xizismile]

面试官可能想听的是 service mesh 方案

[cubecube]

@xizismile 这个，国内有实施落地的么？感觉还在概念阶段呀

[yuelang85]

我第一个想法就是 docker 。。。。封装环境，回避依赖升级。如果真需要升级，就是模块级别

[chihiro2014]

参考下 Service mesh，金丝雀发布确实是个不错的选择，将主要流量分给老系统，次要流量分给新系统，等新系统稳定了，再逐步升级上去。就算炸了，还能走以前的不是？
https://www.bilibili.com/video/BV17t411E7rV

[CoderGeek]

想到向下兼容 - - 最近在搞这个问题 233

[xizismile]

@cubecube 大厂像阿里啥的，应该都落地了吧，看看他们的技术分享、博客

[luozic]

https://mp.weixin.qq.com/s?__biz=MzA3MDMwOTcwMg==&mid=2650005790&idx=1&sn=ca7fda1a8d135f9ae72bc21bad486cc5

[cubecube]

更新下，已挂。