最近团队一直在讨论是否将现有的产品架构向微服务架构靠拢。提到微服务架构，我们先说说目前所使用的架构。
目前我们所使用的架构虽然不是传统的单体应用架构，也就是所谓的一刀切，所有的功能全部堆积在一起，在项目选型阶段，我们便摒弃这一架构。因为它存在很严重的问题，严重到有可能会因为一个小的误操作导致整个系统瘫痪。但我们也不能忽视它在团队初期快速开发和部署发布的优势。
我们将整个系统进行了粗粒度的划分，将整个系统根据业务划分成若干个子模块，虽然前期我们在业务编码时体会到了拆分后的优势，能够快速准确的找到问题所在，不会因为某个模块出现问题导致其他模块不能正常使用。但随着业务模块不断增加，用户越来越多，由于前期的粗粒度拆分，导致耦合性越来越严重，运维工程师也面临着巨大的挑战。
随着一系列问题的出现，团队也开始考虑向微服务架构靠拢。到底什么是微服务架构呢？
微服务是一种架构风格，即将单体应用划分为小型的服务单元。
微服务优势：
1、快速迭代，部署，上线；
2、可独立部署；
3、职责专一；
4、可按需进行动态扩容；
5、代码复用性强。
当然它也不是十全十美的，也有自己的缺点。
1、由于分布式部署，会遇到网络、容错等众多问题；
2、去中心化的数据管理，使的事物问题尤为突出；
3、测试运维难度提升。
我们到底要不要使用微服务架构呢？还需要团队认真考虑这个问题！
网友评论