技术预研第一天

最近团队一直在讨论是否将现有的产品架构向微服务架构靠拢。提到微服务架构，我们先说说目前所使用的架构。

目前我们所使用的架构虽然不是传统的单体应用架构，也就是所谓的一刀切，所有的功能全部堆积在一起，在项目选型阶段，我们便摒弃这一架构。因为它存在很严重的问题，严重到有可能会因为一个小的误操作导致整个系统瘫痪。但我们也不能忽视它在团队初期快速开发和部署发布的优势。

我们将整个系统进行了粗粒度的划分，将整个系统根据业务划分成若干个子模块，虽然前期我们在业务编码时体会到了拆分后的优势，能够快速准确的找到问题所在，不会因为某个模块出现问题导致其他模块不能正常使用。但随着业务模块不断增加，用户越来越多，由于前期的粗粒度拆分，导致耦合性越来越严重，运维工程师也面临着巨大的挑战。

随着一系列问题的出现，团队也开始考虑向微服务架构靠拢。到底什么是微服务架构呢？

微服务是一种架构风格，即将单体应用划分为小型的服务单元。

微服务优势：

1、快速迭代，部署，上线；

2、可独立部署；

3、职责专一；

4、可按需进行动态扩容；

5、代码复用性强。

当然它也不是十全十美的，也有自己的缺点。

1、由于分布式部署，会遇到网络、容错等众多问题；

2、去中心化的数据管理，使的事物问题尤为突出；

3、测试运维难度提升。

我们到底要不要使用微服务架构呢？还需要团队认真考虑这个问题！