微服务：

系统架构的演变

单一应用架构

早期的互联网应用架构，大量应用服务 功能 集中在一个包里，把大量的应用打包为一个jar包，部署在一台服务器，例如tomcat上部署Javaweb项目

缺点:耦合度高，一台服务器宕机，所有功能停止工作。维护成本高，无法做拓展。

垂直应用架构

把一个单一应用 拆分成几个毫不相干的应用，可以分担流量，减缓压力。比如把一个电商系统拆分成前台系统 管理系统 用户系统，这其中可能会有 重复的地方。

的优点在于：

系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平扩展。 一个系统的问题不会影响到其他系统，提高容错率。 缺点：

系统之间相互独立， 无法进行相互调用。 系统之间相互独立， 会有重复的开发任务

分布式架构

在垂直应用架构的基础上 比如把一个电商系统拆分成前台系统 管理系统 用户系统 提取公共业务代码为服务层，通过前端表现层去调用服务。但是这几个系统相互独立 调用起来相当复杂 并且导致 比如上面提到的前台系统 管理系统 用户系统相互粘连 耦合度变高

优点：

抽取公共的功能为服务层，提高代码复用性。 缺点：

系统间耦合度变高，调用关系错综复杂，难以维护。

SOA架构

提供一个面向服务的调度中心 统一对服务进行调度

优点：

使用注册中心解决了服务间相互调用的问题 缺点：

仔细一看 图中 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )。服务关心复杂，运维、测试部署困难

微服务架构

基于服务彻底拆分应用 使得每个微小的服务独立运转，即使一个服务宕机也不会影响其他服务的使用！但是这样随之而来的是高成本，每个服务都是独立的，并且可以拓展功能，但是这样运维的压力会很大。

这样也就带来了微服务要处理的一些问题：

资源的分配与调度，服务的治理，服务网关的配置，服务的发现与注册，服务的追踪与容错。