具有go特⾊色的运维 在⾼高并发，通信交互复杂，重业务逻辑的分布式系统中， Go语⾔言优势体现在：开发体验好 、⼀一定量级下服务稳定 、性能满⾜足 需要 ⼀一定量级下服务稳定： 50+内部产品，万款开发平台app 实时⻓长连接数亿量级，⽇日独数⼗十亿量级 1分钟内亿量级⼲⼴广播,⽇日下发峰值百亿量级 400台物理机，9个独⽴立集群，国内外近10个IDC 线上单机最⾼高160w⻓长连接 （24核 E5-2630 @ 2.30GHz 64G内存 ） qps在2~5w（取决于协议版本，业务逻辑，接⼊入端⺴⽹网络状况） 测试环境，可以通过300w⻓长连接压测（⺴⽹网络,连接稳定,⽆无带宽限制,实际可以更⾼高 ,决定于⼲⼴广播时候业务内存开销的cpu消耗带来的⼼心跳或者业务延时能否接受） 以360消息推送系统为例 ⾼高并发、通信交互复杂 � �/ ����/ ���� Admin���� ���������� �������� ������� ���push������ ������ 消息系统规模架构：重业务逻辑 ⾼高并发、通信交互复杂 Dispatcher Service Room Service Proxy Service Register Service Saver Service

第⼆部分 端点 PaaS 发展历程 有状态服务 Job / JobFlow 批计算 流计算 ⽆状态服务 DaemonSet Workloads 多集群调度 混合云调度 跨云迁移 多环境调度 业务数据统⼀调度 集群核⼼服务 Helm 镜像服务 Add-on filebeat / telegraf 监控 ⽇志 HPA Operator 注册中⼼ 配置中⼼ API API ⽹关 微服务拓扑 全链路追踪 错误分析 ⽇志分析 主动监控 浏览器监控 APP 监控 慢SQL JVM 诊断 ⾃定义告警 APM 微服务管理 资源管理 标签管理 系统监控 集群管理 服务⽬录 埋点 数据库 ⽇志 画像 标签 报表 推荐 … 代码管理 持续集成 编排部署 应⽤运维 测试管理 协同管理 数据源管理 数据集成 数据开发 数据资产 数据服务

• 功能重复开发 • 运维成本高 • 流量统一控制能力低 • 引入BFE后 • 功能统一开发 • 运维统一管理 • 流量控制能力增强 • BFE平台的主要功能 • 接入和转发，流量调度，安全防攻击，数据分析 BFE部署前 BFE部署后 L4LB 业务A 集群 业务B 集群 业务C 集群 BFE 业务A 集群 业务B 集群 业务C 集群 L4LB BFE平台架构 负载均衡器 强。可以达到单个连 接 / 请求的粒度。 高。负载均衡器引 入了额外的资源消 耗。 低。客户端基本不 需要实现策略。 总体流量规模不大 （从负载均衡器资 源消耗的角度）； 应用场景对流量控 制要求高。 基于名字服 务 + 客户 端策略 弱。客户端直接访问 服务，没有可靠的卡 控点，无法实现精细 的流量控制测量。 低。不需要额外的 资源投入。 高。客户端需要支 持比较复杂的策略， BFE为什么基于Go语言 • 研发效率 • 远高于C语言 • 稳定性 • 内存方面错误降低 • 可以捕捉异常 • 安全性 • 缓存区溢出风险降低 • 代码可维护性 • 可读性好 • 易于编写高并发逻辑 • 网络协议栈支持 BFE的短板 • 没有在内存拷贝上做极致优化 • 使用Go系统协议栈 • 无法利用CPU亲和性（CPU Affinity） • 无法控制底层线程 七层负载均衡的生态选择

2020 年底面临的问题 ● 无法查询超过 30 天的数据 ● 查询慢，平均时间超过 2 分钟 ● 跨集群指标无法聚合 ● Prometheus 集群经常崩溃 ● 维护时 Prometheus 会丢数据 ● 成本高，需要大容量 SSD 磁盘 2021-2022 核心需求 可跨集群查询 长期存储 兼容 Prometheus 扩展性强 无侵入性 Why Thanos VS VS Gateway Store Gateway Redis 2022 年底面临的问题 ● 超 100+ 倍数据点增长导致查询缓慢 ● 架构复杂，参数调优困难 ● 频繁 OOM ● 集群规模受制于 Prometheus ● 集群成本上升 2023 压测结果 VS ● CPU 使用低 1.7 倍 ● RAM 使用减少 5 倍 ● 存储空间减少了 3 倍 25K+ 1Mil 60Mil+ 业务指标数量 VMInsert Why VictoriaMetrics so good？ 第四部分 极致的设计与优化 ● 根据容器可用的 CPU 数量计算协程数量 ● 区分 IO 协程和计算协程，同时提供了协程优先级策略 ● 使用 ZSTD 压缩传输内容，降低磁盘性能要求 ● 根据可用物理内存限制对象的总量，避免 OOM ● 区分 fast path 和 slow path Gorilla 压缩算法

gRPC协议 日志记录 缓存控制 调用鉴权 异常捕获 并发控制 数据统计 监控报警 链路跟踪 自动降载 自动熔断 超时控制 Redis集群 Redis集群 数据库 MySQL集群 MongoDB集群 ClickHouse集群 服务发现 ETCD集群 Redis集群 代码未动，数据先行 ● 定义数据边界 ● 数据库互相隔离，通过RPC访问 ● No join, no pain! 用户 商品 支持自定义fallback ● http/rpc框架内建 ● 自动触发，自动恢复 自适应熔断 ● K8S的HPA 80%触发 ● CPU>90%开始拒绝低优先级请求 ● CPU>95%开始拒绝高优先级请求 ● 基于滑动窗口，防止毛刺 ● 有冷却时间，防止抖动 ● 实践检验，配合K8S弹性伸缩 ● http/rpc框架内建 自适应降载 ● 超时 ● 级联调用 ● 跟客户端超时配合 重试 ● 指数退避 ● 流量quota ● 超时相关性 更多组件 Requests 并发控制 自适应降载 自适应熔断 Rpc Call K8S弹性伸缩 限流 负载均衡 多重防护，保障高可用 ● 链路跟踪 ● Logging ● Metrics ● 监控报警 可观测性 没有度量，就没有优化！ ● 数据上报到控制台服务 ● 数据上报到prometheus go-zero如何高效解决问题

开发者直接使用K8s的失败故事 • 认知成本高：K8s功能强大却没有统一的使用方式，不得不学习复杂的声明字段和各种奇怪的Annotation； • 稳定性不足：没有设置Pod的QoS等级，导致频繁被驱逐，没有设置反亲和性策略，导致节点流量不均; • 扩展效率低：需要负责安装，升级丰富的云原生插件，无法解决插件的依赖，冲突和资源浪费问题； • 运维成本高：Apiserver, etcd, Controller-Manager Controller-Manager, Kubelet,等组件都具有一定复杂度，无法做到定期升 级以维持安全，高可用，高性能的状态； • … 能力复用 自动化 可观测 稳定 安全 开发者真正想要的是策略：大象无形的基础设施，坚如磐石的中间件，丰富高效的应用PaaS平台 基础设施 云原生PaaS平台提供应用管理策略 基础设施 K8s 云原生生态（CNCF） 云原生应用 4 6 7 2 控制器设计（做什么） • 基于“可重构”状态机，开放的世界 • 不要修改资源声明 • 事件驱动+主动轮询 • 重试 + 幂等 • 自愈 • e2e测试 • Ginkgo BDD • Kind本地K8s集群 新的复杂度-最终一致性 status: … phase: succeed … • 过期的状态 • 版本冲突 • 业务及时性 status: currentBatch: 1

缓存过期  定期同步  主动方式  监听数据变化 数据加载，更新 02. 全量数据加载，增量数据监听 • 每个应用服务分别消费数据变更消息 • 一个应用服务消费数据变更，应用服务集群内广播 Maxwell是一个能实时读取MySQL二进 制日志binlog，并生成JSON格式的消 息，作为生产者发送给Kafka、 RabbitMQ、Redis、文件或其它平台的 应用程序 业务数据已经超过1000万，海量数据下，如何实现冷热数据的交换 冷 热 新 系 统 历 史 数 据 冷数据、数据量多 缓存成本大、命中低、收益小 热 数 据 当前系统中的热点数据 命中率高 系 统 新 增 数 据 近期新增数据，较大概率命中 存储空间 缓存性能 冷热可交换，引擎可扩展 06. 冷热数据交换，通过栈式缓存结构，实现多级缓存策略 语言的局限性 07. 基于 耗时问题 MemoryTile的通用性 复杂的数据结构，如何处理？ 复杂结构的处理 MemoryTile Marshal MemoryTile g o la n g 语 言 专 用 、 高 效 适 合 专 用 的 特 殊 场 景 MsgPack 通 用 、 跨 语 言 、 跨 架 构 适 合 协 议 、 传 输 、 存 储 MemoryTile序列化性能提升超2倍 MemoryTile反序列化性能提升近10倍

Cassandra MongoDB ... Google Spanner Google F1 TiDB RDBMS NoSQL NewSQL NewSQL 是什么 ● 水平扩展 ● 事务 ● 高可用 & 自动故障恢复 ● SQL TiDB ● Scalability as the first class feature ● SQL is necessary ● Compatible with 还有一些你看不到的东西：调度 调度的目标 ● CPU ● IO ● 内存 ● 磁盘使用量 ● 网络流量 ● Location Awareness 调度的方法 ● PD 周期性根据 Cache 中的集群信息，生成调度计划（Operator） ● Operator 是作用于一个 Region 的一系列操作 ○ Transfer Leader：将 raft group 的 leader 转让给某个 生成 Operator 使之均衡 调度的难点 ● 难以评判什么样的数据分布情况是最优解 ○ 机器配置不同 ○ CPU、内存、磁盘、网络多种因素相互制约 ○ 用户场景多变 ● 调度所依赖的集群状态不一定是最新的 ● 调度本身也会带来系统负担 多副本管理策略 ● 使用多副本保证数据安全（Data safety） ● 维持数据副本数 ○ 副本数不足：AddPeer ○ 副本数过多：RemovePeer

11:3999/maxq.slide#1 8/22 4. MaxQ - AMQP实现架构 按照协议spec自动生成frame encode/decode Exchange接口化 Queue接口化——MaxQ集群 7/1/2017 基于amqp实现的golang消息队列MaxQ http://192.168.10.11:3999/maxq.slide#1 9/22 MaxQ - 生产实现架构 7/1/2017 基于amqp实现的golang消息队列MaxQ http://192.168.10.11:3999/maxq.slide#1 10/22 5. MaxQ相关特性 1. 消息可靠性 2. 容错性 3. 扩展性 4. 高并发 7/1/2017 基于amqp实现的golang消息队列MaxQ http://192.168.10.11:3999/maxq.slide#1 11/22 消息可靠性 1) Publishing可靠性 Queue 7/1/2017 基于amqp实现的golang消息队列MaxQ http://192.168.10.11:3999/maxq.slide#1 12/22 容错性 zookeeper不可用 元数据已缓存在内存中，不会有任何影响，生产方和消费方仍可正常生产和消费 服务自动降级，元数据不可变更 zookeeper恢复，服务自愈 7/1/2017 基于amqp实现的golang消息队列MaxQ

语言的大多数代码示例和练习都和控制台有着密不可分的关系而 感到惊奇，因为提供平台依赖性的 GUI（用户界面）框架并不是一个简单的任务。有许多由第三方发起的 GUI 框架项目正在如火如荼地进行中，或许我们会在不久的将来看到一些可用的 Go 语言 GUI 框架。不过 现阶段的 Go 语言已经提供了大量有关 Web 方面的功能，我们可以通过它强大的 http 和 template 包来 达到 Web 应用的 GUI 实现。 的编程语言，这不仅体现在它可以处理使用 UTF-8 编码的字符串，就 连它的源码文件格式都是使用的 UTF-8 编码。Go 语言做到了真正的国际化！ 1.2.6 语言的用途 Go 语言被设计成一门应用于搭载 Web 服务器，存储集群或类似用途的巨型中央服务器的系统编程语言。 对于高性能分布式系统领域而言，Go 语言无疑比大多数其它语言有着更高的开发效率。它提供了海量并 行的支持，这对于游戏服务端的开发而言是再好不过了。 Go C 编译器名称为 6c、8c 和 5c，相关的汇编器名称为 6a、8a 和 5a） 标记（Flags） 是指可以通过命令行设置可选参数来影响编译器或链接器的构建过程或得到一个特殊的 目标结果。 可用的编译器标记如下： flags: -I 针对包的目录搜索 -d 打印声明信息 -e 不限制错误打印的个数 -f 打印栈结构 -h 发生错误时进入恐慌（panic）状态 -o 指定输出文件名 // 详见第3