《深入理解Dubbo工业级架构设计》,中国机械出版社
问题探索
如何保证服务的高可用,行业中的99.999999% 是如何设计出来的。高可用设计包含了哪些范畴(链路高可用,网络高可用,物理机高可用,服务高可用,数据高可用)?
涉及知识点内容
- 微服务架构详解
- 微服务同城容灾实现 p7~P83?思想层面与代码落地层面
- 微服务之追踪架构详解。问题追踪!针对问题的快速定界与定位?
- 微服务之容错保障策略 ribbion ALIBABA DUBBO dubbox 设计层面比较深入(开源社区)阿里
- 微服务之容错保障策略,微服务层面是如何提供高可用?秒杀,抢购,限流量场景。
面试题!
你了解微服务吗?项目中使用了微服务什么样的功能。
聚焦微服务架构
微服务架构,Spring Cloud,Dubbo,Spring Cloud alibaba,soft rpc stack brpc stack grpc
什么是服务化/微服务?
微服务是在什么样的背景下推出?SOA(面向服务编程,webservice,soap,wsdl)经验,解决业务功能的重用性。业务生产落地中发现的问题,SSM+Spring Boot(运行的问题,流量不均衡,导致产品使用出现严重的分化)商品模块80%流量 + 支付模块20%流量 ,支付与商品与库存(数据垂直领域划分)与订单(信息关系)是属于两个领域下的业务,HTTP API,针对细颗粒服务的交互,衍生出来一种新的技术解决方案,RMI RPC(调用协议)。
数据领域划分
单体(SSM)+ 分库(分布式事务),JPA分布式标准(不是实现)
ORM对象映射(实体BEAN与数据库表之间的关系映射)
zookeeper nacos etcd eureka:服务透明化(消费者,不知道具休的服务提供者,而有注册与发现中心通知消费者,服务的具体地址是什么)
CAP,AP,CP ,保证数据,服务
Spring Boot:简易化的开发模式(项目构建方法论)!
Microservices.io
martinfowler.com
- 由一组小服务组成的应用。这一组服务往往提供特定的业务能力
- 往往拥有自己独占的进程,通过轻量级的通讯协议进行通讯,比如http
- 能够独立部署,并且具有完全的自动化的部署能力
- 极小化的集中式的服务管理能力
- 可以使用任何的开发语言和数据库技术
巨石程序vs微服务
单体应用的例子
单体应用拆分
为什么要使用微服务?
阿里的微服务实践 – 中台思想
百万架构运营微服务实践 – 中台思想
服务编排 K8S DOCKER,业务编排,ROS 资源编排 OA(钉钉)
Dubbo 体系
服务化后的开发方式转变
微服务改造面临的挑战
- 不正确的服务拆解比巨型应用还危险
- 分布式的复杂度,开发、测试、事务、部署。
- 运维复杂度 配套系统完备性
- 组织的成熟度
阿里云微服务应用
微服务调用架构详解
HTTP协议调用,RPC协议调用,HTTP2协议调用,RMI协议调用,GRPC协议调用,REST协议调用
PAYLOAD(数据载体),协议选择目录,快速,Dubbo,协议压测数据报告
dubbo 协议 效率比较高,针对密集型方法请求的而特定延迟的内部传播协议。
小数据量传播,效率比较高(长连接)
生产环境存在多个接口版本!
A接口a服务,A接口b服务,通过IF else分支策略来确定商品数据的表现形式呢?业务耦合性太强
远程过程调用:调用方法(接口+方法+参数+参数值,版本号,分组)RPC协议本质。
远程调用核心的协议数据:(接口+方法+参数+参数值,版本号,分组),这种数据是否能够满足远程调用的需求呢?
http:超文本传输协议(<a = url),针对web资源定位而产生的协议类型。
http://www.baidu.com/user/getuserinfo.action?uid=xxxxx
Spring mvc controller,http协议涵盖了与方法资源更多无用的元数据标识信息。
协议头&协议体(偏重的协议),soap(重协议,灵活度更高)
rest协议,在HTTP协议上弥补了,method使用范围
多版本:BUG修复或者打补丁了,微功能增加或者修改
分组:同等功能针对不同的用户群体而提供的特色数据
通过大数据实时分析,A高价值人群,B中价值人群,C低价值人群
只有一个注册中心,测试环境,正式环境,灰度环境
服务端:存在接口的实现类
优雅关机!(级联资源释放)
微服务同城容灾实现 (异地容灾)
Invoker <= Cluster(List<Cluster,Cluster>) retry = 4 failover 策略
商品服务,http,rpc
获取服务接口的高度抽象设计 !Dubbo服务获取方面设计不错的地方。
设计比较具体
User getUserInfo(int i)
User getUserinfo(long i)
User getUserinfo(short i)
User getUserinfo(integer i)
User getUserinfo(Objecti) => 高度抽象设计方式,类型转换
User getUserinfo(T i) => 高度抽象设计方式,泛型,响应式编程,函数式编程
容灾:为服务提高高可靠的能力方式,当某地区的服务存在异常,则通过路由切换方式能够快速将损失规避
服务注册与发现:解决客户端与服务端之间的透明化
商品,支付,库存,发布策略
商品:HTTP,RPC,2注册中心=》服务数量,4个服务
Spring Cloud Eureka,不提供多地区注册中心,注册能力,SDK暂时没有实现该功能
Dubbo zk | nacos
region zone ,有形态,但是没有能力!猜测阉割了!开源,会将公司核心价值能力code,而不进行开放!
微服务治理能力功能,不进行开放!阿里云,服务产品化!edas(微服务产品)
eureka 集群 与 多地区集群,这两个是两个概念,多地区对等注册中心集群实现方案,euraka不实现。
负责注册中心,服务注册的是谁?是注册中心吗?还是谁呢?一定是客户端(SDK),EUREKA客户端来进行负责zk,sdk来负责协议业务数据传输,但是提供多注册中心注册的一定dubbo + zk sdk来进行提供的。
微服务之追踪架构详解
- Instrumented client和Instrumented server需要集成在分布式系统的具体服务中
- 采集跟踪信息,调用Transport,把跟踪信息发送给Zipkin的Server。
- Transport是Zipkin对外提供的接口,支持HTTP、Kafka、Scribe等通信方式。
- Zipkin即Zipkin server,主要包括四个模块:
- Collector: 用于接收各个应用服务传输的追踪信息;
- Storage:Zipkin的后端存储
- 支持In-Memory、MySql、Elasticsearch和Cassandra;
- API:提供对外的查询接口;
- UI:提供对外的Web界面。
Http Tracing的时序图
- 用户的请求/foo首先被Trace Instrumentationlan拦截,记录下Tags,时间戳
- 同时在Header里增加Trace信息
- 然后再流转到后端服务进行处理,处理完成后,正常响应
- Trace Instrumentationlan拦截响应,记录处理延时后
- 将Response正常返回给调用方
- 同时异步地将Trace的Span发送给Zipkin Server
Span中的traceld是在整个调用链路上唯一的ID,用于唯一标识一条调用链
栈异常,能够分析问题的代码在什么地方,但是不知道是什么业务数据导致的!空指针异常。
微服务之容错保障策略
容错策略
- failfast 快速失败,只发一起调用,失败立即报错【非幂等性的写操作】(突发流量 ,激增的请求数)
- 线程数量越来越多,不干活,占用资源 OOM 挂掉
- failback 失败之后,后台记录,隔一段时间,定时再次调用【必须成功调用服务】
- 调用补偿机制(增量过程)
- failover 失败自动切换【默认】retries=“3”
- failsafe 出现异常时,返回空结果,直接忽略,记录失败错误
- forking 并行调用多个服务器,只要一个成功即返回【实时性要求较高的读操作】预缓存这种热标记
- broadcast 广播调用所有提供者,逐个调用,任意一台报错则报错【服务同步数据】跨 同Server下的instances
容错保户:当服务调用发生异常,如何进行一下步处理,这个就是容错要解决的问题,解决问题的方式 有很多种 ,这个就是容错的多种策略
秒杀场景特点:异常流量 ,服务各种指标无法满足突发流量的规模(QPS 10W),剩下9W怎么解决?扔掉!
failfast 快速失败!退订流程,苹果鼠标垫1W库存,10W人抢购,退订5千
怎么处理?通过客户端静默抢购方式,圈圈方式!1分钟!敢死队抢购中等待,防止退订。将抢购流量快速返回,retry多少次!5次,决定延迟的递归因子。
陡坡流量(70度)转换成波浪形流量(小高峰流量),抢购流量均衡方式
redis计数器:扣库存
延迟处理!是指MQ(消息队列)?不是,一定是从技术上解决业务的问题
MQ(10 qps),1W:延迟服务端流量的压力