业务发展初期，业务流量很小，对业务迭代效率的要求很高，使用单体服务开发灵活，部署简单。随着业务的快速发展，业务复杂度越来越高，同时业务开发人员也急剧增加，单体服务逐渐暴露出来一些问题，主要问题如下：
一、传统单体问题
- 开发效率低
业务逻辑都集中在单个服务中，所有的开发者都在一个项目里面进行修改，代码并入时经常会出现相互等待和代码并入冲突的现象，严重影响开发效率。另外，多人同时操作一份代码，出错的概率也会增加。
- 可维护性差
业务逻辑都集中在一个服务里面，单个开发者不太可能完全掌控整个业务，因此业务修改和问题追查定位都非常困难。由于很少有人能够对业务非常熟悉，增加新功能或者修改原有功能时更多像是在打补丁，导致代码质量和可维护性越来越差，各种功能耦合在一起，新人接手的时候都不知道从何下手。
- 架构扩展性差
不同模块可能有不同的架构要求，单体服务很难照顾到大家的差异化需求，如果想针对某个模块进行新架构和新语言的调整与支持，也比较困难。
- 部署不灵活
任何一处很小的改动，都需要对整个服务进行编译、部署和上线，这可能会影响整个系统的稳定性，同时很难对某个特定的模块进行单独的容量规划和部署设计。
- 健壮性差
单体服务的所有模块都在一起，某个模块出现严重问题，会导致整个业务不可用。当业务代码规模很庞大时，系统的故障点会很多，严重影响业务的健壮性和可用性。
二、什么是微服务
微服务就是为了解决单体服务的上述问题而生的，微服务架构是将单个服务拆分成一系列小服务，这些小服务都拥有独立的进程，通过HTTP RESTful API之类的轻量级通信方式进行通信，而作为独立的业务服务，则可采用一些自动化部署机制独立部署，每个服务可以使用不同的开发语言和数据存储技术，实现去中心化的服务管理。
微服务架构的核心诉求是支撑业务敏捷开发和部署，因此微服务架构的本质是如何优雅地支持微服务的“拆分”和“组合”，如何进行合理的架构拆分，如何最大限度地减少微服务之间沟通的成本，这是微服务架构的关键所在。
微服务不只是个技术问题，更多的是关于组织和团队的问题，系统架构和组织之间存在映射关系，如果组织结构不支持，则无法建立高效的系统架构，反之也是这样。
三、微服务的收益
互联网业务的两个显著特点是业务发展快和业务高并发，微服务在这两个方面均有很大的收益，通过有效支撑业务创新和高并发架构，微服务架构成为传统架构演进时的必然选择。
通过将单个服务拆分成多个微服务，多个微服务可以独立开发、独立测试、独立运维，不同团队可以并行开发，互不影响，可以有力地支撑业务的快速迭代，方便业务创新和试错。
互联网业务通过业务模式创新和运营模式创新，用户和流量变化很快，需要从架构层面支撑业务流量的伸缩变化。微服务架构将单个服务拆分为多个子服务，每个微服务均可以独立进行容量评估，非常灵活，可以很好地支撑业务的高并发需求。
