简介：微服务架构（Microservice Architecture）是一种架构的概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。微服务架构是区别于传统的单体软件架构，为了适应当前的环境“高并发、高性能、高可用”而产生的软件架构。

单体式应用程序

先讲一下什么是单体式应用程序。

单体式应用程序内部是包含了所有需要的服务，也就是所有的功能和服务全部在一个程序里面。每一个服务模块之间的耦合性很强，很难拆分和扩容。

例如一个最简单的单体式程序：hello world，它就是一个程序包含所有功能。

单体式应用程序的优点就是开发简洁、部署容易、测试容易。

但是一旦当业务开始迭代，系统变得庞大之后，维护和迭代就会变得异常的艰难。

因此，就有了微服务的概念。

微服务

2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。「维基百科」

对于微服务架构而言，单个应用程序被划分为各种小的、互相连接的微服务，一个微服务完成一个比较单一的功能，相互之间保持独立和解耦合。

微服务架构的几个主要优点：

技术异构型

每一个不同的服务内部的开发技术可以不一致，这样可以让不同的服务选择最适合该服务的技术。

同时，系统中不同的部分也可以使用不同的存储技术。比如这一个部分使用 redis，那一个部分可以使用 MySQL。

隔离性

每一个服务都是相互独立和自治的系统。就好比电路的并联，某一个服务瘫痪并不影响其他服务的正常运行。

可拓展性

我们可以只针对需要进行升级的某一个服务进行升级，对症下药。

简化部署

如果你的服务是一个超大的单体服务，有几百万行代码，即使修改了几行代码也要重新编译整个应用，这显然是非常繁琐的，而且软件变更带来的不确定性非常高，软件部署的影响也非常大。在微服务架构中，各个服务的部署是独立的，如果真出了问题也只是影响单个服务，可以快速回滚版本解决。

易优化

单个服务的代码量不会很大，这就意味着对单个服务的优化要简单的多。

参考文章