阿里云云原生开源开发者沙龙

2023年8月27日

Dubbo Triple 协议升级实现web、移动端、后端服务全面打通

一、RPC协议的困境

存在的问题：

南北向调用http比较简单，dubbo比较复杂
RPC服务难以调试
客户端需要HTTP协议转发，需要比较复杂的转发层，性能消耗大。

二、全新的Triple协议

上一代Triple

SPEC与实现上完全兼容gRPC，同时提供更灵活的实现，但是没有避免传统RPC可以的缺点
任意序列化，非IDL（不强制protoBUF）
还是没办法通过http client直接调用

新一代Triple特性

兼容gRPC gRPC-web HTTP/1 HTTP/2
调试友好
仅依赖HTTP特性，选择经过长期检验的网络库
不只是Unary，提供了Stream场景的支持
- 客户端流 CLient Stream
- 双向流 Bi Stream

三、Triple协议开发为服务

定义服务

IDL定义服务
POJO定义服务

快速调试服务

curl

Client调用

IDL、POJO简单调用
不需要起客户端，支持前端

四、RPC but not RPC

Triple只是Dubbo中内置的一款协议，外部的接口是统一的

Dubbo提供其他的底层能力

服务发现
接口
链路追踪

Dubbo Admin提供了可视化的集群状态管控

今年会用go重写

提供了便捷的服务治理

Higress：下一代云原生网关

站在Nginx和Envoy的肩膀上

Higress简介

诞生背景：
- 2020年ali本地生活战役
- 蚂蚁与aliRPC互访
特性（Tengine只有后面两个）
- 完整支持http grpc
- 支持配置的热更新
- 支持丰富的路由策略
- 业界主流技术
- 东西向跨域网关
发展历程：
- 提出流量网关和微服务网关合并的想法
- 独立部署防止被云商绑定

站在Nginx的肩膀上

更精确的配置管理
- nginx配置变更reload会导致downstream和upstream都断开重连，导致CPU飙升，严重可以导致雪崩
- Envoydownstream抽象成了listener，交由LDS实现配置发现
- upstream抽象成cluster，交由CDS实现配置发现
- 重建只导致downstream连接断开，不会影响upstream
- 证书等更新不影响downstream
更高效的现代化协议
- gRPC/HTTP2/HTTP3
- 过往协议无HTTP2等新协议优化
革命性的扩展机制：WebAssembly
- 低延时，无论什么语言一次约0.01ms
- LLVM IR优化层，对开发者透明

站在Envoy的肩膀上

标准化
- 支持K8s Ingress API，支持Nginx Ingress核心功能解注册无缝转换
- 比Nginx Ingress 提供更实用的功能注解，如服务级限流、RESTful路由
- 拥抱Gateway API（下个月），混合使用，平滑迁移
高集成：异构架构下服务发现和路由
易扩展：简单的SDK和CRD

RocketMQ 分级存储设计详解

分级存储技术选型背后的故事，数据存储模型与竞争力

一、存储模型简介

存储协议的差异：物理机、云盘（块存储）、对象存储
- 直写的目的是池化存储，转写的目的是降低长期保存成本，两者可以结合
从KV系统抽象出字节流模型
- 无限长度的字节流
- 不同Topic混合存储->队列级别的拆分

二、数据上传流程

可重复读：分级存储与本地存构建的顺序索引必须强一致
- commitLog
随机索引重排减少平均10次数
- 文件结构：file header 、 hash 、冲突追加数据到Item Block（需要多次读取Item Block）
- 一次取回slot

三、数据读取流程

存储被视为多级缓存，越上层的戒指随机读写速度快
转冷时主动对数据做compaction，从二级存储读取是连续的，把更宝贵的一级存储IOPS留给在线业务
分级存储抽象为存储策略
数据预读

四、更多有趣场景

定时消息
压缩和归档

RocketMQ高可用设计范式

内容来自于阿里今年ACM论文

一、背景

RocketMQ不再局限于一个消息中间件，而是一个云原生消息、事件、流实时数据处理平台，覆盖云边端的多样协作场景。

不同场景下对高可用的要求不同

二、RocketMQ高可用方案

两种传统的实现方案

master&slave
RAFT实现：leader&follower

弊端：

master、slave
- master故障，消息发送终端，整体写分区减少
- 在master上的操作不可进行，影响顺序消息和管控
RAFT
- 需要三副本以上
- ACK不够灵活
- 存储库不是RocketMQ原生的，有些用不了（0拷贝等）

新的融合架构

切换/无切换架构，用于不同场景
Master-slave中增加松耦合选主莫哭啊
无切换架构升级，Messaging场景下及时无切换也可以Failover

三、高可用范式

Container
- 角色多样性
  - 一台机器可以同时拥有主、备
- 资源利用率
Impostor
- 打开slave-act-master，从节点假装主节点，但是只能读不可以写；也可以参与选举
Controller
- 数据强一致
- 主动管理broker主备关系
- 故障可恢复
Merger
- 按最早同步的数据位点截断
Regulator
- 数据上报
- 慢节点剔除
Notifier
- 客户端测补偿
- 路由反向通知

RocketMQ serverless版的实现与解析

与时俱进的云消息服务

一、serverless的背景

使用方与提供方一次次的互怼中进步------云原生2.0
特点：按需弹性、按需付费
降低成本：沟通成本、付费成本、运维成本、资源利用率提升
以客户期望为目标的思考
- 提供方：轻量化接入设计、弹性伸缩与调度、规模化多租形态、可靠的SLA保障、完善的监控运维
- 适用方：方便理解快速适配、用量付费降低成本

二、RocketMQ serverless

可靠的SLA保障
- 技术架构及部署架构稳定性设计：Region化、多集群部署、降低中心、集中化
- 系统运行稳定性保障：SRE平台
计算、存储与网络：充分利用云的弹性能力
“用户”调度：资源弹性的补充
- Meta Server
- SRE
全新的轻量级多语言SDK：与富客户端互补、更易于集成
- 极简API
- 通信层gRPC
分级存储助力
可观测性走向云原生标准

阿里云-云原生开源开发者沙龙