为什么我们创造ZStack而不是选择OpenStack

我们站在巨人的肩膀上，所以能够看得更远

三年前，当我还在为另外一家IaaS软件公司工作的时候，一个朋友半开玩笑的对我说：“你们做的产品会让IT管理员下岗”， 虽然是句玩笑话，但我却非常认同这个观点。大家普遍的共识是IaaS以及各种软件定义数据中心的软件会解放各大公司的IT部门，对系统管理员的需求会大大减小。三年过去了，IaaS产业已经变得异常红火，可是没有一个IT管理员因此而失业。更戏剧的是，IaaS产业又创造出来很多新的工作岗位（到各大招聘网站搜索OpenStack职位即可证明）。现在，利用IaaS软件来搭建私有云的企业，他们不仅需要一个以前一样的团队来负责系统运维，而且还招聘了一个新的研发团队或是聘期第三方公司来维护IaaS软件本身。对云计算程序员来说，这或许是个好事，大家可以在这个行当里找到一份很不错的工作。但是我却对此深深的失望，因为我一直认为IaaS软件应该让我们的生活变的更加简单才对。

现在看来，复杂度和稳定性是IaaS软件诞生以来一直需要解决的两大问题。因为没有解决好，很多人试图用不同的观点来为此开脱。

有一个流行的观点认为, 云计算本来就应该是个很复杂的东西，它管理了一个包括计算，网络和存储在内的庞大分布式系统。这个观点不假，但是我认为，业务的复杂度并不表示软件的安装和部署应该复杂，更不表示软件的使用和维护应该复杂。2011年的时候，我花了差不多一周的时间来安装我的第一个OpenStack系统，但以失败而告终。后来在DevStack的帮助下，我才能一睹它的真容。2014年，为了尝试Neutron我再次试图安装OpenStack，可是这次竟然连DevStack都失败了。当然，复杂性这个问题不是OpenStack独有的。在其他IaaS软件的邮件组里，随处可见各种针对IaaS复杂性相关问题的抱怨。通常这些问题还只是发生在搭建一个微型的演示系统上。如果用户要在一个超大型的机房里搭建IaaS软件，他们遇到的问题可想而知。

我有一个朋友，他的团队负责运维公司内部一个由2000台服务器组成的OpenStack私有云。他觉得OpenStack的复杂度对他们来说并不是一个大问题，或者没有让他们感觉有什么不舒服。我完全可以理解他说这句话的原因。因为经过两年不断的摸索，他的团队里成长起来了很多精通OpenStack的大牛。他们不仅仅只是使用OpenStack熟练，深谙其中各种坑，还能进行创造性的二次开发。这就是我之前提到的IaaS创造的研发团队。虽然他所在的互联网公司可以负担这种复杂性带来的开销，但不代表大多数的传统公司能够。我们也看到了许多来自OpenStack社区内部的警告（感兴趣的读者可以搜索： Open Source and OpenStack: Complexity and lack of knowledge raise risks； OpenStack's Next Move Is To Remove Complexity； We Need To Simplify OpenStack。 或者直接搜索"OpenStack complexity"）。所以，虽然我们看到基于OpenStack的一些成功案例，例如eBay，但是并不是每一个传统公司能够组建一支DevOps的团队去部署自己的私有云，并且自担风险。（另外，我在eBay工作的朋友透露，他们2014年的主要任务就是把公司的OpenStack系统从Folsom升级到Havana，用一年时间）

OpenStack能够解决自身的复杂度吗？也许可以，但是这一定非常的困难。难并不是因为OpenStack社区缺乏优秀的软件工程师（相反，我们很难见到其他类似的项目能聚集如此众多来自全世界的卓越的软件专家），而是因为OpenStack的设计理念、设计原理以及它从一开始就确定的架构，决定了要解决复杂性，并是通过一些小修小补或是简单的代码重构就能够实现的，而是需要破釜沉舟的重新设计。但是如果真的推倒重来，它还是OpenStack吗？也许你可以叫他NewStack，FutureStack或者其他什么Stack。总之，怕不再是OpenStack了。对于这个问题，很难在一段话中讲清楚，我将会在另一篇文章中详细论述IaaS软件的复杂性的根源和解决办法。

至于稳定性，我前面提到的那位认为复杂性不是问题的朋友也承认他们OpenStack的稳定性对他们来说是个头疼的问题。比如奇怪的API调用错误，不稳定的集群，消息总线无故挂住，脆弱的网络系统，还有一些我没有记下来的问题。当然，这些问题也不是什么秘密。在2014年OpenStack香港峰会上，Ubuntu就曾公开的表达，Openstack是脆弱的（https://plus.google.com/107021066102930532296/posts/U1sU3zEZAiQ）。类似的观点也可以在一些OpenStack论坛看到。

相比一些单机软件，分布式的IaaS软件由于集成了许多外部子系统，的确面临更多的挑战。在我之前的工作之中，也经历了相同的遭遇。我一直密切关注着行业领袖OpenStack，也曾一度希望它能够解决我们遇到的各种问题。但是，我逐渐的意识到在OpenStack社区，有些重要的架构设计没有得到足够的重视。3年前，有一个”RabbitMq Scaling“（http://lists.openstack.org/pipermail/openstack-dev/2012-November/002730.html）的问题引起了我的注意。起初，我无法想象一个具有每秒处理2万到10万次消息能力的消息总线会无法满足IaaS软件的需求。跟踪这个问题后，我发现OpenStack用了一种叫临时队列（temporary queues)的东西，它会为每个消息动态的创建和销毁消息队列。尽管这种设计方式也并非不可以（我们可以在AMQP的规范中找到），但是我还是很好奇究竟是什么原因让OpenStack做出这样的决定。因为程序员的直觉告诉我，这会带来潜在的稳定性和性能的问题。当时我很高兴有人发现的这个问题并试图修复它。不幸的是，当我昨天再次查看相关实现的时候，发现OpenStack依然还在使用三年前的老方法。这让我感到诧异。在过去的三年中，OpenStack社区里已经冒出来很多新的子项目，可是这么严重的基础问题却依然存在。如果你尝试使用1万个并发API来同时创建1百万个虚拟机，你将会很容易的看到它带来的严重影响。要重现这样的场景，你不必去构建一个真实的物理环境，利用简单软件仿真就可以模拟。如果消息传输层存在这种潜在的不稳定性因素，你无法相信它可以构建出一个大型稳定的云计算环境？如果IaaS不能稳定，构建在其之上的PaaS和SaaS面临的问题将会被更加放大，且更难修复。云的稳定性相关的问题还有很多，同样我想在另一篇文章中详述它的根源 和解决方法。

那么Openstack到底能不能修复这些稳定性问题呢？或许吧，但是恐怕也不会太乐观。通常这类稳定性的问题往往都是由于底层设计考虑不足。如果想要完美修复，都需要对核心模块彻底的重新设计。所以，这似乎又回到了前面说的推到重来的问题。有人也许会认为，只要OpenStack放慢一些功能开发的进度，花时间来修复一些稳定性相关的bug，再辅以严密的测试，就可以让OpenStack到达非常稳定的状态。这或许可行，但是以我的经验来说，面对一个已经有几百万行代码的项目来说，不从底层架构重新设计是无法实现的。如果只通过修复一些bug来提高稳定性，当整个项目一旦恢复快速开发的进度，那些曾经的稳定性的问题依旧还会重现。一个健壮的软件必须要能保证添加再多的功能也能持续稳定。我的合伙人在开源软件测试领域有多年的工作经验，他说：真正保证软件的稳定性的方法是健壮的架构，而非完善的测试系统。

既然OpenStack无法解决我一直期望解决的问题，那我想我们也许该重新做个新产品了。我们要从最初的设计就开始认真的审视这些问题。要对每一根地基，每块砖头都仔细推敲。我们希望我们的IaaS软件能够达到如下三个目标：

1，简单。任何一个数据中心的IT管理员应该能轻易的创建单机云或者搭建一个由成千上万台服务器组成的分布式云系统。

2，健壮。这个云系统能够满足长期稳定运行，并且在保证稳定的同时添加各种新功能。

3，灵活。除了可以实现亚马逊公司知名的EC2模式外，该云系统可以实现各种不同的模式来满足差异性的客户需求。

我有一个朋友，他是一家知名的OpenStack公司的CEO。他对我说，“你不会成功的。因为你想实现的东西也是我原来想做的，但是后来我不得不放弃，因为现实让我明白这是不可能的”。我告诉他，这也是为什么我们选择去创建一个新的IaaS，而不是基于OpenStack来做的原因。既然先行的IaaS巨人们已经帮我们标注了前进道路上泥泞的沼泽和丛生的荆棘，我们坚信我们可以站在巨人的肩膀上走向成功。

在我们做ZStack的伊始，我们并没有着急的添加各种功能。因为我们知道既然各种很炫的云功能（例如VPC，ELB，VPN，Ceph，Swift）已经能够成功集成到各种IaaS之中，他们之后也会稳定的集成到ZStack中来。相反，我们花了很多时间来思索该怎么构建核心架构去化解已知的复杂度，稳定性和灵活性等问题。例如，我们设计的消息传输层可以可靠的处理数万条并发请求，多功能插件系统能够在不修改现有模块的情况下轻松添加新功能，各种自动化的机制能够最大的减轻系统管理员从安装部署到升级维护IaaS的负担，精密的流水线引擎可以完全回退任何错误事件造成的影响。我们还有许多许多高级的功能，我无法在此一一例举。你也许会说，口说无凭，请给我干货。好吧，鉴于此篇文章长度有限，请访问我们的主页http://www.zstack.org.cn。在那里，我们写了16篇纯技术的博客来详细介绍我们的主要技术特点。如果那样还不能直接的让你把我们的技术和当前的问题联系起来的话，我会再写更多的博客来详细阐述他们的关系。

最近Docker(或是其他和容器相关的技术)和繁荣的公有云业务可能会让人们怀疑基于IaaS的私有云还是否有未来。这个话题也非常有趣，在未来的文章里，我也会阐述我们的理解。

最后，我想说，尽管我说了一些关于OpenStack负面的问题，但是我绝非想要冒犯这样一个伟大的先行者。相反，我包涵敬意的认真学习了OpenStack很多年。我想说，如果这个世界上要是没有OpenStack，那么整个IaaS产业绝不可能像现在这般繁荣。IT管理员恐怕还不得不挣扎在管理服务器的汪洋大海之中。跟其他行业的开路先锋一样，OpenStack遇到的各种问题，也仅仅是因为在它开始的太早，很难找到什么可以值得参考的东西。因此，ZStack是幸运的，我们从OpenStack以及其他的IaaS身上学到了很多经验，你在我们未来的文章中也会看到我们借鉴了他们一些非常棒的点子。

哦，对了，你可能会对我们的名字感兴趣。我们之所以叫ZStack，因为我们希望就像Z是26个字母中的最后一个，ZStack也能成为这个行业为了构建一个易用，稳定，灵活的IaaS软件的最后一次努力。

好吧，感谢看我唠叨了半天，祝你天天好心情！