CIC的私有云计算架构

 

原文链接

 

对很多人来说，云计算已经不是一个陌生的概念，只是好像它都是跟诸如Google、 IBM、微软这样的业界大腕相联系，与中小企业无缘。而实际上呢，得益于诸如Hadoop这样的开源软件，广大中小企业也可以搭建自己的私有云，相当程度的满足自身需求。我们这篇文章会从我们的实践出发，谈一谈为什么CIC的业务也要求类似云计算的IT基础架构，我们的施行效果又是如何。

在CIC技术系统内部存在相当数量的应用，各自承载不同类型的大计算量任务，包括分词，产品分析，新词发现等等。拿7月份来说，仅仅当月的产品分析一项就花了近3000个机时，如果单机执行，则需要花费接近小半年，初夏的数据要到深秋才能拿到，我们的分析师真是要等到花儿也谢了。

为了解决这个问题，我们之前的做法，是由负责各个应用的项目组针对每种任务独立提供解决方案。例如，有些应用是将数据通过Linux的NFS服务共享，然后通过一些散列算法让部署在不同机器上的应用程序各取所需；也有的应用则是将数据通过RPC轮询发给多机处理，最后再将结果集中返回。这些做法单独来看问题都不大，但是如果从技术发展的全局出发，就会发现它们存在如下的局限性：
1. 如果为各个具体项目来实现分布式计算，则各个项目组要花费相当的精力和时间，来一次次的重复完成例如负载均衡，出错恢复等非核心业务功能；
2. 鉴于分布式计算本身也有专门的技术要求，未必每个项目组都有相应的技术储备；
3. 我们系统内部同时存在多个分布式系统，而每个系统部署在一些专门的机器集群上，这样会缺乏对机器整体的协调和利用，导致集群在部分时段空闲，部分时段又过分拥挤。

譬如下图是同一时间内目前分别来自三个不同应用集群中的三台机器的实际CPU负载，可看出大部分时间内机器都是空闲。但是同时在任务密度比较大的时候，这些应用集群本身的机器资源又可能超负，需要手动从其他集群中协调机器，从而增加了维护成本。

因此，如果沿着现在的方式走下去的话，那么我们的开发成本，维护成本，硬件投入，以及跨项目组的沟通协调成本都会持续提升；而硬件使用效率跟开发人员生产率却会下降。从这点出发，我们决定构造一个通用的分布式计算框架引擎(Computing Engine, 以下简称CE)作为我们的基础计算架构, 来满足如下基本需求：
1. 通用性，CE本身实现任务分发，负载平衡，错误恢复等分布式计算的基础工作，一个计算密集型的任务可以通过简易的封装，部署在CE中执行，在同一时间内，CE可以执行不同类型的任务，由此达到对服务器资源的最有效利用；
2. 健壮性，CE本身的运行稳定；
3. 可扩展性，新的机器资源可以简易的集成进CE集群，投入应用；
4. 灵活性，除去通过API或者通过扩展框架来将任务部署在CE中外，也要支持利用Python等脚本语言进行轻量级的开发，来应对一些ad-hoc的任务；
5. 支持对大规模数据量的处理，以及对最终结果的集中收集。

我们的Computing Engine是在开源的分布式计算框架Hadoop上定制开发的, Hadoop 是一套对Google著名MapReduce模式的实现，用最简单的话说，Map Reduce就是把任务数据拆分成多块，分别在不同的计算机上进行处理，最后再把中间结果聚合起来，得到最终结果。

目前我们已经成功整合了两项应用，另外三项也在工作中，应该说结果很让人满意，所有的机器资源不需要再根据应用被划分，运行稳定可靠，如果中间因为网络或者小部分机器本身故障，Hadoop的内部机制可以自动将任务分配到正常机器上运行，保证所有任务最终的顺利完成。同样再抽取CE集群中三台机器，观察它们的CPU使用情况，可以看出资源的利用已经显得相当均匀，如下图所示：

另外一个让我们高兴的副产品是，由于所有的计算任务会在单独的线程中进行，所以可以充分利用现代多核的CPU，经我们在双核的机器上测试，由于我们的应用本身没有对多核进行优化，因此在CE中执行时，即便是单机性能也提高了近50%. 

最后总结一下采用这样私有云架构对于我们未来技术发展的一些战略意义:
1. CE作为我们系统中核心运算平台的，能够大幅减少现有计算密集型任务的时间，同时提高服务器利用效率（顺便说一下，我们所有的计算服务器其实都是廉价的PC机)；
2. 同时， CE也使未来对计算要求更高的业务成为可能，因为这样的架构允许我们简单的加入新的机器就能扩充计算资源，而不会有额外的管理和维护成本；3. 最后，由于CE除了支持Java，也支持Python和Bash Shell这样轻量级的脚本语言（这要感谢Hadoop的良好实现），也使得我们得以鼓励开发人员利用廉价而高性能的计算平台进行业务创新。