云技术前景

我有幸担任了2021 GIAC大会云原生专场的制作人和主讲人，前后组织了四场讲座。在这个过程中，我也作为观众从这些同行的演讲中学到了很多非常有用的知识。本文为2021 GIAC云原生专场侧记，窥一斑而见全豹，以观察2021年云原生技术发展现状及未来趋势。

“云原生”一词含义广泛，涉及资源的高效利用、交付、部署、运营和维护。

从系统层面可以区分云原生基础设施[如存储、网络和管理平台K8s]、云原生中间件、云原生应用架构和云原生交付运维体系。本届特别会议的四个议题也基本涵盖了这四个方向:

亚马逊资深技术专家黄帅管理了一个云原生服务的爆炸半径，a auto quicks基础设施中心服务网格负责人江涛，a auto quicks中间件Mesh Practice，Tetrate的可观测性工程师柯徐震用SkyWalking监控Kubernetes。Dubbogo 3.0:云原生时代的Dubbo基石是由Dubbogo社区负责人制作的。

下面，根据个人实地笔记和个人回忆，描述每个题目的要点。由于时间和本人能力有限，有些错误在所难免，请各位专家指正。

云原生服务的爆炸半径

个人认为黄的题目属于云原生应用架构的范畴。

演讲内容从十年前亚马逊AWS的一次故障说起:AWS中某服务的配置中心是一个CP系统，一次人为的网络更改导致配置中心的冗余备份节点被破坏。运维人员紧急恢复变更后，配置中心的不可用【有效副本数不足一半】导致整个存储系统的其他数据节点认为配置数据一致性不正确，拒绝服务，最终导致整个系统服务崩溃。

事故的直接原因是CAP定理对可用性和一致性的定义非常严格，不适合实际生产系统。因此，在线控制平面的配置中心的数据应该在保证最终一致性的前提下首先可用。

此外，在现代分布式系统中，人为操作错误、网络异常、软件错误以及网络/存储/计算资源的耗尽是不可避免的。分布式时代的设计者一般通过各种冗余手段[如多个存储分区、多个服务副本]来保证系统的可靠性，在不可靠的软硬件系统上构建可靠的服务。

但是这中间有一个误区:有时候一些冗余的手段可能会因为雪崩效应而降低系统的可靠性。

比如上述事故中，人为的配置错误导致一系列软件系统故障，而这些故障又高度关联，最终导致雪崩效应，可以称之为“横向扩展的毒害效应”。此时，思考的维度进一步从“在不可靠的软硬件系统上提供可靠的服务”扩展到“通过各种隔离手段降低事故的爆炸半径”:当不可避免的故障发生时，尽量将故障损失控制在最小，保证可接受的范围，保证服务的可用性。

针对这种想法，黄给出了以下故障隔离手段:

服务粒度适中微服务的服务粒度并不是越细越好。如果服务粒度太细，就会导致服务太多。第一个后果是，一个组织中几乎没有人能理解服务的整个逻辑，这就增加了维护人员的负担:大家只敢小修小补，没人敢做实质性的优化和改进。服务粒度的第二个后果是整个微服务单元呈指数级增长，导致容器布局和部署成本增加。适度的服务粒度应该考虑到架构的演进和部署成本的降低。在全面隔离服务布局时，获取数据中心的电源和网络拓扑信息，确保强关联系统之间的部署“不远”“不近”。“不在附近”意味着相同服务的副本不部署在使用相同电源的相同机柜中，也不部署在使用相同网络平面的Azone中。“不远”是指部署距离不能太远。例如，可以在拥有多个IDC的同一城市部署多个副本。使用这两个原则来考虑性能和系统可靠性。随机分区所谓随机分区的本质就是混合服务请求，保证某个服务的请求可以经过多个通道【队列】，保证某个服务的请求处理在某些通道掉线时不会受到影响。使用随机分区技术，用户将分散在多个小区中，爆炸半径将大大减小。与K8s APF公平限流算法中的洗牌切片颇为相似。混沌工程通过不断内化混沌工程实践，提前踩雷，最大限度减少“故障点”，提高系统可靠性。

使用SkyWalking监控Kubernetes事件

虽然这个题目安排在第三讲，属于云原生交付运维系统，但是和前面的题目有很强的关联性，所以这里先描述一下。

如何提高K8s系统的可观测性，一直是各大云平台的中心技术难题。K8s系统可观测性的基础数据是K8s事件，它包含了Pod和其他资源从请求到调度和资源分配的整个链路信息。

SkyWalking提供了日志/度量/跟踪等多维度的可观测能力，最初只用于观测微服务系统。今年提供了SkyWalking-Kubernetes-event-Exporter接口，专门用于监控K8s事件，净化、收集并发送到SkyWalking后端进行分析和存储。

讲座中，柯花了相当多的精力来讲整个系统的可视化效果是多么丰富。他的个人兴趣如下图所示:通过类似大数据流编程的手段对事件进行过滤分析。

其可视化效果和流量分析方法可供蚂蚁Kubernetes平台借鉴。

中间件在auto faster中的网格实践

在本主题中，自动快手的江涛主要讲解了服务网格技术在自动快手中的实践。

姜服网分为三代。其实划分的标准有很多，都有道理。显然，江把Dapr归入了第三代。

上图是Aauto faster的服务网状架构图，明显借鉴了Dapr的思路:将基础组件的能力下沉到数据平面，将请求协议和接口标准化。一些具体工作如下:

统一运维，提高可观测性和稳定性，故障注入和流量记录等。特使的二次开发等。，只传输变化的数据，按需获取，解决了单实例服务太多的问题；协议栈和序列化协议都得到了极大的优化。为了实现面向故障的设计，服务网格可以采用回退作为直接连接方式。

就个人兴趣而言，蒋提到了服务网格技术在更快落地汽车时面临的三大挑战:

成本:复杂环境下的统一部署和运维。复杂:规模大，性能要求高，策略复杂。落地:业务需求不强。

尤其是第三个挑战，Service Mesh的直接受益者不是业务方，而是基础设施团队，所以对业务没有很强的需求。而且像Aauto Quicker这样的实时业务平台对性能非常敏感，服务Mesh技术必然导致延迟的增加。

为了推动服务网格技术的落地，Aauto Quicker的解决方案有:

首先，保证系统的稳定性，不要急于分散业务量；搭乘公司重大项目顺风车，积极参与业务结构升级；基于WASM的可扩展性，与业务一起构建；选择典型落地场景，设立标杆项目。

最后，姜对易车下半年的服务网络工作提出了更快的要求:

显然，这条路线也深受Dapr的影响。它在理论或架构上没有创新，更专注于标准化开源产品，并更快地在Aauto中落地。

姜在演讲中提到了服务网格技术的两个标杆:蚂蚁集团和。其实他们成功的一个重要原因就是高层对先进技术的重视和业务方的大力配合。

Dubogo 3.0:云原生时代Dubogo的基石

作为本课题的主讲人，我在演讲中并没有过多强调Dubbo 3.0的现有特性，而是重点介绍了服务Mesh和灵活服务的形式。

Dubbo 3.0是最重要的一点，就是无代理服务Mesh。这个概念其实就是gRPC的由来，也是最近gRPC生态推广的重点。其优点是性能无损，微服务升级方便。但是gRPC本身的多语言生态是非常丰富的，而gRPC提倡这个概念的另一个原因是，作为一个强调稳定性的温和框架，它的性能并不是很好，如果考虑代理服务Mesh，它的性能就更令人担忧了。

Dubbo生态最大的缺点就是除了Java和Go，其他多语言能力都不太好。个人认为学习gRPC，完全屏蔽其他语言能力，并不是一个好主意。Dubbo-go-pixiu项目由Dubbogo社区出品，以gateway和sidecar两种形式解决了Dubbo生态的多语言能力，将南北交通和东西交通统一为pixiu。

无论是什么样的服务网格技术，在中国的发展都已经过了第一波高潮，从蚂蚁集团和字节跳动两个标杆开始，就已经走向稀疏状态。它仍然需要不断进化，与业务更加紧密地结合，让中小厂商看到它的商业价值，这将迎来其后续的第二波浪潮。

Mesh本身特别适合帮助中小厂商将服务迁移到K8s的混合云或多云环境。这些环境大多使用大量开源软件系统，可以帮助他们摆脱对特定云厂商的依赖。

Dubbo 3.0的灵活服务基本可以理解为反压技术。Dubbo和Dubbogo之所以要做弹性服务，是因为在云原生时代，节点异常是常态，对服务能力的准确评估是不准确的:

机器规格:大规模服役下，机器规格不可避免的存在异质性【比如受超售影响】，即使是相同规格的机器，老化速度也不一样；复杂的服务拓扑:分布式服务拓扑是不断发展的；服务流量不平衡:有高峰，也有低谷；上游服务能力的不确定性:缓存/数据库能力实时变化。

解决方案在于:服务器端自适应限流，服务调用端[客户端]自适应负载均衡。

自适应限流的基本思想是基于排队论对利特尔定律的改进:queue_size = limit *。每个字段的含义如下:

在一段时间内限制qps的上限。Rt_noload时间窗口中Rt的最小值。rt是一段时间内的平均RT，也可以直接取P50 RT。

也就是说，两种形式的RT用于评估方法级服务的适当性能。RT增加反映整体负载{ CPU/内存/网络/goroutine}增加，性能会下降。相反，RT的降低反映了服务器可以处理更多的请求。

自适应限流:服务器在方法级计算queue_size，同时计算当前方法正在使用的goroutine的数量[假设处理一个客户端请求需要一个go routine]。服务器知道在每次接收到某个方法的新请求时实时计算queue_size。如果inflight > queue_size，则当前请求被拒绝，queue_size-inflight的差值通过响应包反馈给客户端。

自适应负载均衡:客户端通过心跳包或响应接收服务器返回的某个方法的load queue_size-inflight，可以使用基于权重的负载均衡算法调用服务。当然，也可以提供P2C算法来避免羊群效应造成的服务节点瞬间压力，可以实现杜博戈供用户选择。以上全部内容仍在社区讨论中，并非最终实现版本。

摘要

从2017年到现在，个人参加了十几场大大小小的国内各种级别的技术会议，既是制作人又是讲师。演讲水平不高，但是基本的时间控制能力还可以，这样就耽误不了。这次主持GIAC的云原生突围，观众对这个专场的评分是9.65【所有专场的横向评分】，整体表现尚可。

我有幸生活在这个时代，见证了云原生技术的沉浮。我也有幸在阿里的平台上工作，见证了Dubbogo 3.0的各种场景在阿里云钉钉内部的逐步落地。

作者|鱼雨

原文链接:http://click.aliyun.com/m/1000294268/

本文为阿里云原创内容，未经允许不得转载。