搜狐私有云的两次转型之路

2010 年，搜狐开始搭建内部的 IaaS 私有云平台。2011 年，搜狐转向了 PaaS 私有云方案，做了第一个版本。第一个版本用了半年之后，又换了另一种方案做了 PaaS 的第二个版本。目前，搜狐私有云团队正在准备将这个内部的 PaaS 平台对外公开，打造成一个公有云平台。

在最近一次有关 PaaS 的线下交流中，搜狐 PaaS 平台负责人于顺治介绍了他们云计算平台两次转型背后所遇到的问题和思路。之后，InfoQ 中文站就该话题采访了于顺治，本文根据采访内容整理而成。

IaaS 平台建设

最开始选择做 IaaS 主要是为了解决以下两个问题：

1. 成本问题。之前搜狐的所有服务器全都是物理机，很多业务线的服务器资源都非常浪费，一台高配的物理机，上面可能只跑一个访问量很小的应用，几乎就没有负载。同时，机房的机架、网络设备等资源非常有限。使用 IaaS 可以有效降低成本，增加机房的资源容量。
2. 采购周期问题。在大的公司，从服务器采购申请开始，到最后的上架，这个周期一般都比较长。对于一些紧急项目，这么长的采购周期根本无法接受，最终肯定会影响项目的进度。IaaS 平台建成后会有一个大的资源池，在几分钟内就可以提供一台虚机资源。

平台建设使用的内部服务器的发行版基本是 CentOS 系，虚拟化方案选择了 Xen。之所以选择 Xen 是因为在那个时候，Xen 在 CentOS 的 Release 里已经比较稳定，而 KVM 则是刚刚进入 Release 中，尚处于测试阶段，而且从当时的社区支持和性能等方面考虑，Xen 的方案还是优于 KVM 了。当然，后续由于各种原因，Xen 逐步衰落了，不过这是后话。

IaaS 平台遇到的问题

IaaS 平台在推行一段时间后，遇到最重要的问题就是应用运维问题。

搜狐内部各业务线的技术都是独立的，而且绝大部分都没有单独的运维人员，一般都是开发人员兼职去做。当我们把虚拟机交给业务线后，业务线需要自己去搭建相关的软件环境，需要考虑 HA、灾备、监控、扩展性等问题，开发同学很难把所有的这些问题很好的解决掉，而且让开发同学去搞这些东西，他们也挺郁闷的。

同时，公司领导也希望能有一个平台，能统一公司各业务线的总体架构。而 PaaS 正好能比较完美的解决这两个问题，因此，在 2011 年，我们就启动了 PaaS 平台的研发工作。

第一版 PaaS 的实现思路

我们刚开始调研 PaaS 时，当时的主流 PaaS 基本都是按照 GAE 的那套模式去做的。当时 Cloud Foundry 刚刚开源没多久，自身也不太成熟，影响力也远不如现在，所以我们当时就没考虑 Cloud Foundry，而是跟随 GAE 采用了沙盒这种方式去做。

第一版的 PaaS 我们基于 JVM 做了安全沙盒，大概用了 5 个月的时间开发调试，在 2012 年的 5 月份正式为搜狐内部业务线提供服务。这个版本运行半年下来，可用性达到了 99.95%，非常稳定，各个业务线应用都开始逐渐接入。

第一版 PaaS 的限制

我们的 PaaS v1 最大的问题有两个：

1. 平台仅支持 Java
2. 平台的局限性非常大，只能基于我们提供的 SDK 做开发，老应用想要迁移更加困难

基于第一版 PaaS 的架构，很难去解决上面这两个问题。于是，我们开始调研其他方案，开始了第二版的开发。

第二版 PaaS

第二版的 PaaS 基于 Container 构建。通过 Cgroup 和 NameSapce，我们可以很方便的实现资源管控和应用隔离，也很好的解决了第一版 PaaS 的各种问题。其实除了新的架构之外，PaaS 平台的一些核心模块，如调度、配置、监控、存储等都复用了上一个版本的。

第二版 PaaS 的开发难点主要来自我们使用的 Linux 发行版对 LXC 的支持很不好，因此我们的工作重点主要是对内核进行 Patch，对 LXC 进行相应的修改调整，用以保证平台的稳定和可靠。

目前，V2 已经是搜狐内部主要使用的平台，之前 V1 平台上运行的应用基本全都迁移到了 V2 平台，而且很多是业务线的开发同学自主迁移的。V2 平台上现在已经运行了超过 400 个应用，包括技术中心、焦点、汽车、视频、Sogou 等，其中也不乏一些重要的应用，如搜狐通行证、搜狐企业网盘。

公有云的挑战

之前我们一直在做搜狐内部的私有云，它的很多要求和公有云还是不太一样。对于公有云来说，安全性是最大的挑战。

安全性会包含两个层面，一是平台的安全，因为公有云开放后，整个平台也就对外暴漏了出去，要防止某个恶意应用去破坏整个平台，保证公有云平台的安全可靠。二是应用自身的安全，保证应用的代码不会泄露，也不能被其它应用所访问。另外，公有云环境下，平台的稳定性，公有云用户的个性化需求等也都存在挑战。

我们在 v2 版本的基础上，在技术架构等方面做了调整和完善，降低平台模块的耦合性，使整个架构的扩展性更好，用以满足未来公有云用户的个性化需求，而且在网络、LXC、系统、Service 等多方面均做了加强，保证安全性。另外，我们也与公司安全团队进行合作，请他们对我们的公有云平台进行全面的评测，打压、扫描、模拟攻击，以便提前发现问题。最后，我们也会通过一系列的技术措施、规章制度等去规范公有云平台的运维体系，增加严格的审计制度，从内部去保证平台的可靠和安全，让开发者和企业信任我们的公有云平台，更放心的去托管他们的应用。

总结

过去四年，我们团队在私有云上做了很多的工作，也收获了很多，除了技术上的提升之外，我们对整个云计算体系有了更深刻的理解。另外，我们在如何应对大型互联网公司内部复杂的部署和运维环境方面积累了丰富的经验，并把公司内部的众多共性需求给提炼出来，在私有云上完成实现。我觉得最有成就感的产出就是为公司提供了一个统一的平台，一致的部署架构，使得内部各业务线的应用在生命周期内能方便快速实现开发、部署、监控，统计，并大大降低了运维成本，资源成本。