我们找阿里云资深技术专家李响聊了聊开源和云原生

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 在第十五届“开源中国开源世界”高峰论坛上,阿里云资深技术专家、etcd 创始人、CNCF TOC(Technical Oversight Committee,简称TOC)李响荣获2020中国开源杰出人物贡献奖。恭喜李响!

作者 | 禾易
来源 | 凌云时刻(微信号:linuxpk)


前言

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

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

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

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


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

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

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

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

还有一种趋势是,国内一些基于开源技术去构建技术体系的厂商越来越多。这些厂商不单单是像以前一样售卖开源技术,而是自己构建或者尝试去构建开源生态,并在国内或国外去推广。以前在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 社区进行托管,与该项目背后的任何商业公司(无论是阿里云还是微软云)完成解耦。

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
7天前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
6天前
|
运维 Kubernetes Cloud Native
云原生技术入门及实践
【10月更文挑战第39天】在数字化浪潮的推动下,云原生技术应运而生,它不仅仅是一种技术趋势,更是企业数字化转型的关键。本文将带你走进云原生的世界,从基础概念到实际操作,一步步揭示云原生的魅力和价值。通过实例分析,我们将深入探讨如何利用云原生技术提升业务灵活性、降低成本并加速创新。无论你是云原生技术的初学者还是希望深化理解的开发者,这篇文章都将为你提供宝贵的知识和启示。
|
7天前
|
Cloud Native 持续交付 云计算
云原生技术入门与实践
【10月更文挑战第37天】本文旨在为初学者提供云原生技术的基础知识和实践指南。我们将从云原生的概念出发,探讨其在现代软件开发中的重要性,并介绍相关的核心技术。通过实际的代码示例,我们展示了如何在云平台上部署和管理应用,以及如何利用云原生架构提高系统的可伸缩性、弹性和可靠性。无论你是云原生领域的新手,还是希望深化理解的开发者,这篇文章都将为你打开一扇通往云原生世界的大门。
|
5天前
|
弹性计算 Kubernetes Cloud Native
云原生技术的实践与思考
云原生技术的实践与思考
19 2
|
6天前
|
Kubernetes Cloud Native 持续交付
云原生技术在现代应用架构中的实践与思考
【10月更文挑战第38天】随着云计算的不断成熟和演进,云原生(Cloud-Native)已成为推动企业数字化转型的重要力量。本文从云原生的基本概念出发,深入探讨了其在现代应用架构中的实际应用,并结合代码示例,展示了云原生技术如何优化资源管理、提升系统弹性和加速开发流程。通过分析云原生的优势与面临的挑战,本文旨在为读者提供一份云原生转型的指南和启示。
20 3
|
5天前
|
边缘计算 Cloud Native 安全
云原生技术的未来发展趋势
云原生技术的未来发展趋势
18 1
|
6天前
|
运维 Kubernetes Cloud Native
云原生技术在现代应用架构中的实践与挑战####
本文深入探讨了云原生技术的核心概念、关键技术组件及其在实际项目中的应用案例,分析了企业在向云原生转型过程中面临的主要挑战及应对策略。不同于传统摘要的概述性质,本摘要强调通过具体实例揭示云原生技术如何促进应用的灵活性、可扩展性和高效运维,同时指出实践中需注意的技术债务、安全合规等问题,为读者提供一幅云原生技术实践的全景视图。 ####
|
6天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
17天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
9天前
|
消息中间件 存储 Cloud Native
云原生架构下的数据一致性挑战与应对策略####
本文探讨了在云原生环境中,面对微服务架构的广泛应用,数据一致性问题成为系统设计的核心挑战之一。通过分析云原生环境的特点,阐述了数据不一致性的常见场景及其对业务的影响,并深入讨论了解决这些问题的策略,包括采用分布式事务、事件驱动架构、补偿机制以及利用云平台提供的托管服务等。文章旨在为开发者提供一套系统性的解决方案框架,以应对在动态、分布式的云原生应用中保持数据一致性的复杂性。 ####

热门文章

最新文章