DevOps|架构与运维峰会,你可能错过的干货

科技 作者:有料 2016-05-19 09:14:38 阅读:291
  【5月18日报道】5月15日,UCloud主办的Devops Workshop架构与运维峰会于成都举行,大会邀请到了UCloud DevOps Workshop系列活动成都站,UCloud 邀请到了KVM运维专家肖力、1号店技术部-架构部总监张立刚和UCloud综合开发中心总监文天乐,分享他们在海量服务架构探索过程中的技术实践。 ucloud1 到场的听众来自各大互联网公司,包括文轩在线、长虹、京东、虹微、华为、tap4fun、四川移动、三零盛安、万达飞凡、马上消费金融、多点生活、任我行、数之联、TestBird、Testin、Camera360 、咕咚、启明星辰、神州数码等,现场积极的提问更是突显了听众对内容的关注。 ucloud2 图:肖力,金山西山居系统运维经理 金山西山居系统运维经理肖力,他带来了题为《我的虚拟化项目运维实践》的分享,从项目评估开始,介绍如何将自己的业务迁移到虚拟化或者云上,同时介绍如何做好监控、报警、灾备,持续的运维。 ucloud3 图:文天乐,UCloud综合研发总监 UCloud综合研发总监文天乐带来的演讲主题是《账户计费系统高可用架构设计与实践》,为大家着重分享了UCloud账户计费系统架构设计与实践,以及演化过程中积累的经验,主要内容有:账户计费系统现状与面临的问题、深入账户计费系统架构演进、简要介绍灰度切换方案、经验总结。他认为架构没有最好的,只有最合适当前业务发展的架构。 以下整理了金山西山居系统运维经理肖力和UCloud综合研发总监文天乐分享的内容。 肖力:我的虚拟化项目运维实践 嘉宾介绍:肖力,KVM运维专家。金山西山居系统运维经理,前盛大游戏研究员。15年工作经验,10年游戏行业运维经验,5年KVM虚拟化运维经验维护有微信订阅号:“KVM虚拟化实践”著有《深度实践KVM》一书。 本次分享主要有四个部分:非技术因素及业务压力模型构建、技术及经验分享、监控、灾备、应急响应、案例和公有云运维的一些经验。本文主要截取非技术因素、业务压力模型构建、如何将业务迁移到虚拟化环境、软硬件选型和灾备方案方面进行整理。 一、非技术因素 2015年是云计算大爆发的一年,对云计算虚拟化的直观感受是人才需求量越来越大、职业待遇逐步提高,云计算招聘的微信群异常活跃。第二个感受是做云计算的朋友在公司内部越来越受重视。总体来说:1.云是更高级的资源利用的方式2.云使业务部署更高效便捷3. 随着这几年的发展,云真的成为基础架构和生态系统,在大数据、视频、教育、医疗等各个方面得到应用。 现在的问题,已从企业要不要上云的问题,变成为如何上云的问题。企业上云可以选择使用公有云,可以选择自建私有云,也可以选择使用混合云,大部分使用云的方式以后应该是混合云。 云计算对运维人带来的影响最为明显的是分工更专业、要求更高,比如原来你在一个公司的内部,可能是计算或业务方面的运维;在上云后,可能会把系统、底层方面的运维工作都交到云,从而将更多精力关注到业务,将业务做得更好、更专业。如果去做私有云,也就是IaaS层的运维,包括数据中心、网络、安全等,只在大型企业存在,。此外,因为云计算平台有众多的API,如果你利用好这些API,可以实现从底层到上层的全面打通,运维方面的趋势是更强调自动化二、业务如何迁移到虚拟化环境 第一步,要说服老板和同事支持做虚拟化。随着云计算虚拟化概念的普及,很多人对云已然不再如开始般排斥,但是去做第一个项目时,一定要保证它的成功,树立好榜样。 第二步,如何选择潜力股 如何保证第一个项目成功虚拟化呢?一定要选择潜力股,找到一个比较好做成功的虚拟化项目,它有很多特征:
  • 单进程,现在CPU都是多核的,单进程可以非常容易去做;
  • 其次是利用率不高的业务,比如常年那些利用率只有20~30%的业务,可通过将几个业务合并到一个宿主机上,从而提高它的利用率;
  • 频繁变动的业务,通常非常喜欢做虚拟化,因为虚拟化快速部署的提点,解决了业务频繁变动这样的痛点;
  • 非核心业务,如果一开始就着手核心业务做虚拟化,一旦出现问题,将面临着很大的压力,甚而会影响到整个公司对于虚拟化的信心,所以第一个虚拟化项目从非核心业务开始。
另外,不是所有业务时候做虚拟化,在物理机上压力已经非常高的业务,就很难通过虚拟化来做整合。 第三步,虚拟化项目实施周期。实施虚拟化一般应该遵循以下样的流程:业务性能需求评估、根据压力模型设计一个虚拟化方案、搭建测试环境、系统综合测试、业务测试、小规模部署、全面部署、全面部署好最终的虚拟化运维。 第四步,解决实施中的问题。在实施过程中有一些问题需要注意,首要关注虚拟化层的稳定性,然后虚拟机快速自动管理维护,接着解决与业务更紧密的结合,最重要的是需要拥有一套监控、健康、报警、应急习响应预案。 三、业务压力模型分析 ucloud4 构建业务压力模型的时候,如何具体地做。首先要对业务架构熟悉,它的逻辑角色类型是怎样的,最好画一个图出来做到心中有数,明确角色间的关系。 然后进行性能数据收集与分析,有两种方法:
  • 一是收集每个项目的服务器数量和角色,看长期的监控数据、CPU内存等压力情况,一般观察两个月;
  • 二是通过脚本收集现有服务器性能,这个主要为了收集更细的数据;
  • 通过收集的压力数据,得出压力模型,根据压力模型,确定虚拟化比例
四、软硬件选型 软件方面,对于生产环境我们一般肯定要选择稳定版本。但是,在稳定版本的基础上,内存版本越高越好,为什么?这里有一个数据,数据时间比较长,同样配置情况下CentOS 6.1和 CentOS 5.6的CPU计算能力的对比,CentOS 6.1要比CentOS 5.6好9%,就是内核版本越高,它的CPU中断和上下文切换优化得越好,同时网络IO、磁盘IO也优化得越好。 硬件方面,尽量一开始配置要稍微好一点,因为配置得越强悍,你可以虚拟的虚拟机越多,你最终肯定节省成本;另外,内存也要稍微大一点,因为你的宿主机跑上一段时间以后,往往你会发现内存不够,到时候又要加内存。最后,尽量选择主流品牌。 五、灾备方案 虚拟机灾备策略—应用层备份(在线迁移不是灾备手段) 灾备有两种思路:
  • 应用层灾备,基本上跟原来物理机上一样,你在物理机上怎么做灾备,在虚拟机上用同样的方法做灾备;
  • 虚拟化灾备,做快照,做多份的镜像复制。
一般建议在应用层次做灾备,因为在应用层做灾备消耗的资源要少很多。注意的是,灾备要定期演练,一方面让大家熟悉过程,再来验证一下灾备这个机制到底是不是生效,可总结为两点:
  • 所有的虚拟机xml描述文件应定时交叉备份;
  • XML 描述文件与IP 地址信息需要同时备份;
  • 定期演练,我们自己要熟悉过程,相关的业务也需要让他们去演练一下,出现问题的时候我们可以很快的恢复。
总结 第一个上云是趋势,虚拟化是第一步;然后在生产环境,我们尽量选成熟的技术、完善的预案,因为对生产环境要有定位;虚拟化是基本的IT技能,不管原来做哪方面的运维,可能或多或少用到虚拟化的运维。此外,我们在企业内部推荐虚拟化的时候,口碑也是非常重要的,一旦有问题就会影响我们口碑去推需虚拟化。 文天乐:账户计费系统高可用架构实践 嘉宾:文天乐,UCloud综合开发中心总监全面负责UCloud经营数据分析、账户计费系统、网络、多账号平台研发项目。拥有7年以上互联网及 IT 研发相关经验,曾就职于商派、盛大在线、盛大云,历任高级研发工程师,盛大云监控及计费产品的开发负责人。 本文主要截取账户计费系统架构演进过程的六个阶段进行整理。 服务架构的演进过程 ucloud5 UCloud服务架构的演进主要经历了以下六个阶段:
  • 单体模式;
  • 具有灰度发布能力;
  • 前后端分离;
  • 服务化改造;
  • 按SET部署;
  • 分机房按SET部署,按SET进行跨机房热备容灾。
1、单体模式架构上线业务系统 UCloud服务初期上线时的架构主要分三部分:
  • PHP Web Conosle,负责所有前端展现交互、后台服务间逻辑组装;
  • 平台类服务,账户、计费、监控、名字服务等公共服务;
  • 各业务系统分数据中心后台服务的接入层。
PHP Web Console、业务系统分数据中心的服务、平台类服务组合上线,Web Console 通过Protobuf与所有后端服务进行通信。 2、具备灰度发布能力 要解决前面面临的问题,我们首先需要支持Web层灰度发布包含以下的灰度方式:
  • 无用户态特性按照 单IP -> IP段(地区) -> 到IP取模逐步灰度控制影响范围;
  • 有用户态特性按照 单内部用户(开发账号) -> 内部测试账号 -> 用户分级逐步灰度发布控制影响范围。
3、前后端分离 ucloud6
  • 开发API Gateway 层用来管理后端 API 注册和管理、权限验证管理、流量控制;
  • 开发API层,解决前台交互层,需要整合跨系统逻辑调用问题,前端只专注产品交互和用户体验;
  • 开发统一的单点登陆Token,系统方便前端实现跨域API调用让前端代码可以完全静态化。
在此阶段,完成前端展现可以独立控制发布,彻底实现了前后端解耦,API协议保证向前兼容,Web端可以随意重构交互优化前端架构,实现了跨域独立部署,独立的灰度策略互相之间不受影响,极大的提高了前端团队开发效率和稳定性。 4、服务化改造 对业务端API开发效率优化:
  • 按照业务模块化,所有业务API由后台产品研发部门独立部署发布上线;
  • 抽象通用平台类特性例如:子账号特性,权限体系,计费等特性抽象公共能力让业务端在API中组装。
总体目标:让业务API开发效率提升并单独部署维护,提高产品特性的研发迭代效率并提高稳定性。 5、按SET部署   基础架构优化完毕,各个业务系统单独部署发布,开始对系统进行容量和容灾方面的考虑,从部分平台类系统开始考虑按SET部署架构测底解决容量和容灾问题,每个SET只服务一部分用户,保证遇到物理服务器宕机等故障情况下只影响部分用户或业务。 ucloud7 例如图上所示, SET 1 服务1 ~ 服务50000000 用户,SET 2 服务50000001 ~ 100000000 的用户,一个SET 出现问题只影响一个部分用户,不同的业务根据自身情况进行SET切分,规模大小也视情况而定,按SET部署后合理的划分方式下不同SET之间数据还可以互相迁移,来平衡搞负载或高容量的SET,极大的提高了可运维性。 6、分机房部署SET ucloud8 按SET部署架构改造完毕后还没有达到最理想的状态,如果所有服务部署在单机房还是可能会出现问题,机房整体出现断电、断网等故障还是会出现大面积影响。
  • 对SET架构进行分机房部署,让不同的用户运行在不同的机房中,这依赖一些基础设施比如跨机房光线专线。
  • 跨地域SET在相邻节点部署热备,以便出现机房故障时能具备异地快速恢复服务的能力。
总体介绍了UCloud在不同的阶段架构演进的一些过程和经验,架构没有最好的,只有最合适当前业务发展的架构。

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:http://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

图库
关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接