YY游戏使用云平台的经验及云计算随想(2)

在更早期的时候,用户的网站要么使用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)、日志、数据、缓存都必须去本地化,使用外部独立的存储接口.在云平台上,应用节点随时可以生成,也随时可以销毁.如果业务自身没有做到无状态,那就谈不上弹性伸缩.

总体来说,面向云平台的业务开发模式,给我们带来的不只是架构的变化,更是开发理念的转变.在这种理念下,软件开发过程更快速,软件质量更高.用户只要遵循一定的开发模式,平台就会保障软件最终运行的架构、性能、可用性和扩展性.

文章来自微信公众号：云技术实践

（编辑：ASP站长网）