0 0
Read Time:18 Second

此方案最大的好处便是: 各个微服务间对其所共享的 Shared Library 拥有所谓的选择权; 也就是说, 某个微服务可选择 1.0 版的 JAR, 另一个微服务则可以选择 1.5 版的 JAR。

当然, 缺点是: 当有数十个、上百个, 甚至是上千个微服务共享某个发生变更的 Shared Library 时, 则这些为数众多的微服务便得一一的重新启动后, 才能执行测试, 才能得知 Shared Library 的变更, 对各个微服务的影响。

Share Library 应尽量的能细分到某一特殊功能的粒度; : 某一庞大的 Backend.jar 应细分为 Persistence.jar, SQL.jar, Security.jar。某一大而全的 Utility.jar 亦应细分为 Calculator.jar, MaxTime.jar

这样的细分粒度, 将有利于能更精确的分析出, Shared Library 在每个版本中到底变更些了什么? 各微服务针对这些变更, 所应采取的相对应的措施为何?

About Post Author

方俊贤; Ken Fang

专利号: 201910652769.4; 一种深度学习的算法, 预测微服务持续发布、持续部署后对产品整体质量的影响, 获得国家知识财产局专利; 符合专利法实施细则第 44 条的规定。
Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据