转载

余兴超谈企业开源软件的选型以及开源文化

前两天，InfoQ上有一篇关于开源如何影响数据库市场的报道。文中谈到，2014年，商业的关系型数据库仅增长了5.4个百分点，而开源数据库市场却增长了31%，可谓后劲十足。现在越来越多的企业在商业软件和开源软件之间都选择了开源。使用开源软件最明显的优势之一就是成本降低，比如我们使用开源的MySQL、PostgreSQL数据库根本不用花一分钱。但开源软件的使用门槛并不低，比如在使用之前企业需要做好调研工作，在使用过程中，企业需要知道如何与社区版本进行同步、互惠互利。UnitedStack是一家基于开源技术的商业公司，为了了解他们在开源软件方面的实践经验，我们采访了他们的技术负责人余兴超。

InfoQ：企业在使用开源软件是应该如何选型？自研和开源之间如何抉择？

余兴超：在2011年，我们决定开始做一个IaaS平台，当时考虑了OpenStack、CloudStack、Eucalyptus。

社区活跃度

名称	OpenStack	CloudStack	Eucalyptus
协议	Apache 2.0	Apache 2.0	GPL v3
成熟度	不成熟	较成熟	成熟
社区活跃度	非常活跃	较活跃	活跃
语言	Python	Java	Java

说实话，从上表的对比中，更应该去选择Eucalyptus。但是我们当时选中OpenStack是因为两点原因：一是其发展前景，二是技术栈和我们团队匹配。

当时Openstack社区只有Nova、Glance、Swift三个项目，Keystone认证服务人仍在孵化中，但在这个IaaS开源方案，在一开始就有众多巨头的积极参与，无论是在API设计，功能路线图，持续集成系统的改进，代码提交的规范，软件缺陷的修复上，让我们看到了一种不同于其他开源项目的活力。

我们选择了OpenStack软件栈作为我们的IaaS平台基础，那么接下来就是评估这套开源方案能否完全满足现有需求。当然这套方案是不可能完全满足我们需求的。因此，我们又会根据不同的情况选择是进行二次开发或者完全自研。

举个例子，当时我们希望把Nova、glance、cinder的后端统一使用ceph rbd，但是社区当时还没有相应的计划。因此，我们决定对nova、glance、cinder进行二次开发，以满足我们内部的需求。随后，我们把该bp贡献到了社区。决定自研一般分为两种情况：一是开源软件完全不能满足需求，二是时间等不起，开源软件仍不成熟。以OpenStack面板Horizon为例，我们第一版的dashboard就是在horizon基础上进行二次开发的，但是horizon面板上的各页面响应速度完全不能满足需求。因此我们推倒重来，开发了自己的面板服务和API中间件来解决这个问题。

再以billing为例，Openstack社区曾经有过一些长期的孵化项目比如计费系统，但是这对于一个运营公有云平台来说，计费是必须的，所以在时间成本上，我们是无法接受的，于是我们就有了自己的计费系统。

目前我们有十多个自研项目，但是它们都使用与Openstack社区完全统一的代码框架。这些项目都是由BoneDragon开发框架统一生成的。这一框架是用Python语言编写的，可以一键生成项目的基础开发框架，包含标准化的API模块、数据库模块和测试用例。BoneDragon框架已经开源，并且发布到GitHub上。

InfoQ：企业内部修改开源软件后，如何做才能保证patch尽可能被接受？如果不接受，如何维护？如何随着主版本的升级而升级？

余兴超：对开源项目进行二次开发其实并不是难事。难事在于我们如何维护这些私有代码，OpenStack迭代频繁，每6个月会发布一个大版本，每2个月会发布一个里程碑。因此，我们在对待私有Patch的态度是非常谨慎的：我们会尽量把Patch提交到社区，当然这个patch必须是通用的，有完善的文档和测试用例，才能够被社区接受。若是该patch没有被社区接受或者是完全私有patch，那么我们会尽可能地不去破坏原有的代码逻辑，例如API扩展。如果不得不进行修改，也会尽可能地保持代码的可维护性。

InfoQ：决定使用开源软件后，企业应该做哪些调研和测试？具备哪些基础条件后，可以考虑再生产环境使用？

余兴超：从决定使用开源软件到最终在生产环境上线，期间会经历一段较为艰辛的历程。以Openstack为例，在对其进行了POC验证后，我们决定采用Openstack软件栈作为我们的IaaS平台基础。我们使用原生的Openstack搭建了一套用于内部研发使用的开发和测试平台，但由于页面缺乏快速响应，创建虚机的时间过长，缺乏计费，监控，管理员后台和运营后台等关键特性，因此并不适合将其直接用于商用。

在做了充分的客户调研后，我们对云平台提出了具体的特性列表和指标要求，比如页面的响应速度要求在200ms以内，操作系统镜像，虚拟机镜像，卷服务使用统一的后端存储，虚拟路由器能够在较短的时间内自动迁移等等。

在此基础上，我们制定了研发工作的roadmap，定义了各个项目的milestone。工程师们都全身心投入到了OpenStack项目以及UnitedStack自研项目的开发和自动化部署工作中。在经历了3个月时间的开发和调试工作后，我们完成了计划的特性开发，并将UOS平台部署到了生产环境。在最初的一个月时间里，UOS平台进入内测阶段，只针对内部和部分受邀用户开放，研发工程师们对代码进行了多次打磨，修复收集到的软件缺陷，运维工程师对线上变更进行了梳理和规范，制定对于Openstack公共库管理机制，跨大版本升级机制，变更异常时的回滚机制等等。

在达到既定的功能和稳定性的要求并且建立起关于该平台的研发和运维规范后，我们正式将UOS云服务平台开放。

InfoQ：公司是否应该有开源文化？同事之间如何较好的传递开源软件的使用经验？

余兴超：作为一家使用开源IaaS平台的云计算公司，我们积极在公司内部推动开源文化，鼓励工程师们积极参与到开源社区去。工程师们主动地参与到开源社区的开发，我觉得这就是一种良好的开源文化。

拥有社区开发经验的同事可以带领其他同事参与到社区开发中去。通过指引和实践，从未接触过社区开发的同事可以迅速地掌握社区的开发流程和规范以及项目框架等等。除此之外，这些有社区开发经验的同事会在代码审查上向其他同事提出详尽的修改建议，这样其他同事就能够尽快地熟悉社区的代码风格和质量要求。

InfoQ：公司应该如何培养员工的开源文化、开源意识？

余兴超：首先，一家公司中应该在其核心领域拥有一批在社区有影响力的工程师，他们会起到一个良好的带头作用。其次，鼓励（物质和精神双重）工程师们积极参与开源，对于公司和工程师个人来说，参与开源既是贡献，也是成长，也是在自我完善的过程。

InfoQ：开源文化对公司有什么样的积极影响？

余兴超：在过去三年里，我发现了一个有趣的现象：那些深度参与过OpenStack社区开发的工程师和未参与过社区开发的工程师有着较为显著的区别，这不仅体现在代码的规范、风格以及质量上，还体现在解决问题的思路上。之所以有如此显著的区别，有两方面的原因。一方面是因为开源社区拥有健全的持续集成体系和开发规范，积极的讨论环境和氛围；另一方面，公司内部业务需求的推动，使得参与开源开发的工程师获得了快速成长的机会。

因此，开源文化的推广有助于工程师个人素质的提升，对于公司产品和公司人才存储的竞争力来说都产生了积极的影响。

另外，一个积极拥抱开源文化的公司，意味着更加开放和自由，这将会持续吸引更多优秀的工程师加入。