1.3 微服务架构
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，各个服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在独立的进程中，服务与服务之间采用轻量级的通信机制互相协作，通常是基于HTTP协议的RESTful API。每个服务都围绕具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。这就是Martin Fowler在Microservices中给出的微服务架构的定义。
以笔者参与的订单系统项目为例，微服务架构如图1-3所示。
图1-3 微服务架构
微服务架构和单体架构具有非常明显的区别。例如，微服务架构的审单、开户、发货、数据库服务、日志服务和公共服务等不再是功能模块，而是能够单独运行的微服务程序。每个微服务程序可以运行多个实例，具备简单、快捷的横向扩容能力。另外，前后端代码完全物理分离，前端代码包括的静态资源直接部署在Nginx上即可。
提示：前后端分离分为逻辑分离和物理分离：逻辑分离一般是指前后端代码从业务逻辑和功能划分上做到了代码结构上的分离，但是程序打包发布时通常还是一起发布运行的；而物理分离不但前后端代码结构做到了分离，而且前后端代码可以分别独立打包和独立部署，这时的前端代码往往只包含HTML、CSS、JS、PNG、JPEG等静态代码文件和资源文件，可以部署在Nginx或Apache服务器上，并且可以使用公有云厂商提供的CDN对静态资源进行加速。
下面简要介绍微服务架构的特点、优点和缺点。
1.3.1 微服务架构的特点
（1）系统服务层拆分抽取为一个一个的微服务。
（2）微服务遵循单一功能原则。
（3）微服务之间采用RESTful等轻量协议进行通信。
1.3.2 微服务架构的优点
（1）开发简单：开发人员只需要关注自己负责的微服务工程，业务和技术双重聚焦。
（2）开发快捷：服务拆分粒度更细，有利于资源重复利用，提高开发效率，产品迭代周期更短。
（3）技术栈灵活：可以使用Java、Python、Go等多种语言开发微服务应用。
（4）服务独立无依赖：基于HTTP协议的微服务，各个服务之间没有依赖关系，降低了系统复杂度。
（5）独立按需扩展：根据微服务调用频次进行扩容和缩容，调用频次高的微服务扩容。
（6）可用性高：多节点部署，大大提高了系统的可用性。
1.3.3 微服务架构的缺点
（1）多服务运维难度大幅度提升。
（2）系统部署依赖度提高，服务治理成本增加。
（3）服务间通信成本增加。
（4）数据一致性挑战难度增加。
（5）技术成本高，团队挑战难度增加。
可以用4个词概括微服务架构的特点：微小、独立、轻量、松耦合。