作者：YY游戏云平台组
1.1 云计算发展趋势
自从2006年亚马逊AWS上线它的第一个EC2实例以来，云计算已经在全球得到飞速发展，并且被企业用户和个人开发者广泛接受。RightScale公司发布的2016年度云计算报告[1]显示，采访了1060名IT专业人士，其中42%的受访者所在公司的规模大于1000人，95%的受访者已经在使用各类云计算，如图1-1所示。
图1-1 调查显示95%的受访者在使用云计算
RightScale公司的调查报告同时指出了2016年云计算相对于2015年的增长趋势，如图1-2所示。
图 1-2 2016年云计算相对于2015年的增长趋势
上述数据表明，2016年相对于2015年公有云的使用率仅上升了1%，而私有云的使用率攀升了14%，使用混合云（这里定义为同时使用公有云和私有云资源池）的比例则从58%跃升至71%。
1.2 YY游戏使用云平台的经验
自2013年起，YY游戏[3]就使用私有云平台服务于自身的页游业务。
在开发云平台之前，游戏运营面临的问题是：
-
页游开服快、密度大、周期短，导致运维变更频繁。
-
传统开服、合服涉及大量的运维人工操作，例如安装服务器、配置网络、部署游戏、配置数据库等。
-
用物理机开服，资源分配不合理，一个物理机上分配较多的游戏进程，会导致风险过高；分配较少的进程，又导致成本浪费。
-
数据备份、监控、故障转移在传统模式下都成为挑战。
针对这些痛点，我们在OpenStack的基础上，开发了第一代云平台，即Cloud 1.0。云平台上线后，资源管理更加灵活，在性能和成本之间取得良好的均衡，并极大地增强了运维自动化能力。到现在为止，Cloud 1.0已经支撑了几十万游戏用户同时在线。
如图1-3所示是Cloud 1.0的基础产品架构，包括云主机、云存储、云DB、云缓存、云网关五大核心产品。用户可通过控制面板访问它们，也可通过调用API在应用程序中访问它们。
图1-3 YY游戏Cloud 1.0的基础产品架构
在Cloud 1.0的OpenStack实现中，虚拟计算是Nova管理的KVM，虚拟网络是Neutron管理的VLAN供应商网络（ProviderNetwork）。关于VLAN供应商网络，Rackspace有一篇博客[4]描述得比较清楚，可以参考。在Cloud 1.0中我们没有使用分布式块存储服务（如Ceph）。
在Cloud 1.0中，我们并没有实现租户网络，不同的游戏厂家接入同一Flat网络，这对隐私和安全都不利。Cloud 1.0的云网络架构如图1-4所示。
云网关是游戏平台中一个重要产品，请参考腾讯游戏的TGW[5]。简言之，云网关有两个重要作用：一是收敛公网IP，节省IP成本；二是集中安全防护，降低单个云主机被DDoS攻击的可能性。所有的云主机都只有内网IP，运行在云网关后面。除了云主机外，还有云DB、云缓存、云存储等配套产品，都是游戏服务需要的。
图1-4 YY游戏Cloud 1.0的云网络架构
随着云平台规模越来越庞大，慢慢暴露了OpenStack的一些弱点，比如结构复杂、可靠性一般、扩展性弱，导致我们在云的可控性方面很被动，从而产生了对第二代云平台的需求。
那么我们需要一个什么样的云呢？首先，它是基于私有云的；其次，这个私有云一定要满足业务特点，比如游戏行业与金融行业，业务特点截然不同；最后，这个云一定要可管理、可扩展、可控。对于一个平台服务来说，存在性能短板、运行故障并不可怕，可怕的是出问题后用户无法跟踪和定位，从而失去可控性。
在此需求推动下，我们着手开发第二代云平台。正是随着第二代云平台，即Cloud2.0的自主研发和上线，我们在此过程中积累了大量的实践经验，从而得以推动本书的形成。
1.3 云计算随想
本书作者之一风河，作为云计算用户已有多年历史。从2011年起，就先后使用了多家公有云平台，包括Rackspace、AWS、Linode、Vultr等。从客观上说，云计算带给用户的不只是成本优化，还有效率方面的显著提升。
在更早期的时候，用户的网站要么使用Share Hosting（共享主机，如DreamHost、HostMonster），要么使用Dedicated Server（独立服务器，如SoftLayer、CNServers）。前者在性能、稳定性方面都存在问题，不适合流量大的站点；后者在管理上极麻烦，下单一台服务器，短的2~3天，长的1~2周才能完成上架交付。云计算出现后，有效地解决了这些问题，带给用户更稳定、更高效、更便捷的解决方案。
YY游戏有自己的云平台解决方案，主要面向公司内部的游戏运营和业务部署，既包括IaaS私有云平台，又包括PaaS升龙部署系统。在我们自己的云平台上，花了不到半个小时，就建立了一个测试站点。这个站点的配置如下：
-
云主机：2VCPU、1GB内存、50GB硬盘、无公网IP地址
-
云DB：1GB内存、InnoDB、SSD盘、单实例
-
云网关：TCP转发
基本上是最低配置的云主机和云DB，并使用了支持TCP和HTTP协议的云网关（因为云主机没有配置公网IP地址）。
服务建立后，对资源的管控和监控都极为方便。如果是传统的物理机，则要装一堆的东西、写一堆的脚本去完成服务器监控与备份。而对于云主机、云DB，这些都是一键式操作。如图1-5所示是云DB集成的监控图。
图1-5 云DB集成的监控图
面向用户技术的发展趋势，应该是越来越方便、易用。以前建立一个站点，需要专业人士来完成。而现在借助各家云平台在基础层（IaaS）、业务层（PaaS）所做的铺垫工作，非专业人士也能在短期内建好一个站点。在飞速发展的移动互联网时代，产品的更新迭代极快，如果产品开发能够用现有的平台与技术快速实现，为什么不用呢？这也是云平台将来会持续存在与发展的一个原因。
而对于技术开发用户来说，接受云平台、适应云平台也是一个必然趋势。比如，对于我们
开发的业务，往往会关注如下几方面问题。
-
弹性：根据访问规模的增减，业务弹性伸缩（Scaling）。在规模变大时，整个架构自适应Scale Up；在规模收缩时，架构Scale Down。架构里包含Web服务器、应用服务器、数据库服务器、缓存服务器、存储服务器等。
-
自动化：业务的开发、测试、发布、部署、运行、调试整个环节，都有自动化手段辅助进行。只要执行几个命令，就可以将代码从本地环境发布到远程环境，并顺利运行。不需要关注服务器怎么分配、数据库怎么运行、路由（Route）怎么调度，只要关注自己的业务逻辑是否正常即可。
-
分布式：随着节点的增加，业务性能（Performance）和容量（Capability）线性增长。在节点发生故障时，自动进行故障转移（Failover）。不管是水平扩展还是故障转移，对用户都是透明的，整体服务可用率高。
-
监控：业务范围内的每个服务对象，大到IDC、CDN、服务器、存储，小到每个逻辑接口，都有自动化监控手段，在发生问题时第一时间通知到开发者，使其对业务运行环境（硬件、软件、网络）的性能、可用性指标了如指掌。
现在，上述问题越来越成为我们关注的重点。传统的开发模式和服务交付方式，比如手工部署、单机运行、自主管理、集成一体（All in one），可能还继续适用于某些业务。但是随着开发团队和业务规模的增长，开发人员迟早会面对上述问题。此时面向云的开发模式和交付方式，就显得突出和有必要了。
从传统模式到云模式，开发理念和实现方式有个转变过程。不是说把一个传统软件扔到云平台上就能随时运行。比如，业务要做到弹性和分布式，它自身需要是状态无关的（Stateless）。它的事务（Session）、日志、数据、缓存都必须去本地化，使用外部独立的存储接口。在云平台上，应用节点随时可以生成，也随时可以销毁。如果业务自身没有做到无状态，那就谈不上弹性伸缩。
总体来说，面向云平台的业务开发模式，给我们带来的不只是架构的变化，更是开发理念的转变。在这种理念下，软件开发过程更快速，软件质量更高。用户只要遵循一定的开发模式，平台就会保障软件最终运行的架构、性能、可用性和扩展性。
[1] RightScale公司2016年度云计算报告：
http://www.rightscale.com/blog/cloud-industry-insights/cloud-computing-trends-2016-state-cloud-survey
[2] Gartner公司关于世界级公有云服务的市场研究报告：
http://www.gartner.com/newsroom/id/3188817
[3] YY游戏是欢聚时代公司互娱事业部旗下的品牌，官网是：
http://wan.yy.com/
[4] Rackspace的博客Neutron Networking: VLAN ProviderNetworks：
https://developer.rackspace.com/blog/neutron-networking-vlan-provider-networks/
[5] 腾讯TGW：
http://wiki.open.qq.com/wiki/TGW
本文节选自YY游戏云平台组新书《自主实现SDN虚拟网络与企业私有云》第一章，本书已经在各大图书平台有售。
