
Read Time:18 Second
微服务架构设计的误解 ?
我想,大家对于微服务还是有著一些的误解,所以,我在这提出些我个人的看法:
1. 微服务是将原本在单体应用系统开发时所面临到的复杂度,转移到了测试与运维。而且这种的复杂度的转移,并不是 1:1 的转移,而是呈现指数型增长方式的转移。也就是说微服务在测试、运维方面的复杂度比起单体应用系统在测试、运维方面的复杂度,要高出了许多、许多。
2. 微服务的测试远比起微服务的开发,要更为的复杂,当然也更加的重要的多,但真正懂得去关注的人似乎并不多。
3. 在数百个甚至是上千个的微服务下,我们已无法再用着在单体应用系统下,使用 Scrum 的方式,进行着人与人之间的沟通,因为,那将会太耗时,而且沟通的复杂度、成本也将会过高。
4. 在数百个甚至是上千个的微服务下,我们只能借由测试;如:契约测试;先分析出值得进行人与人之间沟通的议题,我们已无法事事都在进行着人与人之间的沟通。
5. 微服务不是要降低在单体应用系统时,我们所面临到的复杂度,而是要能做到持续交付;单体应用系统是永远都做不到持续交付的。
6. 微服务虽然在测试、运维的复杂度高出了许多,但借由自动化的测试、运维工具,甚至是机器学习,都能高效、大幅的降低这方面的复杂度。
7. 微服务要能成功,一定要有个能开发自动化测试、运维工具的团队,支撑着团队在开发微服务的这件事情上。
About Post Author
方俊贤; Ken Fang
专利号: 201910652769.4; 一种深度学习的算法, 预测微服务持续发布、持续部署后对产品整体质量的影响, 获得国家知识财产局专利; 符合专利法实施细则第 44 条的规定。