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原创首发，请获取授权转载