0
0
Read Time:18 Second
微服务架构设计的误解 ？
我想，大家对于微服务还是有著一些的误解，所以，我在这提出些我个人的看法：
1. 微服务是将原本在单体应用系统开发时所面临到的复杂度，转移到了测试与运维。而且这种的复杂度的转移，并不是 1:1 的转移，而是呈现指数型增长方式的转移。也就是说微服务在测试、运维方面的复杂度比起单体应用系统在测试、运维方面的复杂度，要高出了许多、许多。
2. 微服务的测试远比起微服务的开发，要更为的复杂，当然也更加的重要的多，但真正懂得去关注的人似乎并不多。
3. 在数百个甚至是上千个的微服务下，我们已无法再用着在单体应用系统下，使用 Scrum 的方式，进行着人与人之间的沟通，因为，那将会太耗时，而且沟通的复杂度、成本也将会过高。
4. 在数百个甚至是上千个的微服务下，我们只能借由测试；如：契约测试；先分析出值得进行人与人之间沟通的议题，我们已无法事事都在进行着人与人之间的沟通。
5. 微服务不是要降低在单体应用系统时，我们所面临到的复杂度，而是要能做到持续交付；单体应用系统是永远都做不到持续交付的。
6. 微服务虽然在测试、运维的复杂度高出了许多，但借由自动化的测试、运维工具，甚至是机器学习，都能高效、大幅的降低这方面的复杂度。
7. 微服务要能成功，一定要有个能开发自动化测试、运维工具的团队，支撑着团队在开发微服务的这件事情上。
Happy
0 %
Sad
0 %
Excited
0 %
Sleepy
0 %
Angry
0 %
Surprise
0 %
