【Spring Cloud】微服务架构选型方案
1、技术架构
2、组件介绍
1、服务注册与发现——Eureka
服务注册与发现中心采用Eureka，以AP为核心的高可用注册中心，保证高可用性和最终一致性，server之间互相注册的replicate机制可以单点注册、全局感知，通过集群式部署来避免单点故障导致服务不可用。
提供云端服务发现，一个基于Rest的服务，用于定位服务，以实现云端中间层的服务发现和故障转移。
主要用来实现服务治理，统一管理众多微服务应用的地址信息，以及复杂的调用关系，减少应用之间的耦合，通过提供服务方在Eureka Server注册服务，服务消费方在Server上订阅所需服务得到提供者的地址信息，完成一次服务之间的请求调用。
由Eureka Server和Eureka Client组成，Eureka Server用作注册中心，支持集群部署；Eureka Client是一个Java客户端，用来处理服务注册与发现。
2、服务网关——Spring Cloud GateWay
Spring Cloud GateWay作为Spring Cloud生态系统中的网关，旨在为微服务架构提供一种简单有效的统一的API路由管理方式，并且基于Filter链的方式提供了网关基本的功能，如：安全、授权、监控/指标、限流等。
GateWay特征有：动态路由、基于HTTP请求的路由匹配、Predicates和Filters作用于特定路由、集成Hystrix熔断器、易于编写的Predicates和Filters、限流、路径重写、与服务注册发现组件结合根据serviceId转发。
重要的概念
- 过滤器：用于拦截和链式处理web请求，实现横切的、与应用无关的需求。可在代理请求处理之前（pre）执行，也可以在请求之后（post）执行。pre类型过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等；post类型过滤器可以做响应内容、响应头的修改、日志输出、流量监控等。过了pre和post的区分，根据作用范围还可以分为针对单个路由的gateway filter和针对所有路由的global gateway filter。
- Predicate：在将web请求和路由进行匹配时，用到的就是predicate，决定请求走哪一个路由。GateWay内置了多种类型的Predicate。
请求时，客户端向GateWay发起请求，如果在GateWay Handler Mapping中找到与请求相匹配的路由(此处用到Predicate)，将其发送到GateWay Web Handler，Handler再通过指定的过滤链来将请求发送到实际的服务执行业务逻辑，然后返回。期间，过滤器可能在发送代理请求之前（pre过滤器）或之后（post过滤器）执行。
GateWay基于Webflux，支持异步非阻塞编程。
3、服务调用——Ribbon + Hystrix + Feign
一次服务调用请求过程，提供某个服务的应用可能有多个（集群部署），消费方需要从中选择一个进行调用，即客户端负载均衡技术，Ribbon主要提供客户端的软件负载均衡算法。
Ribbon支持许多常见的负载均衡策略，同时也支持自定义负载均衡策略。
Hystrix的主要作用是熔断器，控制故障范围，是一个容错管理工具，通过熔断机制控制服务和第三方库的节点，对延迟和故障提供更强大的容错能力。
由于网络分区环境的复杂性，通常服务不能保证100%的可用性，如果某个服务出现故障，调用该服务就会出现线程阻塞，此时若有大量请求涌入，线程资源耗尽后造成服务瘫痪。而由于服务之间的调用依赖性，故障会快速在服务群中扩散，严重时导致大量微服务不可用，这就是服务故障的“雪崩 ”效应。
Hystrix可以在服务故障时拦截请求，快速返回错误信息，同时自动探测服务状态以便后续恢复服务请求，另外也支持实现服务降级机制，可以显著增加整个分布式系统的健壮性和稳定性。
Feign是一个声明式的Web服务客户端，支持可插入注释、可插拔编码解码器，以及Ribbon的负载均衡、Hystrix和它的fallback和HTTP请求和响应的压缩。
将对Rest服务请求封装成接口形式，以调用本地接口的形式调用远程Rest服务，对开发更加直观友好。
Feign通过编写简单的接口和插入注解，Feign就会根据自定义的HTTP请求的参数、格式、地址等信息，来完全代理HTTP请求，通过调用接口就可以完成服务请求。
4、业务集群——SpringBoot + SpringMVC
Spring Cloud基于SpringBoot工程构建，利用SpringBoot可以快速开发单个微服务应用。
通过SpringMVC的相关注解可以对外暴露Rest服务。
5、服务配置中心——Spring Cloud Config
随着微服务规模的增大，以及生产、测试等环境隔离的要求，由每个微服务应用单独维护各自的配置信息会非常混乱，而且每次配置信息的变更都需要应用的重启才能生效，因此需要一个分布式配置中心，提供统一的配置信息管理。
Spring Cloud中的分布式配置中心组件Spring Cloud Config，支持配置信息放在配置服务器本地，也支持存放在远程Git仓库中，集中化管理集群配置，可以分为两个角色，Config Server和Config Client。
Config Server保存配置信息在本地或远程仓库中，然后对外发布配置服务，将配置信息服务化；Config Client通过访问Config Server提供的服务接口，获取相关的配置信息来完成自身的应用初始化。
为了避免单点故障，同样可以部署成集群模式。
同样另一个问题，由配置中心统一管理，配置信息变更时，无需重启应用，就可以做到配置信息实时更新生效。
6、消息总线——Bus
Spring Cloud Bus通过轻量的消息代理连接各个分布的节点，称为事件、消息总线，用于在集群中传播状态变化，可以与Spring Cloud Config联合使用实现配置信息热部署。主要功能有两点：
- 对指定主题的消息进行订阅和发布
- 事件监听，包括刷新事件、环境变更事件、远端应用的ack事件以及本地服务端发送事件等。
其本质是利用了MQ的广播机制在分布式系统中传播消息。
- 提交代码或变更配置触发post请求给bus/refresh
- server端接受请求并发送给Bus
- Bus接到消息后通知给客户端
- 客户端收到通知后，请求server获取最新配置
- 全部客户端更新配置
7、认证、授权、安全——spring cloud security + OAuth2 + JWT
Spring Security是一个强大的、高度可定制化的身份验证和访问控制框架，两个主要目标就是 认证 和 授权，一般为先认证身份，然后进行授权。
认证协议——JWT。基本思路就是用户提供用户名和密码给认证服务器，服务器验证用户提交信息的合法性，验证成功返回一个Token，用户用这个Token访问服务器上受保护的资源。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
授权框架——OAuth2。OAuth允许用户提供一个令牌，而不是用户名和密码，每一个令牌授权一个特定的第三方应用在特定的时段内访问特定的资源。
8、链路跟踪——zipkin(spring cloud sleuth)
随着系统和微服务应用的增多，一个业务可能需要多个微服务协同完成，链路上任何一个应用的服务出现问题都会导致业务失败，需要快速跟踪故障位置。
Spring Cloud Sleuth，主要功能是在分布式系统中提供追踪解决方案，并且兼容支持zipkin、HTrace和log-base追踪。
服务追踪从客户都拿发起请求到达被追踪系统边界开始，到被追踪系统向客户返回响应结束，称为一次trace；在trace过程每次调用服务时，埋入一个调用记录（”span”），再附带上响应时间和请求成功与否等信息，这样，若干有序的span就组成了一个trace。
Sleuth为服务之间调用提供链路跟踪，可以做到理清服务间调用关系；耗时分析；可视化错误（借助zipkin）；链路优化。
结合zipkin，将数据发到zipkin，进行数据可视化，展示微服务调用请求链、错误信息可视化。可以直观地看到一次请求经过了那些微服务，以及每个服务的耗时，在请求失败时可以快速定位到请求链中哪一环出了问题。
9、监控中心——Turbine、Dashboard + Spring Boot Admin
首先介绍两个Hystrix监控工具：
- Hystrix Dashboard是一个针对Hystrix进行实时监控的工具，可以直观地看到各个Hystrix Command的请求响应时间、请求成功率等。
- Dashboard只能看到单个应用内的服务信息，Hystrix Turbine可以聚合监控系统内多个服务的数据。由于分布式系统中服务通常集群部署，Turbine可以把多个相同服务的节点状态聚合为一个数据源，以一个整体集群的形式供Dashboard展示。
Actuator时Spring Boot提供的对应用系统的自省和监控的集成功能，可以查看应用配置的详细信息等，为了保证Actuator暴露的监控接口的安全性，需要添加安全管理的Security依赖。
Actuator监控分为原生端点和用户自定义端点两类，可以观察应用运行期间的各种性能指标和内部状况。
Spring Boot Admin：
由于使用Actuator监控，需要对每个应用单独调用固定的接口来进行监控，而且返回数据均为json数据。
Spring Boot Admin是一个开源社区项目，用于管理和监控SpringBoot应用程序。应用程序作为Spring Boot Admin Client向为Spring Boot Admin Server注册（通过HTTP）或使用SpringCloud注册中心（例如Eureka，Consul，Zookeeper）发现。 在前端界面展示Admin Client的Actuator端点上的一些监控信息。
提供了安全登录界面的组件，并且和Spring Boot Security相结合，提供安全登录功能。
Spring Boot Admin Server中还可以集成Turbine组件，让Turbine中展示的内容整合到Admin Server中，和应用实例一起监控，方便查看和管理。
10、消息队列——Kfaka
11、分布式日志系统——ELK
ElK，即ElasticSearch+Logstash+Kibana。
- ElasticSearch是一个基于Lucene的开源分布式搜索服务器。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
- Logstash是一个完全开源的工具，它可以对日志进行收集、过滤、分析，支持大量的数据获取方法，并将其存储供以后使用（如搜索）。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作再一并发往elasticsearch上去。
- Kibana是一个基于浏览器页面的Elasticsearch前端展示工具，可以为 Logstash 和 ElasticSearch 提供日志分析友好的 Web 界面。
- 每台服务器集群节点安装Logstash日志收集系统插件，将日志输入到Logstash中
- Logstash将该日志格式化为json格式，根据每天创建不同的索引，输出到ElasticSearch中
- 另外，zipkin的流也可以直接传给ElasticSearch，便于运维管理和分析
- 浏览器使用安装Kibana查询日志信息
12、分布式事务
由于在微服务架构中，不同的业务集群维护各自独立的数据库，互相之间数据不互通，调用也只是接口的调用，再加上网络环境的不稳定性，分布式事务的一致性就显得非常重要。
常见的分布式事务解决方案有：
- 两阶段提交
- 补偿事务机制
- 本地消息表
- MQ事务消息
13、分布式缓存——Redis
Redis可以用来做分布式系统Session共享，同时，Redis做二级缓存对降低整个服务响应时间、减少数据库访问次数也有帮助，可选Redis Cluster（集群模式）和Redis Sentinel（哨兵模式）。