0 0
Read Time:18 Second

微服务架构设计的误解 ?

我想,大家对于微服务还是有著一些的误解,所以,我在这提出些我个人的看法:

1. 微服务是将原本在单体应用系统开发时所面临到的复杂度,转移到了测试与运维。而且这种的复杂度的转移,并不是 1:1 的转移,而是呈现指数型增长方式的转移。也就是说微服务在测试、运维方面的复杂度比起单体应用系统在测试、运维方面的复杂度,要高出了许多、许多。

2. 微服务的测试远比起微服务的开发,要更为的复杂,当然也更加的重要的多,但真正懂得去关注的人似乎并不多。

3. 在数百个甚至是上千个的微服务下,我们已无法再用着在单体应用系统下,使用 Scrum 的方式,进行着人与人之间的沟通,因为,那将会太耗时,而且沟通的复杂度、成本也将会过高。

4. 在数百个甚至是上千个的微服务下,我们只能借由测试;如:契约测试;先分析出值得进行人与人之间沟通的议题,我们已无法事事都在进行着人与人之间的沟通。

5. 微服务不是要降低在单体应用系统时,我们所面临到的复杂度,而是要能做到持续交付;单体应用系统是永远都做不到持续交付的。

6. 微服务虽然在测试、运维的复杂度高出了许多,但借由自动化的测试、运维工具,甚至是机器学习,都能高效、大幅的降低这方面的复杂度。

7. 微服务要能成功,一定要有个能开发自动化测试、运维工具的团队,支撑着团队在开发微服务的这件事情上。

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来减少垃圾评论。了解我们如何处理您的评论数据