《spring cloud微服务实战》读书笔记
一、基础知识
1.使用微服务比单应用模式,需要增加的挑战:
1)运维的变复杂,需要自动化工具来支持
2)接口的管理,服务接口化、接口服务化,接口的管理和维护工作很重要
3)分布式带来的复杂性:网络延迟、分布式事务、异步消息等
2.微服务架构的九大特性:
1)服务组件化:解耦、可替换
2)按业务组织团队:每个APP都要独立的人(全栈)或团队,来开发和维护。这样业务的变动,才不会波及整个组织
3)做“产品”的态度:持续关注服务运作情况,并不断分析以帮助用户来改善业务功能
4)智能端点和哑管道:更粗粒度的通信协议,通常用http或者轻量级消息总线
5)去中心化治理:每个服务(APP)技术异构,可以针对业务场景选择适合的技术
6)去中心化管理数据:每个APP使用自己的数据库实例。这也导致了数据库一致性的问题,需要通过补偿机制达成最终结果一致
7)基础设施自动化:自动化测试、自动化部署
8)容错设计:监控和日志组件,保证xi系统稳定性
9)演进式设计:初期使用单应用APP,后面随着业务发展,拆出去多个APP,核心app保持不变
3.spring cloud就像电脑中的品牌机,虽然性能可能没有自己定制的“兼容机”好,但是好处是快速上手,稳定,便宜
4.SC(spring cloud)的版本号,是按ABC开头的单词命名的,后面跟各个版本的发布版本号。注意SC里面每个子项目的版本,要和SC的版本对应
二、 微服务构建:spring boot
1.starterPOMs:spring boot提供的一些列轻便依赖包,采用spring-boot-starter-*。开发者不需要再去关注复杂的依赖配置
2.在使用命令行方式启动Spring Boot时,连续两个减号--就是对application.properties中的属性值进行赋值的标识
3.spring boot有一套自己的配置加载顺序。可以很方便的在不同环境下使用多套配置
4.actuator的原生端点主要有三大类:
1)应用配置:帮助我们获取系统繁杂的配置内容,包括自动化配置报告(/conditions)、创建的所有bean(/beans)、系统配置属性(/configprops)、系统环境属性(/env)、控制器映射关系(/mappings,有点像swagger)、自定义信息(/info)
2)度量指标:帮助我们获取系统运行时的一些状态报告,包括各类度量指标(/metrics,也可以自定义指标参数)、健康指标信息(/health,可重写接口)、线程信息(/dump)、http跟踪信息(/trace)
3)操作控制:远程关闭应用(/shutdown,可重写接口)
三、服务治理spring cloud eureka
0.注册中心、服务提供者、服务消费者
1.eureka服务端,提供了完备的restful API来支持非java语言构建的微服务纳入体系
2.eureka服务端支持集群和故障恢复功能,不同区域的服务端是通过异步模式互相复制状态的,所以在同一时间点,不同服务注册中心状态会有细微差别
3.eureka客户端,主要负责服务注册与发现,周期性的发送心跳来更新服务租约,同时也把注册中心的服务信息缓存在本地
4.可以通过简单的配置,使单节点服务注册中心,变成集群,从单节点模式变成实现高可用模式
5.服务续约(Renew):服务提供者会维护一个心跳来告诉Eureka Server状态可用。服务续约的过期时间和发送间隔可以通过参数配置
6.注册的服务,进行正常的关闭操作时,会发送“下线”通知给注册中心
7.服务注册中的“自我保护”机制,在dev环境下,最好关闭,可以便于调试(实时发现服务)。但是生产环境最好开启,因为生产环境网络可能不稳定,所以要给注册的服务容错机制
8.eureka的几乎所有配置,都可以在配置文件里重新定义,包括ip,实例名,端口号,注册地址等
9.服务提供模块,可以通过修改配置,使与服务注册中心的“心跳”实现方式,通过模块的/health端点来实现。然后再根据自身的实际业务逻辑,自定义/health端点的状态判断
四、客户端负载均衡:spring cloud ribbon
1.通过ribbon实现负载均衡,只需要1.让服务提供者讲多个服务实例注册到注册中心;2.服务消费者直接调用被@LoadBalanced注解修饰过的RestTemplate来实现面向服务接口调用
2.ribbon默认实现默认实现了区域亲和策略,实现了跨区域的容错机制实现。
3.eureka实现服务治理机制,强调了CAP原理中的AP,即可用性与可靠性(弱化一致性)
4.eureka在连接失败的时候,有重试机制。减少了由于系统缺乏一致性,所带来的服务故障的问题。
五、服务容错保护:spring cloud hystrix
1.断路器,类似保险丝的功能,在微服务框架中,通过断路器的故障监控,像调用方返回一个错误响应,避免长时间等待。
2.Hystrix具有:服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能:
1)断路器:有一个“半开”状态,会定时请求当前状态,如果正常,会关闭断路器开关。
2)依赖隔离:仓壁模式
3)使用详解:同步/异步创建请求命令
4)服务降级:getFallback()方法,可以用来处理错误、超时、线程池拒接、断路器熔断等情况
5)异常处理:Hystrix可以忽略指定异常
6)命令名称:通过设定Hystrix命令名称,可以给命令分组,同时划分线程池。
7)请求缓存:可以通过注解,对提供的服务提供缓存
8)请求合并:可以通过注解设定合并接口,在高并发情况下,对服务请求进行合并。注意,请求合并本身也有开销,所以不是适用所有场景。
9)Hystrix有许多有用的属性注解,包括:Command属性、collapser属性、threadPool属性
10)Hystrix仪表盘:通过与actuator的整合,监控流量、成功数、超时数等信息
11)turbine:集群监控工具
12)与消息代理结合:trubine可以通过基于消息代理的收集实现
六、声明式服务调用:spring cloud feign
1.定义要暴露的服务接口:@FeignClient("xxx")
2.可以通过发布接口JAR包到maven仓库的方式,让服务消费者引入jar包来更方便的使用接口(前提是接口要稳定、向上兼容)
3.可以通过配置ribbon的参数,来实现超时、重试的配置
4.可以设置请求压缩,提高传输性能
5.可以为每个feign设置日志级别
七、API网关服务:Spring Cloud Zuul
1. 请求路由:路由转发
2.请求过滤:对请求过滤和拦截
3.本地跳转:实现forward的跳转
4.设置请求头:可以通过设置请求头,来解决安全验证、cookie、重定向等问题
5.可以通过网关的动态路由设置,来避免因修改路由而引起的服务挂起
6.可以通过动态过滤器加载,来保证服务的持续服务能力
八、分布式配置中心:Spring Cloud Config
1.获取配置URL:服务IP+端口/{应用名}/{环境名(dev)}/{分支名},其它方法方式:
2.配置中心server,可以配置多套环境的GIT仓库。还可以通过通配符的表达式,来实现复杂的配置需求。
3.可以使用{application}、{profile}、{laber}这些占位符,来配置URI
4.可以通过设置子目录的方式,来为一个应用配置一个目录:spring.cloud.config.server.git.searchPaths={application}
5.可以通过actuator的端点接口(refresh),重新获取和刷新配置。
九、 消息总线:spring cloud bus
1.消息总线的功能:广播消息
2.spring cloud config可以整合spring cloud bus,通过简单的配置,就能实现发送请求,动态刷新配置的功能
3.也可以通过和kafka整合,达到同样的效果
4.spring cloud bus,是使用了spring cloud stream构架的上层应用。如果要使用其它消息中间件,可以实现一套指定消息代理的绑定器即可
十、消息驱动的微服务:spring cloud stream
1.核心概念:
2.绑定器(Binder):用于连接消息中间件和业务逻辑的一个中间层。
3.topic主题:发布共享消息给消费者的地方。RabbitMQ中对应的是Exchange,Kafka中对应topic。
4.channel:消息通道
5.发布-订阅模式:当一条消息被投递到消息中间件之后,它会通过共享的topic主题进行广播,消息消费者在订阅的主题中收到它
6.消费组:针对多实例的情况,把不同实例的服务,设定为一个组,只消费消息一次
7.消息分区:消息的特征ID,用来保证同类的消息,能被发送到一个特定的实例上实现累计统计的效果
8.spring cloud stream 整合了 spring bott 和 spring integration(消息框架)
十一、分布式服务跟踪spring cloud sleuth
1.实现跟踪:主要通过traceId+spanId
2.跟踪原理:
1)traceId:唯一标识
2)spanId:记录开始、结束时间和状态
3)请求header中增加的跟踪信息:
-
- X-B3-TraceId:一条链路的唯一标识,必填
- X-B3-SpanId:一个工作单元的唯一标识,必填
- X-B3-ParentSpanId:上一个工作单元,root span的该值为空
- X-B3-Sampled:是否被抽样输出的标志,1表示需要被输出,0表示不需要被输出
- X-Span-Name:工作单元的名称
4)抽样收集:通过设定抽样收集策略,可以指定收集的百分比,也可以针对特定的业务场景收集
5)与logstash整合:ELK平台(三个开源工具组合)
6)与zipkin整合:监控与时间消耗相关的需求。可以查某个时间段内用户请求的处理时间
7)http收集:可以根据zipkin的WEB页面,查看各类监控信息
8)消息中间件收集:通过加入spring cloud stream,可以时间通过消息中间件收集跟踪信息
9)收集原理:
-
- 数据模型:span、trace、annotation(cs、sr、ss、cr)、binary annotation
- 收集机制:每个系统实例,合并span后发送
10)数据存储:默认提供支持mysql
11)API接口:zipkin的UI模块也是基于它的restFul API开发的