生前碰巧出任了 2021 年 GIAC 全会云原生植物展演的监制兼客座教授，组织机构了其间五个把戏的演说，在那个操作过程中对个人同时做为电视观众从这些南埃尔普的演说小学到了很多十分有用的知识。本文算是对 2021 GIAC 云原生植物展演的T5670，ratings，以观 2021 年云原生植物控制技术发展概要今后一段时间内的态势。
云原生植物那个词含义广泛，涉及到资源的高效利用、交货、部署及互联网管理等各个方面。
从控制系统层次分可以区分加贺原生植物基础设置【如储存、互联网、管理平台 K8s】、云原生植物开发工具、云原生植物应用领域构架和云原生植物交货互联网管理管理体系，本次展演的五个议程也基本涵盖了这四大方向：
Amazon的资深控制技术专家J063的《一个云原生植物服务项目的核爆直径治理》
快手基础构架服务中心服务项目分层相关人士王宁生的《快手开发工具 Mesh 化实践》
Tetrate 可观测性工程师柯振旭的《使用 SkyWalking 监控 Kubernetes 事件》
生前以 Dubbogo 社区相关人士公司出品的《Dubbogo 3.0：Dubbo 在云原生植物黄金时代的终极目标》
下面根据对个人现场笔记和对个人回忆分别记述各个议程的要点。因时间和生前能力有限，一些严重错误难免，还请圣皮耶尔县喔尖萼。
1.云原生植物服务项目的核爆直径
对个人理解，黄老师的那个议程属于云原生植物应用领域构架范畴。
其演说内容具体来说从Amazon AWS 十年前的一个故障通卓林：AWS 某服务项目的实用性服务中心是一个 CP 控制系统，一次数人的互联网更改引致实用性服务中心的输入输出存储结点被击垮，当互联网管理相关人员紧急恢复更改后，由于实用性服务中心不可用【有效复本数多于一半】引致了整座储存控制系统其他统计数据结点认为实用性统计数据连续性不正确DNS项目，最后引致整座控制系统服务项目崩溃。
TRAP整座事故的根本原因是：CAP 定理对易用性和连续性的定义限定十分严格，并不适合应用领域于实际的生产控制系统。因此做为圣戈当斯区控制面的实用性服务中心的统计数据应该在确保最后连续性的前提下，具体来说确保易用性。
再进一步，现代分布式系统控制系统的数人操作严重错误、互联网异常、软件 Bug、互联网/存储/计算能力用尽等都是不可避免的，分布式系统黄金时代的设计相关人员一般都是通过各种输入输出【如多储存南区、多服务项目复本】手段确保控制系统的可信性，在不可信的硬件管理体系之上构建可信的服务项目。
但是这中间有一个误区：有时候一些输入输出手段可能因为雪崩效应反而会引致控制系统的可信性降低。
如上面的事故，数人的实用性严重错误引致了一连串的软件管理体系故障，且这些故障之间是高度强相关的，最后引致了雪崩效应，可以称之为“水平扩展的毒药效应”。此时思考的维度就从“在不可信硬件管理体系上提供可信服务项目”进一步拓展为“通过各种隔离手段减小事故的核爆直径”：当不可避免的故障发生时，尽量把故障损失控制到最小，保障在可接受范围内，确保服务项目可用。
针对那个思路，黄给出了如下故障隔离手段：
服务项目粒度适中
微服务项目的服务项目粒度并不是拆分的越细越好。如果服务项目粒度过细，会引致服务项目数量过多，其第一个后果就是引致一个组织机构内几乎无人能搞清楚服务项目整体逻辑的来龙去脉，增加维护相关人员的负担：大家只敢小修小补无人敢做出大幅度的优化改进。
服务项目粒度过细的第二个后果是造成整体微服务项目单元体指数级增加，造成容器编排部署成本上升。适中的服务项目粒度要兼顾构架管理体系的进化与部署成本的降低。
充分隔离
进行服务项目编排时，
“不近”是指同一个服务项目的复本不在使用同一个电源的同一个机柜部署，也不在使用了同一个互联网平面的 Azone 内部署。“不远”是指部署距离不能太远，例如多复本可以同城多 IDC 部署。使用这两个原则兼顾性能与控制系统可信性。
随机南区
所谓的随机南区这块，其实质就是在混合服务项目请求，确保某个服务项目的请求可以走多通道【队列】，确保在某些通道挂掉的情况下不影响某个服务项目的请求处理，应用领域随机南区控制技术，将用户打散在多个 Cell 中，大幅度降低核爆直径。
与 K8s APF 公平限流算法中的洗牌分片（Shuffle Sharding）颇为相似。
混沌工程
通过持续内化的混沌工程实践，提前踩雷，尽量减少“故障点”，提升控制系统可信性。
使用 SkyWalking 监控 Kubernetes 事件
那个议程虽然被安排在第三场演说，属于云原生植物交货互联网管理管理体系，但是与上个议程关联性比较强，所以先在此记述。
如何提升 K8s 控制系统的可观测性，一直是各大云平台的服务中心控制技术难题。K8s 控制系统可观测性的基础统计数据是 K8s event，这些事件包含了 Pod 等资源从请求到调度和资源分配的全链路信息。
SkyWalking 提供了 logging/metrics/tracing 等多维度可观测性能力，原来只是被用于观测微服务项目控制系统，今年提供了 skywalking-kubernetes-event-exporter 接口，专门用于监听 K8s 的 event，对事件进行提纯、收集、发送至 SkyWalking 后端进行分析和储存。
柯同学在演说操作过程中花费了相当多的精力演说整座控制系统的可视化效果如何丰富，对个人感兴趣的点如下图所示：以类似于大统计数据流式编程的手段对 event 进行过滤分析。
其可视化效果与流式分析手段都是蚂蚁 Kubernetes 平台可借鉴的。
快手开发工具 Mesh 化实践
快手的王宁生在那个议程中主要讲解了快手 Service Mesh 控制技术的实践。
姜老师把 Service Mesh 分为三个世代。其实划分标准有很多，如何划分都有道理。很明显，姜把 Dapr 划入了第三个世代。
上图是快手的 Service Mesh 构架图，很明显借鉴了 Dapr 的思想：下沉基础组件的能力到统计数据平面，把请求协议和接口标准化。一些具体的工作有：
统一互联网管理，提高可观测性与稳定性，进行故障注入和流量录制等；
对协议栈和序列化协议做了大量的优化；
实施了面向失败设计，Service Mesh 可以 fallback 为直连模式。
对个人感兴趣的是姜提到了 Service Mesh 控制技术在快手落地时面临的三个挑战：
成本问题：复杂环境下的统一部署与互联网管理。
复杂度问题：规模大、性能要求高、策略复杂。
落地推广：对业务来说不是强需求。
特别是第三个挑战，Service Mesh 一般的直接收益方不在业务端，而是基础构架团队，所以对业务不是强需求，而且快手这种实时业务平台对性能十分敏感，Service Mesh 控制技术又不可避免地带来了延迟的增加。
为了推动 Service Mesh 控制技术的落地，快手的解决手段是：
具体来说务必确保控制系统稳定性，不急于铺开业务量；
搭车公司重大项目，积极参与业务构架升级；
基于 WASM 扩展性，与业务共建；
选取典型落地场景，树立标杆项目。
姜老师在最后给出了快手下半年的 Service Mesh 工作：
很显然那个路线也是深受 Dapr 影响，理论或者构架上创新性不大，更侧重于对开源产品进行标准化并在快手落地。
在演说中姜提到了 Serivce Mesh 控制技术落地的两个标杆：蚂蚁集团和字节跳动。其实他们成功的很重要原因之一就是高层对先进控制技术的重视和业务侧的大力配合。
Dubbogo 3.0：Dubbo 在云原生植物黄金时代的终极目标
做为那个议程的客座教授，我在演说中并没有过多强调 Dubbo 3.0 已有的特性，而是着重演说了 Service Mesh 的形态和柔性服务项目两块内容。
Dubbo 3.0 比较重要的一个点就是 Proxyless Service Mesh，那个概念其实是 gRPC 的滥觞，也是近期 gRPC 生态力推的重点，其优点是性能无损，微服务项目升级方便。但是 gRPC 自身的多语言生态十分丰富，且 gRPC 鼓吹那个概念的另一个原因做为一个中庸的强调稳定性的框架其性能不甚优秀，如果考虑 Proxy Service Mesh 形态则其性能更加堪忧。
而 Dubbo 生态的最大劣势是除了 Java 和 Go 外，其他多语言能力不甚优秀，对个人觉得跟着 gRPC 邯郸学步，完全把其他语言能力屏蔽在外不是什么好主意。Dubbogo 社区公司出品的 dubbo-go-pixiu 项目在网关与 sidecar 两种形态下解决 Dubbo 生态的多语言能力，把南北流量和东西流量统一到 Pixiu 中。
不管是何种形态的 Service Mesh 控制技术，其在国内的发展已经渡过第一波高潮，自蚂蚁集团和字节跳动这两个标杆之后走向了寥落，其自身还需要不断进化，更紧密地与业务结合起来让中小厂家看到其业务价值，才会迎来其后续的第二波高潮。
Service Mesh 自身特别适合在 K8s 之上帮助中小厂家把服务项目迁移到的混合云或多云环境，这些环境大都使用了大量的开源软件管理体系，能够帮助他们摆脱特定云厂商依赖。
Dubbo 3.0 的柔性服务项目，基本上可以理解为反压控制技术。Dubbo 与 Dubbogo 之所以要做柔性服务项目，其背景是在云原生植物黄金时代结点异常是常态，服务项目容量精准评估测不准：
机器规格：大规模服务项目下机器规格难免异构【如受超卖影响】，即使同规格机器老化速度也不一样；
服务项目拓扑复杂：分布式系统服务项目拓扑结构在不断进化；
服务项目流量不均衡：有洪峰有波谷；
依赖的上游服务项目能力不确定性：缓存/db 能力实时变化。
其应对之道在于：在服务项目端进行自适应限流，在服务项目调用端【客户端】进行自适应负载均衡。
自适应限流的基本思想是基于排队论的 littles law 的改进：queue_size = limit * (1 – rt_noload/rt)，各个字段的意义如下：
limit 一段时间内的 qps 上限。
rt_noload 一段时间窗口内的 RT 最小值。
rt 一段时间内的平均 RT，或者可直接取值 P50 RT。
即以两种形态的 RT 来评估 method 级别服务项目的合适性能。RT 增大反映了整体 load{cpu/memory/network/goroutine} 增大，性能就会下降。反之，RT 减小反映了服务项目端能够处理更多请求。
自适应限流：服务项目端是在 method 级别计算 queue_size，同时计算当前 method 的使用的 goroutine 数量 inflight【假设每处理一个客户端请求耗费一个 goroutine】，服务项目端每次收到某个 method 的新请求后理解实时计算 queue_size，如果 inflight > queue_size，就拒绝当前请求，并把 queue_size – inflight 差值通过 response 包反馈给 client。
自适应负载均衡：客户端通过心跳包或者 response 收到 server 返回的某个 method 的负载 queue_size – inflight，可以采用基于权重的负载均衡算法进行服务项目调用，当然为了避免羊群效应造成某个服务项目结点的瞬时压力也可以提供 P2C 算法，Dubbogo 都可以实现出来让用户去选择。
上面整体内容，社区还在讨论中，并非最后实现版本。
场外
从 2017 年到现在，对个人参加了大大小小十几次国内各种级别的控制技术全会，身份兼具监制和客座教授。演说水平不高，但基本的时间控制能力还可以，做到不拉场。这次主持 GIAC 的云原生植物分场，电视观众对本展演的评分是 9.65【所有展演横向评分】，总体表现尚可。
很碰巧生活在那个黄金时代，见证了云原生植物控制技术大潮的起起伏伏。亦很碰巧工作在阿里那个平台，见证了 Dubbogo 3.0 在阿里云钉钉内部的各个场景的逐步落地。
参考阅读：Hints for Microservice design – 如何进行微服务项目的划分
云原生植物互联网代理 MOSN 的进化之路
高可用构架改变互联网的构建方式
