始于阿里,回归社区|阿里巴巴的开源之路
摘要: 破土而出的生命力,源自理想主义者心底对技术的信念。 开源曾经帮助 Redhat 在传统软件市场奠定了其行业地位。无独有偶,作为云计算时代的赶超者,谷歌也拿起了开源的武器,试图打乱 AWS 和 Azure 的节奏。
破土而出的生命力,源自理想主义者心底对技术的信念。
开源曾经帮助 Redhat 在传统软件市场奠定了其行业地位。无独有偶,作为云计算时代的赶超者,谷歌也拿起了开源的武器,试图打乱 AWS 和 Azure 的节奏。
目前,这一策略似乎正在奏效。
如今云原生技术正席卷全球,云原生基金会在去年 KubeCon +CloudNativeCon NA 的现场宣布:
其正在孵化的项目已达 14 个,入驻的厂家或产品已超过 300 家,并吸引了 2.2 万开发者参与项目代码贡献,其明星产品 Kubenetes 的 GitHub 上 Authors 和 Issues 量已排行开源领域的第二名。而 Kubenetes 正是 Google 开源的一个容器编排引擎。
今年,KubeCon + CloudNativeCon 首次来到中国。
在2018 KubeCon + CloudNativeCon的现场,阿里云研究员伯瑜向在场的开发者们宣布,CNCF 已将阿里巴巴云原生镜像分发系统 Dragonfly 接纳为其沙箱项目(Sandbox),并有机会成为国内首个从 CNCF 毕业的开源项目。目前已经毕业的两个项目,一个是 Kubernetes,另一个是 Prometheus。
据悉,目前阿里巴巴已经有 8 个项目进入 CNCF 云原生全景图,分别是分布式服务治理框架 Dubbo、分布式消息引擎 RocketMQ、流量控制组件Sentinel、企业级富容器技术 PouchContainer、服务发现和管理 Nacos、分布式消息标准 OpenMessaging、云原生镜像分发系统 Dragonfly 和高可用服务 AHAS。
时间回到 2016 年。
2016 年的那届双11,RocketMQ 创始人冯嘉和他的团队首次将低延迟存储解决方案应用于双11的支撑,经受住了流量的大考,整个大促期间,99.996%的延迟落在了 10ms 以内,完成了保障交易稳定的既定目标。
对于读写比例几乎均衡的分布式消息引擎来说,这一技术上的突破,即便是放在全球范围内,也绝对是值得称赞的。
另一边,在历时3个月的开源重塑后,冯嘉和他的团队启动了 RocketMQ 向Apache 软件基金会的捐赠之路,但迈出这一步并不容易。
“当时国内的开源氛围还没有现在那么活跃,开源之后,很多设计、源码和文档的维护工作还不够理想,但我们就是想证明国内的开源项目和开源社区也可以在世界的开源舞台上发挥价值。”
经过近一年的努力,在2017年9月25日,Apache 软件基金会官方宣布,阿里巴巴捐赠给 Apache 社区的开源项目 RocketMQ 从 Apache 社区正式毕业,成为 Apache 顶级项目(TLP),这是国内首个非 Hadoop 生态体系的Apache 社区顶级项目。
值得一提的是,根据项目毕业前的统计,RocketMQ 有百分八十的新特性与生态集成来自于社区的贡献。
2017 年,消息领域出现一件里程碑事件。
分布式消息领域的国际标准 OpenMessaging 开源项目正式入驻 Linux 基金会,这是国内首个在全球范围发起的分布式计算领域的国际标准。
消息通讯已经成为现代数据驱动架构的关键环节,但在全球范围内,消息领域仍然存在两大问题:
一是缺乏供应商中立的行业标准,导致各种消息中间件的高复杂性和不兼容性,相应地造成了公司的产品低效、混乱和供应商锁定等问题。
二是目前已有的方案框架并不能很好地适配云架构,即非云原生架构,因此无法有效地对大数据、流计算和物联网等新兴业务需求提供技术支持。
这也是冯嘉和他的团队在开源 RocketMQ 过程中,开发者和合作伙伴经常会提到的问题:“在消息领域,市场上出现了各类不同的开源解决方案,这导致了用户更高的接入和维护成本,为了确保各个消息引擎间能正常通信,还要投入大量的精力去做兼容。”
这时候,建立一套供应商中立,和语言无关的消息领域的事实标准,成为各社区成员共同的诉求。
此后,在 2017 年 9 月,阿里巴巴发起 OpenMessaging 项目,并邀请了雅虎、滴滴出行、Streamlio共同参与,一年后,参与 OpenMessaging 开源标准社区的企业达10家之多,包括阿里巴巴、Datapipeline、滴滴出行、浩鲸科技、京东商城、青云 QingCloud、Streamlio、微众银行、Yahoo、中国移动苏州研发中心(按首字母排序),此外,还获得了 RocketMQ、RabbitMQ 和 Pulsar 3 个顶级消息开源厂商的支持。
相比于开源一个分布式消息项目,一套开源标准能被各家厂商所接受,对整个国内开源领域而言,是更具有里程碑意义的事件。
2017 年 9 月,Dubbo 重启开源。
Dubbo 是阿里巴巴于 2012 年开源的分布式服务治理框架,是国内影响力最大、使用最广泛的开源服务框架之一,在 2016 年、2017 年开源中国发起的最受欢迎的中国开源软件评选中,连续两年进入 Top10 名单。2017 年 9 月 7 日,在 Github 将版本更新至 2.5.4,重点升级所依赖的 JDK 及其组件,随后连续发布了 11 个版本。
并于2018年2月捐献给 Apache 软件基金会,希望借助社区的力量来发展 Dubbo,打消大家对于 Dubbo 未来的顾虑。
项目重启半年后,Dubbo 项目负责人阿里巴巴高级技术专家北纬在接受媒体采访的时候,从战略、社区、生态和回馈四个方面谈了 Dubbo 重启开源背后的原因。
“集团近几年开始将开源提到了新的战略高度,这次投入资源重启开源,核心是希望让开源发挥更大的社会价值,并和广大开发者一起,建立一个繁荣的Dubbo 生态,普惠所有使用 Dubbo 的人和 Dubbo 本身。”
Dubbo项目组成员朱勇在今年上海的技术沙龙上分享Dubbo未来发展的过程中提到,其后续的规划是要解决好两个问题。
第一个问题是重点关注技术趋势,例如云原生对Dubbo开源现状的影响。
第二个问题是 Dubbo 本身定位的问题,除了保持技术上的领先性,还需要围绕 Dubbo 核心发展生态,和社区成员一起将 Dubbo 发展成一个服务化改造的整体解决方案。
2017 年 11 月,阿里自研容器技术 PouchContainer 开源。
在开源不到一年的时间里,PouchContainer 1.0 GA 版本发布,达到可生产级别。今年 8 月,PouchContainer 被纳入开源社区开放容器计划 OCI;9 月,被收录进高校教材《云计算导论》;11 月,PouchContainer 团队携蚂蚁金服容器团队、阿里云 ACS 团队,与容器生态 Containerd 社区 Maintainer进行技术交流,有望发展成 Containerd 社区 Maintainer 席位,代表国内企业在世界容器技术领域发声。
PouchContainer 发展速度之快,超出了宏亮的想象。
宏亮是 Docker Swarm 容器集群项目的核心代码维护者(Maintainer),并于2015 年 8 月出版了《Docker 源码分析》一书,对 Docker 架构和源代码进行了深入的讲解,该书在 Docker 领域迅速成为畅销书籍。2017 年,宏亮承担起阿里自有容器技术的对内支持和对外技术布道的工作,秉承初心,希望在竞争激烈的容器开源领域能抢下属于国内容器技术的一席之地。
在团队的努力下,阿里集团内部已实现 100%的容器化,并已经开始涉及离线业务,实现在、离线业务的混合调度与部署。
整个集团能实现 100%的容器化,离不开阿里内部自研的 P2P 分发技术,该项目取名为 Dragonfly,寓意点与点之间的文件分发能如蜻蜓般轻盈和迅速,解决传统文件发布系统中的大规模下载、远距离传输、带宽成本和安全传输的问题。
日前,Dragonfly 正式进入 CNCF, 并成为国内第三个被列为沙箱级别(Sandbox Level Project)的开源项目,可见,CNCF 在其云原生的技术版图中正希望借助Dragonfly等优秀的镜像分发技术,以提升企业微服务架构下应用的交付效率。
始于阿里,回归社区。
今年夏天,国内开源领域,迎来了两位新成员。
作为微服务和云原生生态下的两款重要开源框架/组件,Nacos主打云原生应用中的动态服务发现、配置和服务管理,Sentinel 则是聚焦在限流和降级两个方面。
Nacos 和 Sentinel 均是在阿里近 10 年的核心业务场景下沉淀所产生的,他们的开源是对微服务和元原生领域开源技术方案的有效补充,同时也非常强调融入开源生态,除了兼容 Dubbo和Sentinel,也支持对Spring Cloud 和 Kubenetes 等生态,以增强自身的生命力。
“阿里巴巴早在 2007 年进行从 IOE 集中式应用架构升级为互联网分布式服务化架构的时候,就意识到在分布式环境中,诸如分布式服务治理,数据源容灾切换、异地多活、预案和限流规则等场景下的配置变更难题,因为在一个大型的分布式系统中,你没有办法把整个分布式系统停下来,去做一个软件、硬件或者系统的升级。”阿里巴巴高级技术专家坤宇在 2017 QCon 的现场分享到。
在配置变更领域,我们从2008年的无 ConfigServer 时代,借用硬件负载设备 F5 提供的 VIP 功能,通过域名方式来实现服务提供方和调用方之间的通信,逐步经历了 ConfigServer 单机版、集群版的多次迭代,不断提高其稳定性。
曾写下支付宝钱包服务端第一行代码的阿里高级技术专家慕义,在今年深圳的技术沙龙现场回忆了阿里注册中心自研的 10 年路:
“这期间,集团业务经历了跨越式的发展,每年翻番的服务规模,不断的给 ConfigServer 的技术架构演进带来更高的要求和挑战,使得我们有更多的机会在生产环境发现和解决一个个问题的过程中,实现架构的一代代升级。Nacos 便是在这样的背景下,经过几代技术人的技术攻坚所产生的。”
我们希望 Nacos 可以帮助开发者获得有别于原生或其他第三方服务发现和动态配置管理解决方案所提供的能力,满足开发者们在微服务落地过程当中对工业级注册中心的诉求,缩短想法到实现的路径。
巧的是,一边是 Nacos宣布开源,另一边是 Spring Cloud 生态下的服务注册和发现组件 Netflix Eureka 宣布闭源,勇敢者的游戏充满了变数,但在坤宇和他的团队看来,这场游戏自己可以走到最后,因为我们并不是一个人在战斗,Nacos 只是阿里众多开源项目中的一员,随后还会有更多的开源项目反哺给社区,形成生态,例如轻量级限流降级组件 Sentinel。
7月29日,Aliware Open Source•深圳站现场,只能容纳 400 人的场地,来了 700 多位开发者。阿里巴巴高级技术专家子矜在现场宣布了轻量级限流降级组件 Sentinel 的开源。
作为阿里巴巴“大中台、小前台”架构中的基础模块,Sentinel 经历了 10 年双 11 的考验覆盖了阿里的所有核心场景,也因此积累了大量的流量归整场景以及生产实践。
Sentinel 的出现,离不开阿里历届高可用架构团队的共同努力。
“在双11备战中,容量规划是最重要也是最具挑战的环节之一。从第一年开始,双11的 0 点时刻就代表了我们的历史最高业务访问量,它通常是日常流量的几十倍甚至上百倍。
因此,如何让一个技术和业务持续复杂的分布式站点去更平稳支撑好这突如其来的流量冲击,是我们这 10 年来一直在解的题。”阿里巴巴高可用架构团队资深技术专家游骥在今年的双11结束后分享道。
这 10 年,容量规划经历了人工估算、线下压测、线上压测、全链路压测、全链路压测和隔离环境、弹性伸缩相结合的 5 个阶段。2013 年双11结束后,全链路压测的诞生解决了容量的确定性问题。
__作为一项划时代的技术,__全链路压测的实现,对整个集团而言,都是一件里程碑事件。
随后,基于全链路压测为核心,打造了一系列容量规划相关的配套生态,提升能力的同时,降低了整个环节的成本、提升效率。随着容量规划技术的不断演进,2018 年起,高可用架构团队希望可以把这些年在生成环境下的实践,贡献给社区,之后便有了 Sentinel 的开源。
一边是作为发起者。
将自己生产环境实践下沉淀出来的架构和技术贡献给社区。
另一边是作为参与者。
基于一些开源项目或云平台,输出可以解决开发者当前工作中存在的痛点的解决方案,例如近期新开源的项目 Spring Cloud Alibaba 和 开发者工具 Alibaba Cloud Toolkit。
相同的是,技术理想主义者都希望技术可以为让世界变得更好,这才是技术人的兴奋点。
“让世界的技术因为阿里巴巴而变得更美好一点点”。
这是阿里巴巴系统软件、中间件、研发效能事业部负责人毕玄邮件签名中的一句话。他正和一群技术理想主义者,与太平洋另一边的技术高手们正面PK,在这场躲不开的战役中,一起认真一把。
作者:amber涂南