引言：一个企业私有云的建设是在企业整体技术下的行为，各个方面都有影响，故而不仅仅是个技术的问题，从纯云技术以外的系统架构、管理、运维、开发等角度去讨论一下这话题，也会有更多新收获。

私有云的异和同

随着云计算的概念普及，公众对云计算的概念广泛接受，云的建设投入也越来越大。在这里我们再回头看看企业私有云这块在建设过程中的一些场景，将会发现一个很有意思的现象！每个人眼中的企业的私云，各不相同但又无比的类似。

构建一个企业私有云是一个复杂的命题，在私云开始建设的N年后，我们回头来看会发现，大部分企业私有云的建设是为了把资源动态管理起来，对访问控制和资源隔离没有做太多要求。

我们先来说说这个私云建设起初的目的，在面临基础维护的各项压力时的痛点：一、随着应用的增加，服务器的使用每天都在增加，但单机的性能往往利用不充分，单机使用率不高，服务器增加让管理变的一团糟。二、网络的压力，随着用户数量的增多，以及使用量的变大，一个地方出问题整个网络就会出问题。外网、内网、管理网都成了一张张无法管理的大网，管理成本高昂。三、应用的运维工作变的异常复杂，应用部署的复杂度在增加，应用部署的时间在加长，故障响应时间变的越来越长，付出的代价也越来越大。于是很多企业都开辟了一条类似的道路：私有云。

私有云的工作对于不同的企业来说，因为需求不同所以用的方式也不同，有自己慢慢研发的，也有直接使用外部方案的，如：OpenStack等。但这里面我们会发现这件事情更多变成了为解决服务器、网络等基础问题而专门去做的事了；或者变成了因为要私有云所以要建私有云，变为一件单为解决技术问题去做的事了。

这时我们要是从另一个角度再来看一下私有云这件事会发现，原来很复杂的麻烦事，只是从一个麻烦变为了另一个麻烦。面对一套庞大又复杂的云系统，原来的故障换了一个脸又来了，并且来的更难排查了，因为基础设施变的更复杂，排查的时间更慢。比如，我们的一个产品线曾经直接使用整套开源解决方案，直接部署。在起初一切运行稳定，但是当子项目的流量进一步扩大后需要的基础支持越来越多，这时开始出现了比较大的麻烦，因无法掌控所有开源方案的技术细节，所以系统出现了各种的问题，这些问题有些运维是可以绕过或解决的，但是毕竟运维开发能力不足，我们不得不为每天可能突发的问题配备一个比较专业的开发团队。

整体开源解决方案有很多功能，而我们只是使用了其中的一小部分，为了这一小部分的功能，我们的开发团队不得不熟悉整个项目的代码，维护系统的开发团队的规模也比较大。我们其实给客户提供的只是产品服务，这样每天投入的人力成本非常高，而且对于问题的处理流程也是比较混乱的，最终我们只能退回到原来。所以在建设私有云这事上，我们还是要从整体系统方面来更多的思考。

云化思维解决的困难

从整体系统架构的角度来看看我们的应用系统到底出现了哪些困难，哪些我们是可以用云化来解决的。这里用到了“云化”这个说法，不是私有云。一个系统从应用到基础应该是一个整体，解决问题要从整体来考虑，这个整体包含很多方面：技术文化，开发人员的能力等等。那么具体困难有哪些，我们其实是可以总结一下的，就出现系统架构这一个永恒的课题了，什么样的架构是一个好架构，答案也是一个老声音：最合适的才是最好的（这个好像等于没说）。

那么在系统架构这块往往很多企业因为历史原因存在很多不合理的情况，一时之间也很难完全解决，这才是引发故障最大的核心点之一。比如，缓存这样一件看起来很简单的事情，在起初的系统中引入缓存，因为没有一个很好的架构设计，在一段时间后会发现这个系统中出现了一大堆的缓存服务器，每个缓存服务器中放入的缓存数据也可以用一句话形容：“不知道是什么”。

整个系统在缓存上已经错综复杂，原本为了提高系统性能而设计的缓存变成了一个地雷，任何一个缓存服务器的故障都有可能搞死整个系统。这样一个缓存的问题其实也是很好解决的，就看用什么样的方式来解决，只不过是要花费很多时间来重构整个系统，但是即使本次重构系统完成，可能在不久的将来因为这样凌乱的架构，又会面临再次重构。

这样的例子应该还有很多：数据库，消息队列，各项核心服务等等，但我们回想一下缓存的故事，我们能不能应用云化的想法搞定呢，那么这里的云化，我们就不能单单从基础技术的角度去考虑了，我们要从开发者的文化，后期的运维，架构的可扩展性，使用的便捷性等等方面去想，最后需求归为一句话“要一个缓存的服务在开发者看来它可大可小，数据想怎么放就怎么放，永远也玩不挂，随时能说的清楚里面有什么”。

这时我们就把缓存容器到缓存的调用，整体系统的监控和系统的自动扩容都在后端解决，让开发者使用我们的缓存系统，看上去就像是一个巨大的缓存盒子。把这样的云化工作一件一件的做起来，到最后我们自然就得到了一个真正解决我们困难的私云了。

架构角度的再思考

从系统架构角度的再思考，在这个角度上我们发现一个好的系统往往是一个：大事变小、大系统小做、简单设计、可快速开发、可运维性强的微服务化系统。不会出现一个点出问题，处处有问题的情况。并且对于业务的需求能快速的响应。这时我们私云在这块上就需要更多思考怎么更多的提供可靠的云化中间件，如，缓存，数据代理层，服务发现治理框架等，只有这样才能给应用开发人员提供更多的技术支撑，屏蔽更多的技术细节，让他们能像开发小应用那样，开发大系统。

管理角度的再思考

从管理角度的再思考，在这个角度上，我们经常遇到的一个问题是，对我们的基础资源的整体管理不够，如这个网口上应该是一个什么样的设备；这个服务器是用来做什么的；这个服务器应该安装什么OS，上面的基础配置应该是什么；这个服务器上部署的是什么业务；同样的应用还有多少台服务器；哪些是正在工作的；这台服务器使用量是什么样的，还能进一步的提高吗；扩容的时候还能再快一点吗；等等。

这样的问题让我们想到了最开始的那个需求“ 把资源动态管理起来”，是的，这个正是我们最基础的那个想法，所以在这角度我们的私云就应该要为它设计一个完善的CMDB，这个CMDB可以从基础资源管理到上层应用管理进行一个全面的掌控，并且数据还能够闭环的自动采集，CMDB虽然本事技术难度不高，但是它的管理方式的设计会直接影响整个私云的原数据管理。

当然还有一个最重要的基础事项，选择一个合适的虚拟化的方式，当然这个还要考虑应用的现状，成熟的方案有很多，如：Docker很帅，但你当前如果还有大量的在windows上运行的应用，那么就不太合适了。所以最合适的虚拟化方案才是最好的选择。

运维角度的再思考

从运维角度的再思考，在运维这个角度可能大部分的想法是我已经选择了一个比较好的虚拟化方式这就可以了，或者说私云就是为了解决运维的问题而生的，可能还有更激进者认为我们有云了，就不要运维了，只要找几个人把服务上架就行。但是运维真的就这样吗？这里还是先来想一下运维到底应该是个什么样的角色，从传统情况上来说我们的运维可能每天都在忙于发布，回收等常规基础性操作，工作时间长了好像运维只会发布重启一样。

但其实在移动互联网的今天，一个应用的更新迭代的周期是非常快的，这时候会出现；一些应用，产品和开发者都不再维护它了，但是这个应用还继续在线上运行，这就一定要有运维人员在，并对各种问题进行第一时间处理，这时候运维其实更像一名全栈工程师。

所以私云的基础解决了运维的基础工作（如像Docker，运维的基础工作变的很少），这样运维需要用更多时间来思考，如何更好的在应用层面运维好一个系统，例如：当一个故障事件发生时，这个异常事件后面是什么，关联事件又是什么，这样就让故障的解决变的更加可控。所以在私云建设中要给应用运维建设一个强大的应用运维平台，让运维的所有数据在这个平台流通和分析，给运维人员最好的数据支撑，这样这个私云就是一个健康的云。

开发工程师角度的再思考

从开发工程师角度的再思考，这里的开发工程师并不是指私云的开发者。这个角度经常会被人忘记，因为很多情况下，大家会感觉私云主要是解决基础问题的，开发的应用只要能在上面跑就可以了，所以和开发者的关系不大。其实这时是忽略一些事情的，私云上乘载的正是这些开发者开发的应用，让它们更好的运行才是私云本质的目的。

但长期以来，应用发布上线，往往需要大量的运维工作，所以这个工作往往是非常忙碌的。那么这里私云需要考虑一下怎么去打通开发者到运维者之间的关系（这也是一对长久欢喜冤家）和减少开发过程对基础环境的影响。这里举个比较low的例子：一个故障发生，运维找来了开发人员一起排查故障，几翻苦查之后，发现应用在开发环境和生产环境的基础配置不一样。其实这里反应出来的是一个长久矛盾，开发者不擅长各种运维技能，运维者又不了解开发意途。

这里可能会说我们要‘全栈工程师’但全栈工程师毕竟数量有限，同样我们也可以用一些生硬的管理流程来解决这个问题，但是这样都不是很好的方式，因为我们需要给开发人员更多的自由。所以私云建设在此处就可以做的很好（如：Docker在这里就给了大家更多新的想法），让开发人员通过私云慢慢融入devops的技术文化。

同程旅游的分享

以上正是同程旅游在私云的建设上不同阶段，纯技术角度以外的思考，从这个角度来看：一开始我们对机器进行纯粹的虚拟化，然后把整套开源方案直接拿来使用，接着使用Docker等容器加上中间件的云化走轻量之路。一切过程全是为了系统的更快，更稳，更好，让事情变的更简单，让系统变的更轻量。当然这个私云建设是一个整体的方案，我们需要从多种角度去审视它，不应只从纯粹的云技术这一个角度来看，这也是一个需要长期迭代的过程，我们还在路上。

Q&A

1.问题： 请问同程目前的私有云建设处于何种阶段？如何满足业务的发展需求？

答: 目前同程所有的业务都是跑在我们自己的私有云上带，近一年大量的引入了docker容器，目前基本能满足业务的发展，我们还在继续带改进私有云

2.问题：vmware和citrix的桌面虚拟化您怎么看，会有使用的意愿么？用这两家的产品搭建企业私有云。

答： vmware和citrix的桌面虚拟化只是在做虚拟化，当然虚拟化在云里面是非常重要带一环，但不是全部，如果从虚拟化角度来说它们是挺不错的，但是私有云毕竟以云的方式去做的，虽然不对外公开，除了虚拟化以外，还有做很多其他的工作

3.问题：docker的网络用的ovs吗？

答: 我们的docker没有使用ovs，在网络这块做的比较保守的

 

4.问题：docker的安全怎么考虑的呢？

答: 我们的安全是从整体出发的，安全团队会有很多扫描器，宿主机上会有安全的agent做监控，来保障我们整体业务系统的安全，不知道问的是不是这个安全

5. 问题：您对于微服务和自适应性能水平扩展以及自动发布架构paas配置在有效数据监控下的调整有成熟的产品或者成功案例吗？

答: 这块我们仍在不断的改进，部分可以做到根据监控数据，自动弹性扩容，其他还是需要人工的半自动化参与

6. 问题：你们私有云的使用后，开发工程师对devops有什么样的参与度？

答: devops需要比较多的文化气氛，我们公司一直在积极引导工程师带devops实践，目前部分中间件研发团队，都已经进入devops

7.问题 : docker是部署在物理机上还是虚拟机上呢？

答 :docker部署在物理机上的

8.问题：在单台服务器上存在多个可选业务组件，它们需要的基础环境不尽相同。我希望使用docker封装每个组件。请问这种方案是否可行？是否存在资源占用或其他隐患？

答: 我们的每个docker容器都是单一的应用服务，docker本身的隔离是没有问题的，如果物理机紧张，可以尝试

9.问题：请问有使用openshift 之类的软件管理docker，在一台物理服务器上会出现不同docker 之间的资源竞争吗？如果有那又如何解决呢？

答 : docker 本身具备很好的资源隔离能力，所以基本不会发生资源竞争，我们在应用过程中没有发生类似问题

10.问题：目前的云平台，会使用会用到KVM，Xen等虚拟化技术吗？底层的KVM与Docker之间的关系如何？如果出现KVM的安全漏洞，是否会影响私有云的安全？

答 : kvm我们也在使用，目前有大量的windows服务是跑在kvm上的，我们的安全是整体的安全方案，所以在这一块上是从整体考虑的安全方案，安全措施比较多，基本上入侵检测，到网络监控，主机防御等基本都有一套完整的系统在跑，基本不会担心这个问题

11.问题：即使单台服务器的场景docker也值得应用对吗？

答：可以把底层的基础依赖一起打入容器运行

12.问题：请问docker集群是部署在coreos上吗？还是其他的发行版？

答: docker部署在centos7上

13.问题：有几成业务放在docker上跑了，有多少docker实例？

答 : 我们除了windows上的应用，其他都基本跑在docker下面了，大概3000个左右的container，也一直在增加

14. 问题：您公司以后会不会开源一些成熟架构或者开放一部分私有云的paas平台给其他开发者比如自动扩容数据反馈架构产品?

答:我们也很想开源出来，目前还需要做更多的工作，以让它变的更好

15.问题 :kvm通过openstack管理还是rhev？

答:我们之前也在使用openstack来管理，目前正在迁向我们自己研发的一个轻量级管理工具

16 问题 :kvm和docker的异构管理是由统一的云管理平台来负责吗

答:是的，统一归平台管理

17.问题：数据的安全性是如何整体考虑的,比如故障恢复之类的

答: 数据库在另外一套数据库的管理集群中，另外还有分布式文件存储系统，docker本身不存储数据

18.问题：容器中应用的更新一般怎么做，更新镜像并重启容器吗？

答 : 目前是这么做的

19.问题 :数据库放物理机吗？如何和虚拟机（业务层）通讯，三层吗

答 : 目前生产环境的数据库没有使用虚拟机，网络是三层通讯

20.问题：问个偏业务的问题，像业务上数据有关联的模块，在应用容器开发和部署时，有哪些要注意的？

答:这个问题没太看明白，我们这边的业务模块之间的通信和调用是通过我们的服务治理调度中间件完成的

21.问题：灰度发布吗，原则是什么？

答 : 是灰度发布的