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:用于记录一个事件
    Spring Cloud学习总结_第1张图片

你可能感兴趣的:(Spring,Java)