下载掌阅APP，畅读海量书库
立即打开
接下来的内容是本章中关于微服务架构的又一个思考：系统架构升级改造时一定会用到微服务吗？或者换一种问法：什么情况下可以考虑使用微服务架构？
笔者认为微服务架构最大的难点就是复杂度提升了很多个量级，并不是一个开发人员或一个小型的开发团队能够解决和应对的。就像在现实世界中，人们都听过的一句话：“贵一点的东西除价格高外，其他的都好。”那么，笔者就拿这句话来做一个类比：微服务架构、服务网格等架构模式，除复杂度高外，其他的也都还好。
微服务架构是一个很优秀的架构模式，能够解决项目开发中的一些痛点，但是想要落地和用好它，需要克服很多的难点。因为它入门难、实践难、部署难、优化难、招人难，总结下来就是技术门槛高。如果技术人员的水平高且人员充足，那么上述的这些“难”就不复存在了，此时不仅微服务架构不是问题，其他的技术架构在落地和实践时也不是问题。
如果公司的业务量不大，也没有强烈的扩容需求，并且开发团队的项目组就一个，后端开发人员也就几个人，那么此时就不适合去尝试微服务架构了，针对公司系统的问题做针对性的优化即可，切不可做“大炮轰蚊子”这种傻事。
如果公司的业务量增长到一定程度，并且技术团队的人员也充足，那么此时可以考虑尝试微服务架构。如果做完技术评估觉得微服务架构非常契合当前的业务和开发人员，那么进行微服务架构的落地就再适合不过了。
什么情况下可以考虑使用微服务架构？
（1）已经对当前的系统使用了很多优化手段，微服务架构是架构模式，并不是一种具体的系统优化手段。
（2）做完技术评估后，得出的结论是微服务架构能够给技术团队和业务扩展带来正向的影响。
（3）最重要的一点是技术团队的人员齐整、技术支撑足够。
如果以上三点都能够满足，再考虑使用微服务架构，进行实际的架构升级和功能开发。不要为了微服务而使用微服务，要根据自身业务和技术团队来考量是否适合使用这种架构、是否有足够的技术支撑来解决服务化过程中出现的问题。如果不适合，那么最终结果可能就是“大炮轰蚊子”。没有足够的技术沉淀和技术人员来做支撑，反而会对系统的开发和维护造成适得其反的效果。