转载

同程旅游王晓波：梦想仗剑的少年，“沦落”为还技术债的大叔

今天的私有云已不是单单基础建设，它已成为企业系统的核心技术体系，也是企业技术能力的倍增器，更是系统健康稳定的原动力。

2016年7月15-16日， ArchSummit全球架构师峰会将在深圳举行，本届大会，我们邀请了同程旅游（LY.com）首席架构师王晓波老师，前来分享《同程旅游基于私有云的服务架构的探索》的内容，同程旅游在私有云服务架构建设过程中的一些实际案例，如何基于Docker容器技来解决基础环境虚拟化过重的问题，又是怎样使用云化的思维开发的缓存、消息等中间件撑起同程旅游海量订单交易的。

让我们一起来看看，在同程旅游构建私有云时，王晓波老师的那些痛并快乐吧。

InfoQ：可以介绍一下自己的从业经历吗？

王晓波：说到从业经历回想起来，自己还是一个代码客，在少年时期（16岁）开始，各种玩具式的编程做了不少，彼时的梦想是成为一个超级黑客，做出各种黑科技式的工具。

梦想归梦想，现实是，我大学毕业后还是来到了一家传统的软件公司开始作为一名标准程序员，码着一行行的代码，实现的也是一些常见的功能，那时的我对着代码有着无数种的想法和奇思妙想，梦想着自己是一个强大的架构师掌控着系统的灵魂。也开始为这个想法去不停地寻找各种实现之路。此时工作场地换成去日本洋打工写代码，期间也经历日本式的架构思想锻炼和向老爷爷级的程序猿的学习。这样的洋打工生活持续了一段时间之后，决定去做互联网的应用，所以之后的生活基本是和各种并发、架构、运维、网络等内容天天交织在一起了，日复一日，年复一年。

2014年，我加入了同程旅游，正好经历同程技术变革的阶段，与众多团队一起做了很多技术变革路上的重大事件。

总而言之，我是一个带着梦想的程序猿。

InfoQ：同程旅游私有云服务构建之前系统基础维护有什么样的痛点？如何解决？

王晓波：同程之前在基础系统这块的主要痛点是，稳定性不够，经常会出现一些不应该有的故障，主要原因是长时间的技术债造成系统基础的错综复杂。

资源的利用率不高，主要原因也是之前对系统各个层次的资源的利用率考虑不够。运维方式有点跟不上系统膨胀的速度。业务应用的开发变得越来越难，因为大量的性能、可扩展性等的问题，让业务应用的开发不能只考虑业务功能的开发。

我们的解决是分了三批来完成的。

首先，我们将大量的运维工作进行了整合，并在大量故障数据的分析基础上进行自动化除障工作，并把原来的老旧的基础虚拟化系统更新成自主可控的轻量级基础虚拟化系统，主要借助了Docker等容器技术，这让我们基础系统相对比较稳定。

然后，我们对原有的数据完整性不够高的CMDB进行重新设计，让CMDB能进行全流程的基础信息数据管理，并实现自动抓取所需数据，还对CMDB进行分层设计让基础设施数据与应用基础数据层次管理，这让我们所有数据有了一个完整的管理。在这个基础上我们又研发大量的监控系统和分析系统，有做基础设施监控的、应用系统状态监控、调用关系监控，等等。自动化处理比例大大提高，故障自愈率也提高了一个层次。

最后，我们大量的中间件服务进行了云化工作，让业务应用只需要用，不用管其他（性能扩展等）以服务的方式提供。例如，我们的缓存系统就是一个例子：原来因为大量业务应用不合理的使用，造成天天故障导致缓存变为一个大地雷。之后我们的缓存整个设计成一个可控可运维的大系统并且可以自伸缩，这样业务应用开发只要申请所需的缓存空间大小，就可以完全放心地使用。

详细的解决方案我们将在这次大会详细介绍。

InfoQ：构建私有云服务花费了多长的时间？构建前后系统有什么变化？

王晓波：构建私有云服务花费的时间初期并不是很长，半年左右，在第二个月的时候我们就已经提供线上服务了。但这个系统是一个一直在成长的系统，到今天我们也不会认为已经建完了，因为一直在不停的变化，变的越来越强大。

构建前后系统变化是非常大的，因为我们的私有云服务并不是只在做基础设施的云化，我们把系统技术的升级重构、中间件的云化、运维的变革一并处理了。

基础设施的云化：在云构建前，大量基础设施处在比较混乱的一个状态，有直接的物理机使用，也有使用简单虚拟化后的虚拟机使用，大量应用不停地加，服务器使用率又不是很高，大量的服务器进入机房，但缺乏监控和自动化的操作管理。在云构建后，我们基本已经完全建设一个大资源池，应用是按实际压力情况进行基础资源分配。使用效率大大提高了，管理监控等不再是个问题了。

系统技术的升级重构：各应用系统的重构是我们在云构建这个过程中做得最重的一件事情。之前我们是想，云的构建不应该让应用系统做太多的改动，实际上也是，云的构建本身是不需要应用系统做什么改动的，但是在过程中发现这个还是“技术债”的问题。我们的很多应用系统的“技术债”太重，一直没有很好地还上，云的构建正好给这些应用系统一个很好的“还债”机会，并且对云的构建是一个很好推动。这样的一个过程也是让我们的私有云构建的进度和动力大大加快了。

中间件的云化：主要是要解决原来自己研发的中间件只是一个生硬的代码服务——“应用开发不会用”、“运维不会处理”等一些困难。

云化后的中间件基本是从团队结构开始发生变化的，原来的代码开发团队变成一个运维、研发、产品为一体的DevOps团队。原来生硬的代码服务也变成了一个个简单接入的服务。

运维的变革：云的构建对运维团队的变化是可以用一场革命来形容，运维从一个默默苦力团队变成了一支能做开发能做分析的超人团队。这里详细的变革也在会在本次大会上介绍。

InfoQ：从传统IT的运维，转换到云服务下的运维，运维工作有什么变化？

王晓波：我们的运维主要分为：应用运维、基础运维、IDC运维等不同角色的团队。之前这些不同职责之间的定义比较不明确，运维的工作也主要集中在被动的处理各种重复的故障处理上。

现在转到基于自己的云上的运维后，各团队的分工清晰，运维的工作也不再简单重复，已进入主动推动系统的进步的一个重要角色上了。

运维之前能做开发的人员比较少，到现在的云上的开发技能已经和系统开发没什么区别了。

总之，运维正在经历一场革命，从原来“故障小哥”转为运维的开发者、运维的产品经理等。

InfoQ：有人认为，云计算自服务和传统IT审批模式的冲突，是传统IT迁移到云计算最难的一个地方，涉及到IT流程、使用者思维改变等多个方面。对这一点你有什么深刻感悟？

王晓波：这一块我认为其实并没有什么冲突，并不是自服务就不需要审批了，我们只在让事情变得更快更适应环境变化，因为从某些角度上来说，互联网的要求就是快，唯一不变的就是变化，所以要求我们必须要更快地应对变化，需要更高的效率。云计算目的是为了更好更快更高效的IT服务，并不是让事情进入一个无管理的状态。

以我们的使用经历来说，云的方式不但没有让事情变不可管理，反而是比之前的大一堆的流程管理得更好，因为资源的管理已经进入高度的自动化、信息化的模式了。

InfoQ：在进行架构的时候，如何选择使用Docker容器还是虚拟机？如何部署？

王晓波：目前除了一些已经全能发挥硬件能力的应用外，我们已经全部使用Docker容器部署。当然还一些跑在Windows上的应用使用的是虚拟机部署。

如何选择：在使用Docker容器还是虚拟机的问题上，我们的想法是，虚拟机是很好，但是太重了。我们最渴望的需求是要让一台物理的服务器上多部署点应用，让使用率提高但是又不想让它们互相影响。

另外还想让资源尽量给到应用去使用，不要做无畏的损耗。并且还想做环境的统一，最好和开发过程中的环境也是统一的，还有快速的部署扩展，等等。这样一考虑，如果使用虚拟机虽然也能做，但好像不是最理想的，所以我们选择就是Docker容器了。当然还是一些别的因素的如，跑在Windows上的应用我们就选择虚拟机了。

如何部署：我们目前在生产环境部署的Docker容器量在近3000个实例左右。我们将容器分成了多个不同的任务的集群来完成各种不同的任务。我们也研发相应的调度管理的系统，来管理这些Docker容器和做应用的持续集成。这也会在本次大会上做详细介绍。