什么是微服务架构,该从哪些方面深入理解?到底能解决哪些问题呢？

微服务架构概述

微服务在设计之初就是致力于解决单体式架构的问题而出发的，所以它几乎可以解决单体式架构面临的所有问题。虽然微服务本身也有一些缺陷，但丝毫不影响它替代单体式架构成为主流架构的步伐。那么，微服务架构到底能解决哪些问题呢？

微服务能解决的问题

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

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

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

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

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

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

微服务架构的特点

微服务定义大致反映出微服务架构的一些特点：微服务是小的服务；微服务是独立运行的；微服务的交互是轻量级的，是可以跨语言的；服务的设计是围绕业务的；微服务是可以自动部署的，有集中式的服务管理等。

但随着微服务的发展，它的定义是多变的，每个人在使用微服务架构时的做法都不完全一样，其中有很多很好的实践，有复杂的，也有简单的，似乎很难去界定谁对谁错，毕竟由于软件项目的独特性，每种实践都是在特定的需求和场景下产生的，因此不妨把目光放在它们的共同点上。此前有过无数人的大胆尝试和实践，我们可以通过分析来看看大多数人都在怎样做着微服务。

ThoughtWorks的Martin Fowler是业界的权威专家，他认为虽然很难给微服务的架构一个正确的定义，但可以尝试描述我们认为有合适标签的架构的共同特征。并非所有的微服务架构都具有所有的特征，但是Martin Fowler希望大多数微服务能具有大部分特征。最后，他总结了微服务的九大特征，成为当下这个松散的社区关于微服务的一个宽松的标准。

下面就来看看微服务的九大特征，如图1.8所示。