在 k8s 上部署高可用的 service mesh 监控 pctang@caicloud.io 唐鹏程 才云科技TOC Solving issues in a new way Monitoring your service mesh Old-school monitoringPrometheus + Kubernetes ● A time series based monitoring

feature/new_branch 会合并到 develop； • 5. 部署负责人将 develop 分支代码部署到测试环境，然后再通知 QA 测试；（脚本或者人工）有什么问题？ • 效率低 • 没有代码检查； • 没有自动化测试（包括单元测试）； • 沟通成本高 • 开发需要通知负责人、测试、产品等；（而且是每次构建/部署 都需要） • 依赖多较好的开发流程（流程化、自动化） • 1 是一种文化：一切自动化，工具化，规范化；选择哪个 CI/CD 工具？Docker stats 查看 Docker 服务所占用的CPU和内存开销DroneDrone • 一款使用 Go 开发，基于容器技术的 CI/CD 系统，能够单独部署，支持几乎所有的 Git 平台（Github,Gitlab,Bitbucket,Gogs,Gitea 等）。 • 它的特点： • 一个 .drone.yml 搞定（简单） • 原生 Docker go/blob/master/articles/sonarqube-for-golang/2018-07-22-sonarqube-for- golang.mdDrone 和 Jenkins 联调测试方法 本地即可测试 drone 上是否可以调用成功： >docker run --rm \ -e JENKINS_URL= -e JENKINS_USER=

0 码力 | 45 页 | 18.62 MB | 6 月前

3

语言单一 • 升级困难 • 复杂代码嵌入对客户端进程影响大服务化体系2.0 - Service Mesh雏形 • 物理机、sidecar • Local & Remote，主与备 • 轻量级客户端、本地调用 • Local Proxy负责服务治理与 远程通信 • Remote Proxy负责备份和非 主流流量 JavaApp Local Proxy OSP Server Service Trace-log Trace-log 用户与Istio的区别 我是作者名称没有对称的server端agent • 性能考虑 • Proxy已经增加了一跳，server再增加一跳会加剧 性能压力 • 部署考虑 • 服务端agent成为必选项会增加运维压力 • OSP server默认没有agent，web server只带一个 服务注册agent • 服务端的一些治理、trace、鉴权功能通过代码插 调用链埋点的影响必须足够小 • 鉴权需要同步进行，调用Mixer代 价大 • Mixer的中央节点问题 • 传统基于日志收集的tracing方 案足够成熟 • 内部实现一套可插拔的鉴权框 架也能接受混合部署 vs. 绑定K8s • 历史原因导致长期都会物理机 和容器并存，内部需求必须要 同时支持物理机和云 • 绑定K8s能够享受K8s的红利， 但也限制了使用范围 +服务治理程度更接地气 •

以蚂蚁金服的体量，性能不够好则难于接受 • 架构与性能之间的权衡和取舍需要谨慎考虑 ü 稳定性要求 • 以蚂蚁金服的标准，稳定性的要求自然是很高 • 高可用方面的要求很非常高 ü 部署的要求 • 需要用于多种场合：主站，金融云，外部客户 • 需要满足多种部署环境：虚拟机/容器，公有云/私有云，k8s • 需要满足多种体系：Service Mesh，Sofa和社区主流开发框架 Service Mesh落地要面临的实际要求选择开源产品，还是选择自研？ 需要请求同步阻塞等待的功能都应该在 Sidecar中完成 • 远程调用带来的性能开销代价太高 • 其他尽量优化为异步或者批量Istio的解决方案：添加Mixer Cache ü 缓存的工作方式： • Sidecar 中包含本地缓存，一部分的前置 检查可以通过缓存来进行 • 另外，Sidecar 会把待发送的Report数据 进行缓冲，这样可能在多次请求之后才调 用一次 Mixer • 前置检查和配额是同步的 • Report数据上送是使用

(云上) 交付周期 周 分钟级 弹性扩缩容 - 支持 性能 独占 独占 (优于普通ECS) 硬件故障率 硬盘1年故障率 2% 0.8%% (无本地盘) 硬件维修周期 [周, 月] [分钟，天]成本 效率 稳定云化架构 物理机 + 本地存储 + Underlay网 络 神龙/ECS + 远程存储 + Overlay网络 集团机房 云上机房 基础设施 IDC 系统 基础运维 天基系统 (1-5) • 本地检测 (walle, NPD) + 外部系统 (IDC、aliyun) • SLI、SLO、SLA • 钉钉、邮件、电话报警、ChatOps 自助诊断 • 节点故障自愈 (10) • 决策中心执行修复操作 • 集中统一风控 • 日常1人运维数十万节点 统一风控 监控 决策 自愈神龙运维事件 • 接收事件 (doc) • 响应事件 不带本地盘 SystemFailure SystemFailure.Reboot 带本地盘 SystemFailure.Redeploy 不带本地盘 RebootInstance (doc) 带本地盘 RedeployInstance (doc) 本盘数据不能 迁移运维实践 - 宕机率分析 • 宕机关联度分析 • 宕机趋势 • 机房、单元、分组 • 机型、硬件特征 • 内核版本、hotfix 一致率 • 宕机根因分析诊断

杜绝一刀切k8s和Service Mesh落地方案演进路线 部署在 非k8s上 不是Service Mesh形态 部署在K8s上 非SM 部署在 非k8s上 Service Mesh (Sidecar模式) 部署在K8s上 Service Mesh (Istio模式) 部署在K8s上 Service Mesh (Sidecar模式) 部署在 非k8s上 Service Mesh (Istio模式) 不符合蚂蚁的远期规划（k8s是我们的既定目标） • 会造成投资浪费（k8s铺开在即） 演进路线2分析 部署在 非k8s上 Service Mesh (Sidecar模式) 部署在 非k8s上 Service Mesh (Istio模式) 2 2 2 部署在K8s上 Service Mesh (Istio模式) 部署在 非k8s上 不是Service Mesh形态ü 可以理解为路线1的折衷版本 演进路线4分析 部署在 非k8s上 Service Mesh (Sidecar模式) 部署在K8s上 Service Mesh (Sidecar模式) 4 4 4 部署在K8s上 Service Mesh (Istio模式) 部署在 非k8s上 不是Service Mesh形态蚂蚁金服选择的演进路线 部署在 非k8s上 不是Service Mesh形态 部署在K8s上 非SM

• 打包 • 安装 • 部署 • 测试 • 支持主流的微服务框架 • SOFA • HSF • DUBBO • SPRING CLOUD • … • 控制平面创新的地方 • MESH OPERATOR • RPC SERVICE CONTROLLER • …SERVICE MESH 落地中的问题常见的 MESH 落地方案 在非 KUBERNETES 环境部署 ISTIO 把 KUBERNETES 不支持微服务使用的通信协议 • RPC 服务使用的接口，方法，参数语义无法匹配 ISTIO 的路由模 型 • 一个应用上部署了多个 RPC 服务，每个服务有自己的版本 • …ISTIO 控制平面路由的抽象模型 INBOUND OUTBOUNDSOFA 服务注册模型落地一个微服务框架需要的工作 • 部署 ZK 集群作为 RPC 框架的注册中心 • 开发 ZK Platform Adapter for DUBBO 开发一个通用协议处理框架 • 避免为不同的微服务框架修改 PILOT 代码 • 通过插件的方式按需支持新的协议 • 对应用代码无侵入性 • 为微服务框架提供轻量化客户端落地一个微服务框架需要的工作 • 部署 ZK 集群作为 RPC 框架的注册中心 • 开发 ZK Platform Adapter for DUBBO • 开发 DUBBO 服务的 XDS 配置下发 • 开发 DUBBO 服务的路由规则 XDS

Lyft 联合开发，Go 语 言，与 K8s 一脉相承且深度融合 • K8s 提供了部署、升级和有限的运行流量管 理能力 • Istio 补齐了 K8s 在微服务治理上的短板 （限流、熔断、降级、分流等） • Istio 以 Sidecar 的形式运行在 Pod 中， 自动注入，自动接管流量，部署过程对业务 透明 • 提供了完整的 Service Mesh 解决方案 • 数据面：Envoy /0215/24 严选上云 Roadmap16/24 落地关键步骤 拥抱云原生 • 大势所趋 • 容器化是微服务的最佳载体 • 容器化是 Service Mesh 高 效落地的基石 部署平台 • Sidecar 注入，业务无感知 • 加速云化 建设服务治理平台 • 无缝衔接 VM 集群和容器集 群的服务治理能力 • 最大化发挥 Service Mesh 的 优势 灰度引流 eBPF/xDP(sockops)，优化路径为 SVC <-> Envoy，延迟性能提升10-20%。 Envoy 部署方式 per-pod，跟社区方向一致，也是目前严选采用的部署方案。 • 方案2: 采用 DPDK+Fstack 用户态协议栈，优化路径为 Envoy <-> Envoy，延迟性能提升 0.8-1 倍。Envoy 部署方式为 per-node，功能和运维层面的限制还在评估当中。 • Sidecar 模式采用方案1进行优化，gateway

翻译字数 累计翻译的文档中汉字数超过 20 万。 /04 Istio.io 社区化翻译活动Istio 官网本地化活动卓越贡献者 官余棚 @gorda 罗小东 @ilylia 于晓博 @yuxiaobo96 高国良 @gauliang /05 Istio 官网本地化活动详见：https://github.com/servicemesher/istio-official-translation//06

向Istio的标准协议靠拢 重点目标 长期规划15/24 数据平面实践细节 • 部署方式 • 升级方式 • 容灾方式 • 性能问题 • 资源问题 • 兼容问题 关键设计 关键问题16/24 数据平面部署方式 容器化运行方式 • sidecar模式 • 与业务进程相同Pod不同Container 陌陌微服务容器化部署比例在80%以上 并且还在进一步推进 业务接入方式 • 研发人员：升级SDK版本 研发人员：升级SDK版本 • SRE：发布系统配置发布项 sidecar模式部署17/24 数据平面升级方式 – 平滑升级机制 平滑要求 • 业务进程不重启 • 流量保持不变 方案选择 • FD迁移 vs 哨兵集群 原理 • sendmsg / recvmsg接口发送FD • 步骤：listener、存量连接、存量数据 Java实现 • 借助JNI与Netty Java实现FD迁移18/24