这是一个创建于 1705 天前的主题，其中的信息可能已经有所发展或是发生改变。
面试的问题，大概率挂了。
我大概说了说
1. 在组织内部统一标准化化依赖的版本管理
2. 对核心依赖升级进行评估协调处理
3. 让被依赖的技术 or 业务模块保持向后兼容性
4. 部分模块的 API 使用可以做适配器保持系统内部逻辑的稳定性
5. 升级过程优化，保证服务有序关闭和平滑升级。
以上貌似都没 get 到面试官的点，一直被强调要考虑技术上怎么去处理该问题。
这种针对技术基础依赖和某些业务依赖的管理升级过程，这块技术上有啥好的方案么？
我大概说了说
1. 在组织内部统一标准化化依赖的版本管理
2. 对核心依赖升级进行评估协调处理
3. 让被依赖的技术 or 业务模块保持向后兼容性
4. 部分模块的 API 使用可以做适配器保持系统内部逻辑的稳定性
5. 升级过程优化，保证服务有序关闭和平滑升级。
以上貌似都没 get 到面试官的点，一直被强调要考虑技术上怎么去处理该问题。
这种针对技术基础依赖和某些业务依赖的管理升级过程，这块技术上有啥好的方案么？
 |
1
xuanbg 2020-04-29 15:56:34 +08:00
1 、没有新需求，绝不引人新依赖。
2 、新版本新项目新依赖，老版本老项目绝不升级依赖包。 庶几，可天下无事矣。 |
 |
3
lst2008 2020-04-29 15:59:52 +08:00
parent?
|
|
4
xuanbg 2020-04-29 16:11:37 +08:00
@cubecube 在工程上面，弄个模板复制粘贴最省事。别的都是浮云，毕竟依赖管理这个事情太复杂。面试的话，人家想知道的是你能不能说清楚这个事情的核心是什么、解决问题思路是什么。
依赖管理的核心就是包的版本，核心问题就是版本冲突。然后，你会发现这个问题是没有普适的完美解的，总有幺蛾子。所以大家就都只能因地制宜，每个项目各管各的。做统一的依赖管理那是吃力不讨好…… |
 |
5
yuyu12 2020-04-29 16:12:18 +08:00
找下阿里 Pandora 的思路。
|
 |
6
index90 2020-04-29 16:25:34 +08:00
对于研发：
1. 有损服务 2. 接口兼容 3. 数据库兼容 对于部署： 1. 部署编排 2. 蓝绿部署 3. 金丝雀发布 |
 |
8
cubecube OP @yuyu12 我看了看，潘多拉的思路，还是基于 fatjar 这种固化依赖来弄的，感觉并没有解决因此升级的问题，就是不升级呗，可能我还是和面试官还是对于问题理解不一致吧
|
 |
10
IMCA1024 2020-04-29 17:49:27 +08:00
...emmm 太多名词不知道怎么说
直接问 什么问题，然后给出自己的解决方法。。 |
 |
11
xizismile 2020-04-29 18:08:06 +08:00 via Android
面试官可能想听的是 service mesh 方案
|
 |
13
yuelang85 2020-04-29 18:48:58 +08:00
我第一个想法就是 docker 。。。。封装环境，回避依赖升级。如果真需要升级，就是模块级别
|
 |
14
chihiro2014 2020-04-29 19:00:54 +08:00
参考下 Service mesh，金丝雀发布确实是个不错的选择，将主要流量分给老系统，次要流量分给新系统，等新系统稳定了，再逐步升级上去。就算炸了，还能走以前的不是？
https://www.bilibili.com/video/BV17t411E7rV |
 |
15
CoderGeek 2020-04-29 19:10:21 +08:00
想到向下兼容 - - 最近在搞这个问题 233
|
 |
17
luozic 2020-04-30 13:57:35 +08:00
|
|
18
cubecube OP 更新下，已挂。
|
Select Language