上万服务节点下的微服务生态

《深入理解Dubbo工业级架构设计》，中国机械出版社

问题探索

如何保证服务的高可用，行业中的99.999999% 是如何设计出来的。高可用设计包含了哪些范畴（链路高可用，网络高可用，物理机高可用，服务高可用，数据高可用）？

涉及知识点内容

1. 微服务架构详解
2. 微服务同城容灾实现 p7~P83？思想层面与代码落地层面
3. 微服务之追踪架构详解。问题追踪！针对问题的快速定界与定位？
4. 微服务之容错保障策略 ribbion ALIBABA DUBBO dubbox 设计层面比较深入（开源社区）阿里
5. 微服务之容错保障策略，微服务层面是如何提供高可用？秒杀，抢购，限流量场景。

面试题！
你了解微服务吗？项目中使用了微服务什么样的功能。

聚焦微服务架构

微服务架构，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：延迟服务端流量的压力