1.4.1　微服务能解决的问题

下面从1.3.2节中总结的单体式架构的缺点来分析。

首先，微服务解决了难以维护的问题。微服务本身微小的设计，导致一个服务的职责不会过大，从而轻松地解决了难以维护的问题，单对一个服务来讲，它的代码量不会特别多，量少的东西不一定简单，但一定是好管理的，而且后续介绍的有关微服务更科学的程序设计方法，也会大大增加代码的可维护性。

其次，过载的IDE和过载的Web容器，似乎也随着服务的微小化而轻松解决了，微服务架构中的每个服务都是独立部署的，拥有自己独立的进程，无论是IDE还是Web容器，都可以轻松地承载，而且应用程序的启动和调试效率也要高得多。

然后，对于部署，微服务架构中，服务都是自动部署的（具体的方式后续章节会有介绍），而且每个服务负责的职责都很小，只会部署有变化的服务，所以单体式架构中需要部署全部功能的风险也就没有了。

这样的方式，在应用需要做水平扩展的时候，只需增加需要的服务节点即可，再根据具体增加节点的特性，如存储、CPU、内存等增加具体的符合需求的资源，也就不会出现资源的浪费了。

最后，关于技术创新，微服务本身是独立的，而且每个微服务之间的通信是轻量级的，这就导致微服务之前几乎是没有技术依赖和限制的，服务既可以有自己独立的存储方式，也可以有不同的语言，服务所采用的技术栈也可以是完全不一样的。所以，你几乎可以使用任何你认为合适的技术，当然，做技术选型往往可能需要考虑更多的问题，但至少在项目的服务架构层面，微服务并不会对一个项目的技术选择造成什么困扰。

看上去微服务似乎真的解决了单体式架构的所有问题，那除了能解决这些问题，微服务本身又有哪些新的特点呢？