Spring Cloud学习总结

第一部分 微服务简介

1. “微服务”是2014年Martin Fowler提出来的。
2. 微服务间一般采用HTTP进行通信，也可以用轻量级的消息总线RabbitMQ、Kafaka进行通信。通信协议Json（轻量、可读性好）、XML（重量、可读性一般）、Protobuf（超轻量、无可读性）。
3. 微服务按业务划分服务，每个服务的数据库是独立的。
4. 微服务都是自动化部署的。Docker容器技术、Jenkins自动化部署。
5. 服务集中化管理。Spring Cloud使用Eureka管理的，还可以用Zookeeper、Consul来管理。
6. 分布式架构有可能会有数据一致性问题，并且网络有可能会成为瓶颈。
7. 微服务引入熔断机制：当某服务s出现故障，失败请求次数超过了阈值之后，服务b开启熔断器，不进行业务逻辑处理，转而快速失败，返回失败信息。这样可以阻止故障的传播。熔断器往往有自我修复机制，即熔断一段时间后，尝试半打开熔断器。
8. 微服务在 CAP 理论中采用的是 AP 架构，即具有高可用和分区容错的特点。 分布式服务首先要满足P，而单体服务保证的是CA。所以为了在AP系统中尽量保持数据一致性，会有分布式事务的概念。其中，分区容错性指部分网络不可用时，仍然可以对外提供服务。
9. 业界中常用解决分布式事务的方法是：两阶段提交。Redis支持事务，MongoDB是不支持事务的。
10. 事务分析举例：
    单体应用的事务举例，比如卖商品：

@Transactional
public void update () throws RuntTimeException {
	updateAccountTable (); //更新账户表 
	updateGoodsTable (); //更新商品表
}

如果是微服务架构，商品一个服务，用户一个服务，分别是两个数据库，不能用数据库的自带事务了。
本地数据库事务需要满足ACID，是通过数据库锁和日志来完成的。具体：原子性和一致性是通过Undo日志来实现的，隔离性是通过数据库锁来实现的，持续性是通过Redo日志来实现的。
BASE：是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写，是对 CAP 中 AP 的一个扩展。
两阶段提交（2PC）：XA Transaction、TCC
XA可能的问题：事务协调器单点挂掉、第一阶段同步阻塞、第二阶段仍然可能数据不一致。
总结：尽量少用分布式事务。
TCC：Try、Confirm、Cancel（每个阶段要满足幂等性）
幂等性总结：https://blog.csdn.net/weixin_38336658/article/details/80445743
三阶段提交（3PC）
不管那种，都存在事务失败，数据不一致问题，关键时刻人工恢复。
Spring Cloud可以集成LCN进行分布式事务控制
11. 微服务相对于SOA来说更加轻便敏捷
12. 微服务架构的三个难题：服务的故障传播性、服务的划分、分布式事务
13. 流行的微服务框架：Spring社区的Spring Cloud、Google社区的Kubernets、阿里的Dubbo

第二部分 Spring Cloud

1. 单个微服务8~10人算“微”。
2. 微服务特点：按业务划分；每个服务有自己独立的基础组件（数据库、缓存等）；服务间HTTP通信；有服务治理解决方案，能随时添加删除服务；单个微服务能够集群化部署，有负载均衡能力；整个微服务有安全机制：包括用户验证、权限验证、资源保护等；整个微服务系统有链路追踪能力；有完整的实时日志系统。
3. 微服务的功能主要有：服务的注册发现；服务的负载均衡；服务的容错；服务网关；服务配置的统一管理；链路追踪；实时日志；
4. 服务的注册与发现：向服务注册中心注册一个服务实例，提供服务名、IP等。一般一个服务既是服务提供者也是服务消费者。通常一个服务实例注册后，会提供心跳；如果停止心跳一段时间，服务实例会被剔除。如Eureka；
5. 服务的负载均衡：服务的消费者，一般集成负载均衡组件，获取服务提供者列表，通过负载均衡策略进行选择。服务注册中心一般会进行集群化，它们之间会实时同步信息。Ribbon
6. 服务的容错：为了解决分布式系统的雪崩问题，引入熔断机制。它能够提供资源隔离、服务降级、自我修复等能力。如Hystrix
7. 服务网关：微服务系统的资源以API接口的形式提供服务。API接口资源通常有服务网关统一暴露。此外，网关还可以做一些身份权限认证；记录日志，对请求进行记录；流量监控，高流量下进行降级；常用的网关组件有Zuul、Nginx等；
8. 服务配置的统一管理：每个服务都有大量的配置文件，例如数据库的配置、日志输出级别等；随着服务数量的增加，配置管理将非常复杂。如Spring Cloud Config；配置中心可以考虑集群化；
9. 服务链路追踪。如Google的Dapper。
10. Spring Cloud的常用组件：Eureka（也支持Zookeeper、Consul）、Hystrix（除了提供熔断功能，还支持服务降级和限流）、Ribbon、Zuul（暴露API、拦截）、Spring Cloud Config、Spring Cloud Security（用户权限验证，配合Spring Security Oauth2）、Spring Cloud Sleuth（分布式链路追踪）、Spring Cloud Stream（数据流操作包，可以封装MQ、Kafka、Redis等消息组件）、Feign（声明式调度组件）、Spring Cloud Bus
11. Dubbo 阿里的分布式服务框架：RPC远程调用（封装了长连接NIO框架，如Netty，采用多线程模式）、集群容错（提供远程接口调用，实现了负载均衡、失败容错）、服务发现Zookeeper。
12. Kubernets。可以通过对运行的容器的编排来实现构建微服务。它不局限与Java平台，也不限语言。更像一个平台，面向Devops人员。

第三部分 Spring Cloud组件

• Spring Boot的三大特点：自动部署、起步依赖、Actuator对运营状态的监控
• Eureka
  Eureka分为Eureka Server和Eureka Client
  Eureka包含3种角色：Register Service（服务注册中心，是Eureka Server）、Provider Service（服务提供者，是Eureka Client）、Consumer Service（服务消费者，是Eureka Client）。
  Eureka的一些概念：Register、Renew（Client每隔30s会发送心跳，Server 90s没有接到心跳就会剔除该Client）、Fetch Registries、Cancel、Eviction
• RestTemplate
• Ribbon
  常见的负载均衡有两种方式。一种是独立的进程单元，通过负载均衡策略，将请求发到不同的执行单元上，例如Nginx。另一种是负载均衡逻辑已代码的方式封装在服务消费者的客户端上。Ribbon属于第二种方法。
  Ribbon作为服务消费者的负载均衡器有两种使用方法：一种是和RestTemplate结合，另外一种是和Feign结合。
  Ribbon和RestTemplate结合时，可以使用@LoadBalanced的RestTemplate实例在进行负载均衡访问。访问某服务，需要服务名，LoadBalancerClient会从Eureka Server拉取服务注册列表信息或者自己维护列表。
• Feign（默认集成了Ribbon）声明式调用。
  Feign是一个伪Java Http客户端，不做任何的请求处理。Feign通过注解生成Request模板，从而简化了Http API的开发。
  SpringCloud服务间的调用有两种方式：RestTemplate和FeignClient。不管是什么方式，他都是通过REST接口调用服务的http接口，参数和结果默认都是通过jackson序列化和反序列化。
• Hystrix
  RestTemplate和Ribbon作为服务消费者使用Hystrix熔断器，通过添加注解@EnableHystrix，@HystrixCommand来实现。
  Feign作为服务消费者，在起步依赖的时候已经引入了Hystrix依赖，只需要在配置中开启即可。
  可以使用Hystrix Dashboard监控熔断器的状况：
  Hystrix Dashboard起步依赖需要与actuator起步依赖、Hystrix起步依赖一起使用。通过添加注解@EnableHystrixDashboard，就可以在“…/hystrix.strearn"中查看了。
  在Feign中使用Hystrix Dashboard同样需要Hystrix Dashboard起步依赖需要与actuator起步依赖、Hystrix起步依赖。因为Feign中的Hystrix依赖不是起步依赖。
  使用Turbine聚合多个Hystrix Dashboard：单独的一个服务，在配置中增加其他Hystrix Dashboard服务的名称即可。
• Spring Cloud Zuul路由网关
  Zuul作为网关组件，用于构建边界服务，致力于动态路由、过滤、监控、弹性伸缩和安全等。
  Zuul是通过Servlet来实现的，通过自定义的ZuulServlet来对请求进行控制。Zuul的核心是一系列控制器，在Http请求的发起和响应期间执行一系列的过滤器。Zuul包括4种过滤器：PRE（验证、操作或判断）、ROUTING（分发、返回数据）、POST（收集信息、指标）、ERROR（发生错误时执行）。
  Zuul在路由的时候，已经做了负载均衡处理。如果禁用了Eureka（不通过Eureka来获取服务注册列表），也可以通过hiapi-vl.ribbon.listOfServers配置，自己维护注册服务列表。
  通过zuul.prefix可以配置API的版本号前缀。
  Zuul上面也可以配置熔断器。
  Zuul的横向扩展能力很好，负载过高时，可以添加实例来解决问题。
  一种常见的使用方式是不同的渠道用不同的Zuul来路由。另一种使用方式是Nginx双机热备KeepAlive，下面接Zuul集群。
• Spring Cloud Config
  Config Server从本地读取配置文件
  Config Server从远程Git仓库读取配置文件
  搭建高可用Config Server集群。
  使用Spring Cloud Bus刷新配置。
  bootstrap.yml 相对于 application.yml 具有优先的执行顺序。各个服务配置bootstrap.yml即可。
  Spring Cloud Bus可以选RabbitMQ、AMQP、Kafka等作为消息组件。当远程Git仓库的配置更改后，只需要向一个微服务实例发送Post请求，通过消息组件通知其他微服务实例重新拉取配置文件即可。
• Spring Cloud Sleuth服务链路追踪，其中集成了Zipkin
  常用的链路追踪组件有Google的Dapper、Twitter的Zipkin
  1）Span：基本工作单元，调用每个微服务单元都会产生新的span
  2）Trace：一些列Span组成了Trace
  3）Annotation：用于记录一个事件