2.1.4 微服务架构
分布式架构实现了应用从单进程到多进程的转变，做了粗粒度的服务拆分，微服务架构是在分布式架构的基础上对应用架构进行更细粒度的拆分。在微服务架构出现以前，SOA也曾风靡一时，本书将SOA和微服务合并到一起来讨论。还是以电商为例，用户服务可能会拆分成用户中心、权限、登录等服务，如图2-2所示。
图2-2 微服务架构图
随着Spring Cloud的普及，微服务架构逐步成为大中型企业的主流架构。我们来看下微服务架构有哪些优点。
·耦合性进一步降低：模块更独立，功能拆分更加细化，使代码间的耦合以及数据库、中间件的耦合进一步降低。
·自治性更强：一个微服务就是一个独立的实体，它可以独立部署、升级，微服务与微服务之间通过REST等标准接口进行通信，微服务只与其上下游有关，各个微服务之间更加独立。
·技术独立：各个微服务之间可以用不同的技术栈，服务端应用可以用Java、Go、Python等多种语言实现，数据库可以是MySQL、MongoDB、HBase等不同的类型。
·高可用：随着微服务增多、链路增长，异常也会被分散，一个微服务异常可以通过线程池隔离，利用熔断等技术避免故障扩散和雪崩，大大增加了整个系统的高可用性。
·在微服务架构成为主流架构的同时，很多缺点也被暴露出来。
·复杂度高：微服务采用RPC或REST等方式进行交互，需要考虑网络抖动、消息丢失、幂等、分布式事务等问题，代码的逻辑处理更加复杂。
·粒度难定义：微服务拆成几个合适？什么样的功能模块需要独立成一个微服务？服务拆分的粒度是不好准确定义的，倘若拆得过粗，不利于服务间解耦；如果拆得过细，则会导致应用爆炸，增加系统的复杂性。
·运维复杂度高：微服务的调用关系最终会形成一个大网，故障的定位和排查依托于更加完善的监控报警系统等配套工具。
·性能变慢：微服务一般有一个很长的调用链路，链路过长导致整体接口的性能变慢，响应时间（Response Time，RT）会变长。