IT老炮儿与开源,不得不说的故事|线上分享
小欧有话说:
为了加深EGO会员之间的相互了解,同时也为更多的技术人提供相互学习交流的机会,EGO开展了每周四21:00的线上分享活动。本文根据钟忻7月21日线上分享内容整理而成。看看在开源项目开发方面有丰富经验的他,有什么特别干货分享给大家吧!
钟忻:EGO会员,新中新集团首席专家及云技术负责人,目前负责集团的云化转型,打造围绕校园支付的智慧校园应用,在开源项目开发方面有丰富的经验。
1
个人开源经历
回顾自己的职业生涯,我惊讶的发现自己跟开源有着不可思议的缘分。首先,自己的开发工作一直都是基于Linux,例如硕士毕业后加入Linux发行版公司Turbolinux,在里面主要是负责Linux发行版的维护和HA软件的开发。2005年加入IBM,我所做的开发工作也都是基于Linux,当时我们开发的软件都要在x86、power以及zLinux上面测试,单元测试的工作量非常繁重,由于都是系统软件,在不同的体系架构上面还真会踩到一些坑。
除此之外,我对Hadoop、Ceph等项目也做过比较深入的研究,也给一些项目比如Btrfs贡献过一些Critical Fix。在2013年底加入乐视云计算之后,组建了乐视云平台团队,我们团队维护了很多的开源组件,对Openstack和Ceph开源社区的贡献一直居于国内前列。学生时期的偶像是Linus,最大的心愿就是能把自己的名字永远留在Linux内核里面。加入互联网公司以后,经常看到大家对于选用什么开源组件有各种各样的探讨,希望自己的总结能给大家一些启发,有些见解可能更多的是个人感受,请多指正。
2
从开放性与封闭性看开源项目的成功
首先上一张表格,后面进行展开,以个人亲历过得开源项目为参考,希望从中总结出开源项目成功的一些共性。对于开源社区的维护,代码的管理,文化的培养,这些方面的论述文章已经很多了,我这里更多的是从其他的一些维度来进行展开。
我认为一个开源项目的成功应该是封闭性与开放性的结合,缺一不可。太开放会导致项目主导权的丧失,盘子铺的太大,没法收敛和聚焦,稳定性和成熟度欠佳。太封闭会导致参与度的降低,不能吸纳众家之长,创新和推广都会受阻。
其中封闭性主要体现在技术成熟度和核心算法。技术成熟度是指有一些可参考的商业化软件或成熟案例。开放性主要体现在开发语言、架构设计以及生态系统。开发语言最好是门槛比较低的语言,尤其是互联网公司比较流行的语言。架构设计需要考虑分层、模块化、插件化,这样有利于技术的开放以及吸纳外部的力量。基于开放的架构,加上项目负责人的眼光和推动力,可以构建出庞大的生态系统,有了生态系统,这个开源项目就很难被取代或淘汰。
2.1 开放性
开发语言:
这个很好理解,比如Hadoop很火,一个重要原因要归功于他用了Java。你不能说Doug Cutting当年深谋远虑,因为可能他个人只擅长Java,但如果有人拿着谷歌的三篇论文用C++实现一套系统,也许很多开发和运维人员就望而生畏了。有不少互联网公司早期的云存储系统,都是选用HDFS作为后端,也包括乐视,公司有一堆资深的Java程序员,做出这样的选择也是理所应当的。
另外,Openstack用到的python也是互联网后端尤其是运维的主流开发语言,很多人对象存储用Swift不用Ceph,多少也是因为python的门槛比较低。
架构设计:
Linux操作系统的核心虽然是宏内核设计,但是模块化可以对接众多厂商的驱动和协议栈。核心的进程调度、内存管理代码比较稳定,主要是一些非常资深的维护者在修改,但其实更多的大量源代码贡献都是来自驱动和协议栈。
Hadoop分层设计,HDFS、HBase、Hive以及MapReduce,虽然是参考了谷歌的论文,但事实上这样的分层设计,使得不同的层次上都可以做不同的系统和创新。比如基于HDFS再做一套NoSQL的数据库,或者做一个类似Spark的计算引擎去对接HBase,都是非常容易的事情。
Openstack的组件化和插件化设计,每一个组件可以通过API对接不同的开源和商业方案。Openstack就是一张皮,计算、存储、网络都是开放的。比如底层的存储可以是开源的LVM、Ceph,也可以是各种商业化的存储。你对他的Neutron组件不满意,可以自己开发一套系统,只要对接它的API就可以,比如日本人开源的Midonet,基于BGP协议,也被很多人看好。大家对Openstack诟病比较多的就是摊子铺的太大,稳定性不够高,但正是因为这样的开放性才得到了众多厂商的追捧,能够力压CloudStack等众多优秀的IaaS项目,如今成为IaaS开源项目的首选。
Ceph的统一存储可以支持多种接口,也体现了架构的开放性。在Openstack块设备中的广泛被采用也使得大家对他的其他方面,比如对象存储也会更有信心,所谓东方不亮西方亮。
生态系统:
通过开发语言的低门槛,快速获得关注,开放的架构设计,吸纳众多利益方的参与,众人拾柴火焰高。另外创始人或者主导者的眼光和推动也非常重要,加上开源项目本身得天独厚的优势,生态系统就逐步的建立起来。
Linux的创始人Linus,跟Intel有着非常好的关系,他本人就住在Intel OTC的大本营Oregon,每年Intel内部的技术峰会他老人家都亲自来参加(话说我当年离职太早,错过了亲眼目睹偶像的机会,终身遗憾啊。。。)。正是有了Linus与Intel的密切合作,才有了今天Linux+x86的成功,已经成为了云端的标配。
再比如Ceph的推广,不得不提及Ceph的创始人Sage Weil,他对于Ceph项目的推广是不遗余力的,如果不积极的去对接很多外部的项目比如Openstack乃至Hadoop,单凭自己很难成功。
我在2012年接触Hadoop,那会它的代码跟商业软件比,可以说还是非常粗糙的,性能稳定性有很多优化的空间。但是开源的生态系统的生命力是非常惊人的,现在看整个Hadoop的技术堆栈已经非常完整了,应用也是越来越广泛。
低门槛、开放性、生态系统,诸多因素叠加在一起,才把一个个粗糙的屌丝级项目,打磨成可以媲美商业软件的高富帅。
2.2 封闭性
大家都知道,很多成功的开源项目都是起源于一篇学术论文,或者“山寨”一个成熟的商业项目。比如谷歌的三篇论文之于Hadoop,Sage Weil的博士论文之于Ceph,Btrfs也是起源于Chris Mason看到了IBM的一位研究人员的一篇Btree的论文,这才放弃了屡遭波折的reiserfs,另起炉灶。
开源项目的封闭性体现在两方面:架构成熟度和稳定的核心算法
对于开源项目来说,一方面要有前沿的架构和算法设计,符合技术的发展趋势,这样才有生存的基础。另外一方面,核心的架构和算法要相对稳定,因为开源社区鱼龙混杂,人员水平参差不齐,大多数人更多的是锦上添花,添加各种插件,反馈一些稳定性问题,以及fix一些minor issue,核心的架构和算法还是掌握在少数人手里,这是开源项目能够作为一个成熟产品的命脉所在。
Hadoop就不用多说了,有谷歌的三篇论文傍身,里面一些核心的架构比如HDFS的Namenode设计,都是比较简单和成熟的。Ceph,Ceph虽然能够对外提供不同的接口,但他的RADOS集群及其核心的CRUSH算法是比较稳定的,这也是它能够在Openstack社区大放异彩的原因。再比如Openstack,它的架构也是脱胎于Rackspace和NASA的项目。
3
成功项目的共性
综上所述,成功的开源项目大致有如下几条共性:
开放性:
开发语言的低门槛
开放的架构设计
良好的生态系统
封闭性:
可参考的成熟架构
稳定的核心算法
个人案例分享
下面对于我本人经历过得这些开源项目,再做一些展开。对于已经特别成熟的,比如Hadoop,也没有讨论的必要了。过于学术性的,比如Ceph的MDS、Btrfs,虽然我的深入研究是在11/12年,这几年只是做过一些简单的跟踪,但目前看仍然没有太大起色,可以借鉴他的算法和设计思想,做一些验证,在生产环境基本不推荐。从我本人的角度,这两个项目从一开始也许就是注定要失败。
Btrfs,我本人接触Btrfs是在Intel的Meego项目,是和诺基亚合作的开源手机操作系统,但是codebase还是基于Intel之前的mobilin,后来也是不欢而散,Intel又跟三星合作搞了Tizen项目,目前什么状态就不得而知了。当时Meego的首席架构师非常重视创新,所以在Meego里非常激进的采用了Btrfs作为根文件系统,也是业内第一个把Btrfs用到产品里面的案例,在内部也引起了不少争议。Btrfs跟Sun的ZFS很类似,也有IBM的论文作为基础,基于COW的设计,会有很多吸引人的特性,比如可以很方便的做快照,他的存储分配也特别适合flash设备。这些都跟手机有结合点,比如可以基于快照做到秒级的备份和恢复。因为手机上一般的存储都是基于flash,性能也会有一些优势。但是基于Btree的设计过于复杂,几乎所有的核心模块都有涉及,导致它迟迟不能稳定。当时国内一位核心贡献者在帮我review代码的时候吐槽说,这个项目的dark side太多了。
这方面Ceph的MDS跟Btrfs情况非常类似,过于学术化,技术门槛过高。当时我们9个人的团队分了三组,把所有的核心代码模块都做了细致的研究和文档化,然后从可扩展性、性能、以及故障恢复等方面对Ceph的文件系统(MDS)进行全面的测试和问题的修复。Ceph的并发性当时做的不好,基本是单线程的,所以也没有真正意义上的锁。当然这个是可以逐步提升的。而它的MDS的动态子树设计,虽然在学术上非常fancy,但是子树迁移以及负载均衡工程化的成本都很高。我记得我当时花了一个周末的时间,才找到一个子树迁移的bug,从此我就对这个架构绝望了。据我所知,国际上的存储大厂包括IBM、EMC以及国内的华为,也都没有把类似的方案真正实现到产品里面。假如是个商业项目,投入上百人的团队来做工程化也许是可行的,但以开源社区的人力投入很难让它达到生产级别。
对于Openstack和Ceph的Radosgw,之前的团队属于在国内应用还比较早的,也到了一定的规模。我们的Openstack集群,达到上千台规模,实现了跨地域管理。我们用Ceph替换了HDFS来对视频云存储进行后台重构,达到几十个PB的规模。对于Ceph,语言的门槛还是有的。所以正式选用Ceph,也是在招募了几位比较有经验的C++程序员以后,因为视频存储是我们比较核心的系统,有了代码级的维护能力,系统的稳定性才有保障。
虽然这两个都是有一定成熟度的项目,但还是踩了一些坑,总结下来,要遵循一些通用的原则:
维护人员要有代码级的修复能力,至少能够通过定位问题,从社区backport相关的patch回来。一般来说应用比较广泛的项目踩别人没踩过的坑的几率不大,定期做一些升级就能极大的提升系统的稳定性,预防风险。
提前做各种压力测试和破坏性测试,这个似乎不用多说,但实际的血泪史表明,还是由于进度压力,思想上的不重视,经常被忽略或者做的不到位。我们内部经历过的一次Openstack的严重故障,就是由于运维操作不当,加上压测不够导致的。
掌握监控和性能工具,迅速发现问题。我们之前研发了一套Ceph的监控,就很快的捕捉到了运维人员不小心改动参数引起的性能下降。还经历过个别硬盘性能突然下降,拖累整个系统,也能很快识别
在极端情况比如网络异常情况下要有应急预案,比如Ceph可以设置osd nodown,防止网络抖动造成系统做不必要的rebalance
尽量做减法,去掉不必要的组件、降低复杂度。比如我们的Openstack网络方案就没有采用L3 Agent,高可用依赖于物理路由器,这也是很多公司的做法。再比如我们第一个上线的Ceph系统连Radosgw都没用,直接用一个轻量级的http server对接后端的Rados KV系统。由于去掉了中间层,性能也有一定的提升。
小规模试用,逐步推广,灰度发布,有切换和回滚机制等等,这些都是老生常谈
个人感悟
回顾近16年的开源生涯,从传统IT企业、到创业公司,再到互联网公司,都能目睹开源为业务创造价值。无论IaaS、PaaS、SaaS,API经济,还是开源项目,都是社会分工,促进共享,避免重复造轮子的手段。如何在不同的阶段选取合适的技术,是摆在技术决策者面前的有趣的话题,希望本文能对大家在开源项目的选取和使用方面有所参考。
最后再说几句个人感受,记得从自己2000年开始接触Linux,开源社区每年都说,It’s the year of Linux Desktop,可惜直到现在这一天也没有到来。但是Linux以另外一种形式统治了我们的桌面,那就是Android。本人对安卓了解不多,不敢妄加评论,但我相信它背后的成功,也是封闭性与开放性折衷的结果。这是一个软件吞噬世界的时代,网格死了,云计算火了,Linux桌面死了,安卓火了,潮流的背后是工程师不断的努力,分享与开放,让技术生生不息。借用Linus当年的一本书名,Just for fun。开源是一种情怀,happy hacking!
本文系EGO原创首发,请获取授权转载