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

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

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

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

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

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

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

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

发表评论

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

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