谢谢大家，我是来自人民在线的杨耀武。今天主要讲一下就是我们公司在建云并且让重要的系统上云的，我们整个过程当中的思考和一些我们的想法。因为大家都知道现在是越来越多的机构和企业，都在建自己的私有云。但是如果你去问的话，你们的最终目的、你们的想实现什么样的价值、你们想预期结果是什么的话？我不知道会有多少人不加思索的，或者能够清晰的把它表达出来。其实这问题我们在私有云最开始的阶段，我们也在不断的问我们自己，我们一直在困惑，后来我们逐渐意识到，其实对于云来讲，它的最重要的原因是什么？就是为我们的业务、为我们的产品提供相应的价值。也就是说它能够为我们业务产生这种推动，能够让我们的业务向前发展，能够提供多的价值。接下来就是我来具体的介绍一下，我们整个的建云决策和过程，和我们上云的大致步骤。

这是我们公司大致的业务简短的说明，人民在线是人民网一家控股子公司，我们主要是做的舆情业务，主要分三大块，一块是舆情监测还有舆情预警、还有舆情应对。对于舆情监测这一块信息化程度是最高，包括采集、包括里面的处理，包括话题分析、主题分析等等，还实时监测也有推荐方面的一些东西。其他还有预警这一块是我们的系统和人工相结合的业务，还有应对这一块还有传播分析还有相关的咨询建议这一块的东西。

这是我们整个的思路过程，当时资源情况是这样，当时我们有两个数据中心，一个是在北京一个是在武汉。我们的产品线包含的也比较多，包括  我的舆情监测等等的产品，还有一些我们的内部及时通讯还有微通社就是微博、微信相关的东西。在这种情况下，其实我们对于资源来讲我们要求是比较端化，我们既有存储密集型的业务，也有对计算、网络通讯要求比较高的，当然也有一些高并发的业务。

这样对于资源来讲当时的情况就是，我们很多产品，其实它都会有一个突发的要求。就突然有一天这产品上线，或者说我们的系统要扩容等等。或者说我们的配置进行变更，但是在当时的情况下就产生了一个矛盾，就是我们的硬件资源是相对固定的，因为当时我们整个的硬件来说比如说我们也才用服务器，整个的过程就比较长，包括我们后来集成、测试等等两三个月都搞不定，但是资源要求很多情况下都是比较紧急，很多时候是不确定，因为你不时候要什么样的资源。

后来自然而然就想到了私有云的这东西，下面的说明都比较了解，包括私有云的主要优势包括资源的池化，包括资源的系数的分配，甚至包括快速的交付、灵活弹性可扩容等等方面的东西。既然私有云提供这一方面的便利，有可能能解决相关的问题，接下来就是怎么去做。第一是可能寻找相应的技术合作伙伴一起建设私有云。我们公司上下达成一致，说这事肯定要去做，接下来做一些相关的预算和一些业务的规划。

这就是当时我们建立云之初的思考，我们建设目标是什么？期待的成果是什么，做到什么程度我们的建云成功了，还涉及到具体的架构选择包括规模、预算都是建设周期需要考虑的。

当时我们想重要业务系统上云，当时我们是这么认为的，我们重要的业务上云这是就是私有云一个里程碑，证明我们整个建设已经取得了一定的分工了。如果对我们的业务系统在成本效率方面有很大的提升，其实这私有云的价值就体现出来了。再有既然决定哪一些系统上云，我们对于云的架构选择，甚至包括它的规模的估算，我们就是心里有一定的基础和主线去考虑了。

这就是当时我们的思考。我们目标是什么呢？其实我们终极的目标相对来说比较方向性的目标，就是验证云计算、云平台，都能给我们带来哪一些价值和哪一些方面的提示和变革。我们是否坚持走云化的道路，我们具体的结果就是舆情监测业务上云，我们的规模评估数据量转到数据量，用户的规模以及性能的要求，我们的硬件资源和我们的整个预算资金情况都能有一个比较靠谱的估计，接下来就是架构选型，比如说存储，硬件方面有可能还有一些IOPS比较高的业务还有SD相关的存储设备，包括我们对于网络安全这一方面都会有一个大致的要求出来。然后就是我们的建设周期和我们相关的具体实施计划。

这是一个太极图，其实我的意思是这样，让我们的重要业务系统上云，是我们私有云建设一个主要的目标，它也是我们实现目标的主要策略，也就是什么意思呢？重要的系统它既然是我们上云的目标，我们针对这系统来讲，其实我们就要估算我们整个的云计算相关的规模，也就要决定我们的采用具体的一些架构配置。其实很多在建立之初不明确、不清晰的地方，其实我们就把它明确起来，然后对于我们整个的技术选择，包括整个的具体一些建设实施的细节规划，其实也都是比较明确了。

其实它对于我们实现私有云建设目标它其实就是一个我们思考的主线，我大致就是表达这意思。

当时我们人民在线整个产品体系，写的不全还有很多这是主要的几块，包括我们的监测包括在线募客的产品线、容媒体等等。但是作为舆情监测是主要的业务，为什么这么选？第一个系统够复杂、包括我们的数据采集、包括一些我们的语意分析，包括检索推荐功能系统，这系统这么多不同的系统对资源是有不同的要求。其实这对云来讲对它就是一个考验，对不同的舆情环境、不同的要求，它的支撑程度是什么样，其实这可以很好的测量。

还有一个就是我们有一些系统是需要物理集群上比如说我们的Hadoop、我们的搜索集群。我们云上的系统和物理系统是互通互访，这也是一个现实的需要。

还有就是舆情监测产品线是频繁发布和频繁更新，这也就是考验我们云平台这一块资源交付效率的相关它能提供一个什么样的程度。因为云平台是我们公司的主要业务，云能够给它提供很大的提升，能够提供很大的价值，这一个来讲体现程度就比较高了，这几点就是我们一个主要考虑的点。这大概就是我们的公司舆情监测业务的大致的架构图。从左往右包括我们的采集、包括我们的数据过滤，到中间这一块就是一些分析处理的东西，包括我们的一些聚合计算，包括标准化包括一些搜索等等，还有知识库方面的东西，最右边就是一些可视化的应用，包括高警趋势分析等等更复杂的。这是整个的舆情架构因为它比较复杂所以包含的系统也比较多。

这是当时我们大概的一个社两，左边这一块就是我们要上云的系统，包括右上云Stomt、还有存储包括Spring云存储的架构图片的应用。右边这一块就是部署在物理集群上包括Hadoop，还有Hbrse还有Spark还有搜索系统等等，这是我们当时对云上和云下系统的划分。

这是我们当时考虑的几方面，包括基础架构的考虑、资源要求的考虑，包括我们的建设周期、投入以及和其他系统依赖关系等等。当然也少不了我们跟一些业务沟通，包括业务部门它方面具体的要求。这就是OpenStack云架构这是很通用的一块，这没什么太多可细说的。

这个就是从总体上描述一下我们整个平台架构，包括最底层的数据中心，它提供的一些各种各样的资源，这一块是云平台，包括最底下的资源池、包括上面的应用系统，右边这一块部署在集群上的物理系统，我们把它命名成一个混合的架构，因为它共同来支撑整个舆情监测业务能够顺利的运行和提供服务。

这是我们的一个云平台建好之后，我们舆情监测业务上云的一个主要的过程。第一个就是我们要分配资源，全量部署是什么就是我们的资源都要部署但是这规模比较小，大概是十分之一的比例吧，只有两块，一个是我们的数据分流。因为想要整个业务系统经过真实的数据和访问的考验，所以我们把线上的真实数据分流到我们整个的业务系统上来。因为我们整个的数据采集，以及整个通讯都是使用的AMKU，其实这非常简单我们把数据导流过来。

然后就是访问分流这一块复杂一点，因为我们当时用的DCP，把真实的访问流直接导入测试云上的舆情监测系统上面去。接下来就是我们日志分析，我们用的ELK我们会做一个日志的分析统计化展示，还有一个我们做评估的时候，我们会统计我们的错误日志看看有没有问题在里面，再有我们会对数据比如说原始数据导流的处理，以及分析的数据，跟线上的数据对比看看有没有大的出入。后面就是我们的测试和我们的部分用户真实的访问，看这提案包括性能，包括流长度等等这就是我们整个的大数据过程。

这个图就是我们在整个云平台管理过程当中的一些热点问题和一些相关的经验总结。我估计大家很多公司企业也会遇到相关的问题。最外面的一层就是一些问题，比如说我们最开始的资源配置有可能过低了，有可能我们CPU、内存供给不足。还有可能我们整个的资源量供给不足，也就是我们的虚拟机供给数量不足，还有可能我们的IOPS需求更高，有可能存储和性能瓶颈。然后还包括最左边这一块资源分布不均，有一些系统分布资源过多了，有一些系统本身要的资源比较多但是分的不够，就是我们资源回收比较困难的问题。

我们的总结是这样，第一就是我们对任何的资源要求，都要做好提前的评估。如果我们的资源要求量比较少的情况下，我们就可以简单的评估一下。但是如果资源量要求比较高。比如说我们需要十几台、几十台虚拟机，一般情况下都要求相关的产品、相关的综合部门测试报告出来，我们才能给予资源的提供，还有就是我们对他们的配置要求不是说要什么配置就给什么配置，经常情况下我们会打一个折扣，还有就是我们资源的分配，可能不是一次分配了，我们是分批次的，比如说一次交付50%，或者三分之一的样子，因为我们任何一些业务系统不可能一上来就是高跑，所以分配式交付现实情况下可行，如果一旦发现有问题，我们把它变更起来其实成本代价也是比较少的。还有一点就是因为整个云平台的测试，我们对整个资源的配置变更还是比较方便的，不管是增配还是减配这实施起来还是比较便利的。这就是我们大概的一个上云前后的性能提升的对比吧，这没有特别多好说的。

大致就是这样一个过程，谢谢大家。