企业私有云的换位再思考

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

私有云的异和同

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

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

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

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

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

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

云化思维解决的困难

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

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

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

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

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

架构角度的再思考

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

管理角度的再思考

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

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

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

运维角度的再思考

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

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

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

开发工程师角度的再思考

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

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

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

同程旅游的分享

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

Q&A

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本文根据ArchSummit微信大讲堂上期期邀请讲师，同程旅游首席架构师王晓波为大家线上分享内容和提问环节整理而成，该微课堂是ArchSummit全球架构师峰会运营大会之外的一个线上交流的平台，定期组织分享活动。在这里可以提前聆听讲师及所在团队的线上分享，了解大会最新动态。想参与的读者可以扫描左侧二维码，回复“架构师”，获取参与方式......

讲师介绍

王晓波，同程旅游 首席架构师，专注于高并发互联网架构设计、分布式电子商务交易平台设计、大数据分析平台设计、高可用性系统设计。曾设计过多个并发百万以上、每分钟20万以上订单量的电商交易平台，熟悉B2C、B2B、B2B2C、O2O等多种电商形态系统的技术设计，熟悉电子商务平台技术发展特点，拥有十多年丰富的技术架构、技术咨询经验，深刻理解电商系统对技术选择的重要性。

ArchSummit全球架构师峰会2016（深圳站）有幸邀请王晓波出任“云服务架构探索”专题出品人。大会15大专题，3位联席主席，15位出品人，10位大咖讲师，火币网的创始人兼CEO李林、饿了么CTO张雪峰、阿里巴巴速卖通技术部总监郭东白、Uber高级软件工程师魏凯...他们会给大会带来什么不一样的精彩呢？让我们拭目以待！7折购票倒计时最后一周，了解更多大会详情， 点击这里 。