头图.png

作者 | 禾易

在第十五届“开源中国开源世界”高峰论坛上，阿里云资深技术专家、etcd 创始人、CNCF TOC 李响荣获 2020 中国开源杰出人物贡献奖。恭喜李响！

去年，全球顶级开源社区云原生计算基金会 CNCF 正式宣布其技术监督委员会席位改选结果。阿里云资深技术专家李响入选，成为该委员会有史以来首张中国面孔。

李响是 CoreOS 最早期的工程师之一，参与创建了 etcd、operator framework、rkt 等开源项目。而在开源社区中，李响作为 etcd 作者被开发者所熟知，etcd 是国际知名且被最为广泛使用的分布式一致性存储系统，被阿里巴巴、腾讯、华为、腾讯、微软、谷歌、VMWare 等企业在生产环境和客户产品中使用，用来解决分布式系统中重要元信息存储、管理和备份的问题，以及分布式系统组件一致性协调的问题。

在加入阿里云后，李响一直在推动云原生领域自动化运维相关理念、Operator 概念、OAM 标准的建立。Operator 给予开发和运维人员在云原生平台构建无状态和复杂应用运维的理论标准和实践基础，大幅度提高了云原生运维平台的覆盖度，在开源生态中涌现出了超过 500 个 Operator 具体实现，覆盖了几乎所有的主流云原生软件的运维，其中包含 RocketMQ、Kafka、ZooKeeper、Consul、Argo、Kubeflow 等。这些理念深度影响了云原生领域的发展。

在第十五届“开源中国开源世界”高峰论坛上，阿里云资深技术专家、etcd 创始人、CNCF TOC 李响荣获 2020 中国开源杰出人物贡献奖。

对于国内外开源的进展以及云原生实践的发展，我们找李响聊了聊他的看法。

开源，从“使用”到“融入”

开源在近些年的热度一直居高不下。所谓开源，就是将软件的源代码公开，允许所社区成员对其进行修正、改进和创新，并将其成果与社区内的所有成员共享。除了开发者以个人的身份参与开源之外，企业也在加大力度参与开源软件的研发。

李响提到，开源的融入应该是一个循环：使用 - 发现问题/做了新功能 - 提交代码给项目 - 更多人用。

目前国内开源的发展更多停留在使用阶段，在合适的场景使用开源技术来解决一些业务问题。一个比较好的趋势是，国内对于开源技术的认可度逐渐提高，参与开源的企业和开发者也逐年增加。阿里巴巴也在积极推动一些先进的开源理念的落地，比如云原生。李响提到，如果国内一些思想前卫的开发者愿意花时间与精力去实践云原生，并不断与国外的技术思想去碰撞，那么我们就能够对云原生社区的发展产生一些影响力，从而有资格来引领云原生技术的发展方向。“其实中国的开发者完全有能力参与到开源项目的进程中，并且去影响开源项目。”

还有一种趋势是，国内一些基于开源技术去构建技术体系的厂商越来越多。这些厂商不单单是像以前一样售卖开源技术，而是自己构建或者尝试去构建开源生态，并在国内和国外去推广。以前在 OpenStack 刚出来的时候，有很多厂商基于 OpenStack 这项技术进行包装、集成、售卖。国内一些 to B 的厂商也采用了相似的思路，比如发展较好的 PingCAP。此外，一些初创公司也有意识地去打造开源技术并推广开源技术，这也是国内对于开源态度的一个转变。

当然，国内开源的发展还有一些需要提升的地方。李响提到，一方面，国内的开发者应该更积极地参与到整个开源社区的建设中，不仅仅是技术建设，有时候思想碰撞也很重要。我们要做的不仅是给开源项目提一些短期的问题，或者帮助开源项目修复Bug，而是要为更长线的工作做准备。只有融入到社区中，才能给到社区更具体明确的需求，帮助开源社区的发展，甚至影响开源社区的未来方向。

对于参与开源的企业而言，不论是创业公司，还是云厂商，能够从 0 到 1 去做一些开源项目，并尝试去做一些创新性的、先进性的项目，把国内在开源社区和先进生产力上的影响力发扬光大，甚至去打造一些国际知名的开源品牌，才能真正融入到开源的发展进程中。

当然，开源的世界里也有一套自己的玩法。

关于开源治理

前段时间，谷歌将Istio项目商标的所有权正式移交至 Open Usage Commons（OUC）。接受 Istio 后，OUC 将与项目指导委员会共同制定商标使用指南，方便社区统一使用 Istio 项目商标。此举引发了业界激烈的讨论，作为 CNCF TOC，李响谈了谈他对于开源治理的一些看法。

开源可以从三个部分来理解，第一部分是代码的开放，就是让大家可以看到并且修改代码。这是任何一个开源项目要做的最基础的事情。第二部分是开源工作中涉及的品牌和专利，把这部分工作开放，让品牌从属于一个中立的组织，这样其他厂商或者用户使用的时候，不会受到专利的限制，也没有品牌的担忧。

第三部分是治理模型的开放，治理模型的开放意味着每一个项目都有一个治理组织，对开源项目做出一定贡献或者达到某种标准，就被允许加入到治理组织中，对开源项目的未来发展拥有一定的话语权和决策权。举个例子，阿里巴巴今天开源了一个项目 X ，最开始参与投票的 5 个人都来自于阿里巴巴，假设有一天阿里巴巴的贡献减少了， B 公司的贡献增加了，那么 B 公司就有权利去推动这个开源项目的治理，进而控制它的走向。比如 Redis 项目近期放弃之前的专制管理模式，转而采用新的“社区自治模式”。这意味着 Redis 项目的未来命运将由整个社区决定，而不再单纯掌握在 Sanfilippo（Redis 之父）一个人手中。

谷歌把品牌和专利移交给 OUC ，让品牌从属于一个中立的组织，就意味着在开放代码的基础之上，将代码相关的品牌和专利变成中立了，这样每一个参与项目的人都可以来使用 Istio 的品牌，人人平等。

从开源项目的使用者来看，我们肯定希望开源的项目可以做到上面所说的三部分（代码、品牌、治理模型）都能够开放，从长期来看，这是对用户最有利的局面，这样开源项目就可以按照社区的需求导向来发展，而不是按照参与的某一家公司的意向来发展。

但是谷歌并没有把治理模型开放出来，一是因为 Istio 项目还处于发展早期阶段，如果开放治理模型，会导致很多人参与到 Istio 早期进程中，分裂的话语权对于一个早期尚不成熟的项目而言是不利的。从商业化的角度来看，如果谷歌拥有对于开源项目的治理权利，那么，对于该项目的未来走向是有一定的把控能力，这对于谷歌未来布局产品线有一定的先发优势，这也是谷歌没有开放治理模型的一层考虑。

Istio 之所以成为“香饽饽”，因为它是目前 Service Mesh 社区最引人注目的开源项目，而 Service Mesh 也是当下云原生领域最被看好的发展趋势。

云原生：企业的顾虑与不可抵挡的行业趋势

近年来，云原生的理念越来越受到业界的重视，李响作为云原生领域的创新者，也在推动国内云原生的技术布道，包括深度参与阿里云原生架构白皮书的撰写、参与设计云原生实践课程等。云原生理念对于国内企业而言，还处于一个早期发展的阶段，无论是技术、产品、标准等，都还处于快速迭代的过程中。企业在应用云原生的技术和产品时，难免有所顾虑。

Q：国内和国外在云原生领域的发展，有多大的差距？

李响：总体来看，国内外云原生技术理念的发展没有太大的差距。但是由于云原生理念的兴起是在北美，所以社区生态的发展中心还是在硅谷这里，一些新的技术理念或者架构应用、创新场景等，也是需要一些时间才能慢慢引入到国内。

区别比较大的是国内企业跟国外企业对于云服务的接受度。我们提到云，最先想到的一定是节约资源、弹性、成本降低、技术红利这些大家关心的点。北美企业的人力成本普遍较高，所以他们会愿意为云上的软件服务付费，尽可能节约人力成本。国内很多企业不缺少研发人员，整体研发能力也很强，在云服务提供附加值有限的情况下，很多企业会自己研发一些定制化的能力。

阿里是国内较早开始践行云原生理念的公司之一，通过在内部实践成熟之后，开始对外输出去影响更多的企业。我们非常看重如何通过云原生为企业带来更多的附加值，并且这个附加值一定要超过企业自己定制开发带来的价值，只有这样，企业才会愿意拥抱云原生。未来阿里也会研发出一些更有竞争力的产品，提供更具价值的服务，并去影响海外的用户，让国内的云原生发展与国际接轨。

Q：云上的服务未来会以什么样的形态存在？

李响：未来的云一定不是资源，对于云厂商而言，重心不是售卖这些基础的资源，而是在云上建立一个服务体系和生态，让企业更便捷和方便地使用云上的服务。随着云服务规模化的发展，一个云服务可以交付给很多用户，由于边际效应，每个云服务的成本会大幅降低，对于企业而言更划算。但这对于阿里云而言也提出了一个挑战，如何把云服务更好地规模化，让每个服务更精细也更通用化，从而帮助企业解决更多常见的问题。

Q：选用云原生技术时，企业对云原生技术栈进行大规模应用时的安全性、可靠性、性能、连续性存在疑虑。这个问题如何解决？

李响：对于云原生有顾虑其实可以理解，毕竟云原生还处于早期发展的阶段。阿里云在帮助国内企业了解云原生、使用云原生上做了很多工作。对于云原生技术栈的可靠性、性能、连续性这方面的顾虑，我们从两个方面来解决。一方面是在内部尝试去使用这些技术，阿里巴巴内部有非常丰富的、大规模的使用场景，通过这些场景可以打磨云原生技术。在技术成熟以后，我们将这些技术回馈到社区，帮助云原生社区提高技术质量和发展水平。

另一方面，阿里云上提供了丰富的云原生产品服务、云原生产品家族。以前一家企业想使用云原生的技术或产品，需要花费大量的精力研究一些开源项目，自己做运维和管理，还需要考虑集成、稳定性保障等问题，这样才能建立一个云原生平台。今天，为了方便企业和开发者更容易地使用云原生的技术和产品，更好地接受云原生的理念，并解决企业担忧的可靠性、性能、连续性等问题，阿里云为大家提供了一整套云原生产品家族，提供了非常强的SLA保障。

另外，关于云原生的安全性问题，2019 年，阿里云安全沙箱技术商用上线，支持 ECI、ACK、SAE 边缘计算等多种业务。蚂蚁金服收购了 Hyper ，共同打造安全可靠的容器运行环境。阿里云安全沙箱是基于 MicroVM 构建的安全容器 Runtime。首先它是一个基于硬件虚拟化技术的 MicroVM ，采用了深度定制优化 hypervisor ，极简的虚拟机设备模型。其次阿里云安全沙箱也是一个容器 Runtime，提供镜像分发、镜像管理、容器网络、容器存储，完全兼容 OCI 和 CRI 规范。此外基于软硬一体设计的机密计算容器开始展露头角，阿里云和蚂蚁团队共同推出了面向机密计算场景的开源容器运行时技术栈 inclavare-containers 。它基于Intel SGX等机密计算技术，支持蚂蚁的 Occlum ，开源社区的 Graphene Libary OS ，极大降低了机密计算应用的开发、交付和管理。

Q：越来越多的厂商开始探索 OAM 落地实践， OAM 有什么魅力？

李响：OAM（开放应用模型）是一套由阿里云和微软共同发起、由云原生社区共同维护的应用描述规范（spec）。OAM 的核心理念是：“以应用为中心”，它强调研发和运维围绕着一组声明式的、灵活可扩展的上层抽象进行协作，而不是直接去使用复杂晦涩的基础设施层 API。

在 OAM 规范下，研发和运维的关注点是完全分离开的。研发与运维只需要编写非常少量的、跟自己相关的一些字段，而不是完整的 K8s Deployment 和 HPA 对象，就可以轻松的定义和发布应用。这就是“上层抽象”为我们带来的好处。

目前，阿里云 EDAS 服务已经成为了业界第一款基于 OAM 构建的生产级应用管理平台，并很快推出下一代“以应用为中心”的产品体验；在 CNCF 社区，知名的跨云应用管理与交付平台 Crossplane 项目也已经成为了 OAM 规范的重要采纳者和维护者。

实际上，不止 AWS Fargate，我们云计算生态里的所有 Serverless 服务都可以很容易的使用 OAM 来作为面向开发者的表现层和应用定义，从而实现对原本复杂的基础设施 API 进行简化和抽象，将原本复杂的流程化操作“一键”升级为 Kubernetes 风格的声明式应用管理方式。

更重要的是，得益于 OAM 的高可扩展性，用户不仅可以在 Fargate 上部署容器应用，还可以用 OAM 来描述 Function、虚拟机、WebAssembly 乃至任何你能想到的工作负载类型，然后把它们轻松的部署在 Serverless 服务上，甚至在不同的云服务之间无缝迁移。

Q：未来，云原生会如何发展？

李响：我们一直希望云原生产品生态可以做到标准和开放。不同厂商之间的服务、基础设施等，都可以实现互通。用户开发的应用可以运行在阿里云容器之上，也可以运行在其他厂商的容器之上，应用所依赖的东西本质上都可以是一些开放的接口。这其实一直是阿里云在努力的方向，从云原生的发展角度，我们也在尽量做到标准开放，并且跟社区生态比较好的进行融合，从而减少用户的担忧。

阿里在云原生领域比较关注 4 个方面的发展：

一是对于 Kubernetes 和 Containerd 的贡献。阿里在内部进行了大规模的实践，在性能、规模性、效率上与上游进行共建。从整个生态来看，阿里是最早开始布局云原生的厂商之一，也在尝试扩大云原生覆盖的范围，做边界的拓展。阿里云推出开源项目 OpenYurt ，一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区，另一方面也希望加速云计算向边缘延伸的进程，并和社区共同探讨未来云原生边缘计算架构的统一标准。

二是在微服务体系中，阿里有比较深厚的积累，同时也做了很多开源方面的工作。通过一些开源项目，比如 Dubbo、Nacos 等，把阿里微服务体系中的经验和实践向外输出。另外，阿里也在把微服务体系、开源体系的技术与云进行整合，这样使用云的客户就能更方便地直接使用开源的产品。

三是推进微服务体系向下一代去演进。尤其在云原生领域，大家比较看好Service Mesh 的发展，阿里也在推动微服务体系与Service Mesh 融合，实现更好的兼容性和互通性，进而提高Service Mesh 整个生态的活跃度和成熟度。同时，我们也在让一些开源项目和云产品变得更加云原生化或者说更加适合云的应用场景，比如消息系统 RocketMQ，我们正在提高RocketMQ开源软件自身的弹性和进行 Serverless 化，从而降低使用成本，并且在云上更容易部署。

四是尝试一些创新的、先进性的云原生探索。比如 OAM 开放应用模型的 Kubernetes 标准实现 Crossplane 项目，在同 OAM 社区进行深度合作之后，今天的 Crossplane 是一个面向混合云场景的应用与云服务管理控制平面，它致力于基于 K8s 声明式 API，遵循开放应用模型标准对应用进行管理与交付，并通过独有的机制对云服务以云平台无关的、最终用户友好的方式进行抽象与管理。

Crossplane 项目进入 CNCF Sandbox 也意味着，从今天开始 OAM Kubernetes 标准实现的所有代码、文档和整个 Crossplane 项目本身的所有权，都将转交给 CNCF 社区进行托管，与该项目背后的任何商业公司（无论是阿里云还是微软云）完成解耦。