微服务基本简述

1.单体架构及其不足

典型的单体应用是将所有业务的表示(视图)层、业务逻辑层和数据访问层放在一个工程中，经过编译、打包部署在服务器上。

(1) 单体架构不足

① 单体应用的业务逻辑和代码量越来越多，代码的可读性、可维护性和可扩展性下降
② 随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限
③ 单体应用修改或增加业务可能给其他业务带来影响，导致测试难度增加

(2) 单体架构集群不足

单体应用进行集群部署，通过增加负载均衡服务器(如Nginx)、缓存服务器、文件服务器以及数据库读写分离，应对用户的增加而带来的高并发访问量。

① 大量业务逻辑必有大量代码，代码的可读性和可维护性较差
② 海量用户数据库将会成为瓶颈，需要使用分布式数据库

2.微服务

(1) 服务的划分

微服务拆分原则：服务是可以被替换和更新的 (服务和服务之间无耦合，任何一个服务都可以被替换)

(2) 服务的部署

Docker容器技术是微服务最佳部署容器

(3) 服务注册与发现

服务注册：向服务注册中心注册实例，服务提供者将自己的服务信息（如服务名、IP地址等）告知服务注册中心。
服务发现：服务消费者需要消费服务时，服务注册中心能告知服务消费者所要消费服务的实例信息（如服务名、IP地址等）。

为了保证服务的高可用，服务单元可以进行集群化部署

(4) 服务的容错

雪崩效应：在实际项目中，服务的数量多和依赖性复杂，一个网络请求通常调用多个服务才能完成；当某个服务不可用（网络延迟或故障），这个请求就会阻塞，会影响到依赖于其的其他服务，进而导致整个系统处于瘫痪状态。
熔断机制：当某个服务处理用户请求的失败次数在一定时间内小于设定的阈值时，熔断器处于关闭状态，服务正常；当服务处理用户请求的失败次数大于设定的阈值时，服务出现故障，打开熔断器，所有请求执行快速失败（不执行业务逻辑）；当熔断器打开状态时，一段时间后自动为半打开状态并执行部分请求，剩余请求会执行快速失败，若执行的请求失败，则继续打开熔断器；若成功，则将熔断器关闭。

3. Spring Cloud

(1) 服务注册和发现组件 Eureka

利用 Eureka组件可以很轻松地实现服务的注册和发现的功能。 Eureka组件提供了服务的健康监测，以及界面友好的UI。通过 Eureka组件提供的UI，Eureka组件可以让开发人员随时了解服务单元的运行情况。另外 Spring Cloud也支持 Consul和Zookeeper，用于注册和发现服务。

(2) 熔断组件 Hystrix

Hystrix是一个熔断组件，它除了有一些基本的熔断器功能外，还能够实现服务降级、服务限流的功能。另外 Hystrix提供了熔断器的健康监测，以及熔断器健康数据的API接口。Hystrix Dashboard组件提供了单个服务熔断器的健康状态数据的界面展示功能， Hystrix Turbine组件提供了多个服务的熔断器的健康状态数据的界面展示功能。

(3) 负载均衡组件 Ribbon

Ribbon是一个负载均衡组件，它通常和 Eureka、Zuul、 RestTemplate、 Feign配合使用。Ribbon和Zuul配合，很容易做到负载均衡，将请求根据负载均衡策略分配到不同的服务实例中。 Ribbon和 Rest Template、 Feign配合，在消费服务时能够做到负载均衡。

(4) 路由网关Zuul

路由网关Zuul有智能路由和过滤的功能。内部服务的API接口通过Zuul网关统一对外暴露，内部服务的API接口不直接暴露，防止了内部服务敏感信息对外暴露。在默认的情况下，Zuul和Ribbon相结合，能够做到负载均衡、智能路由。Zuul的过滤功能是通过拦截请求来实现的，可以对一些用户的角色和权限进行判断，起到安全验证的作用，同时也可以用于输出实时的请求日志

(5) Spring Cloud Config

Spring Cloud Config组件提供了配置文件统一管理的功能。 Spring Cloud Config包括 Server端和 Client端，Server端读取本地仓库或者远程仓库的配置文件，所有的 Client向 Server读取配置信息，从而达到配置文件统一管理的目的。通常情况下 Spring Cloud Config和 Spring Cloud Bus相互配合刷新指定 Client或所有 Client的配置文件