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

  【5月18日报道】5月15日，UCloud主办的Devops Workshop架构与运维峰会于成都举行，大会邀请到了UCloud DevOps Workshop系列活动成都站，UCloud 邀请到了KVM运维专家肖力、1号店技术部-架构部总监张立刚和UCloud综合开发中心总监文天乐，分享他们在海量服务架构探索过程中的技术实践。 到场的听众来自各大互联网公司，包括文轩在线、长虹、京东、虹微、华为、tap4fun、四川移动、三零盛安、万达飞凡、马上消费金融、多点生活、任我行、数之联、TestBird、Testin、Camera360 、咕咚、启明星辰、神州数码等，现场积极的提问更是突显了听众对内容的关注。 图：肖力，金山西山居系统运维经理 金山西山居系统运维经理肖力，他带来了题为《我的虚拟化项目运维实践》的分享，从项目评估开始，介绍如何将自己的业务迁移到虚拟化或者云上，同时介绍如何做好监控、报警、灾备，持续的运维。 图：文天乐，UCloud综合研发总监 UCloud综合研发总监文天乐带来的演讲主题是《账户计费系统高可用架构设计与实践》，为大家着重分享了UCloud账户计费系统架构设计与实践，以及演化过程中积累的经验，主要内容有：账户计费系统现状与面临的问题、深入账户计费系统架构演进、简要介绍灰度切换方案、经验总结。他认为架构没有最好的，只有最合适当前业务发展的架构。 以下整理了金山西山居系统运维经理肖力和UCloud综合研发总监文天乐分享的内容。 肖力：我的虚拟化项目运维实践 嘉宾介绍：肖力，KVM运维专家。金山西山居系统运维经理，前盛大游戏研究员。15年工作经验，10年游戏行业运维经验，5年KVM虚拟化运维经验维护有微信订阅号：“KVM虚拟化实践”著有《深度实践KVM》一书。 本次分享主要有四个部分：非技术因素及业务压力模型构建、技术及经验分享、监控、灾备、应急响应、案例和公有云运维的一些经验。本文主要截取非技术因素、业务压力模型构建、如何将业务迁移到虚拟化环境、软硬件选型和灾备方案方面进行整理。 一、非技术因素 2015年是云计算大爆发的一年，对云计算虚拟化的直观感受是人才需求量越来越大、职业待遇逐步提高，云计算招聘的微信群异常活跃。第二个感受是做云计算的朋友在公司内部越来越受重视。总体来说：1.云是更高级的资源利用的方式；2.云使业务部署更高效便捷；3. 随着这几年的发展，云真的成为基础架构和生态系统，在大数据、视频、教育、医疗等各个方面得到应用。 现在的问题，已从企业要不要上云的问题，变成为如何上云的问题。企业上云可以选择使用公有云，可以选择自建私有云，也可以选择使用混合云，大部分使用云的方式以后应该是混合云。 云计算对运维人带来的影响最为明显的是分工更专业、要求更高，比如原来你在一个公司的内部，可能是计算或业务方面的运维；在上云后，可能会把系统、底层方面的运维工作都交到云，从而将更多精力关注到业务，将业务做得更好、更专业。如果去做私有云，也就是IaaS层的运维，包括数据中心、网络、安全等，只在大型企业存在，。此外，因为云计算平台有众多的API，如果你利用好这些API，可以实现从底层到上层的全面打通，运维方面的趋势是更强调自动化。 二、业务如何迁移到虚拟化环境 第一步，要说服老板和同事支持做虚拟化。随着云计算虚拟化概念的普及，很多人对云已然不再如开始般排斥，但是去做第一个项目时，一定要保证它的成功，树立好榜样。 第二步，如何选择潜力股 如何保证第一个项目成功虚拟化呢？一定要选择潜力股，找到一个比较好做成功的虚拟化项目，它有很多特征：

• 单进程，现在CPU都是多核的，单进程可以非常容易去做；
• 其次是利用率不高的业务，比如常年那些利用率只有20~30%的业务，可通过将几个业务合并到一个宿主机上，从而提高它的利用率；
• 频繁变动的业务，通常非常喜欢做虚拟化，因为虚拟化快速部署的提点，解决了业务频繁变动这样的痛点；
• 非核心业务，如果一开始就着手核心业务做虚拟化，一旦出现问题，将面临着很大的压力，甚而会影响到整个公司对于虚拟化的信心，所以第一个虚拟化项目从非核心业务开始。

另外，不是所有业务时候做虚拟化，在物理机上压力已经非常高的业务，就很难通过虚拟化来做整合。 第三步，虚拟化项目实施周期。实施虚拟化一般应该遵循以下样的流程：业务性能需求评估、根据压力模型设计一个虚拟化方案、搭建测试环境、系统综合测试、业务测试、小规模部署、全面部署、全面部署好最终的虚拟化运维。 第四步，解决实施中的问题。在实施过程中有一些问题需要注意，首要关注虚拟化层的稳定性，然后虚拟机快速自动管理维护，接着解决与业务更紧密的结合，最重要的是需要拥有一套监控、健康、报警、应急习响应预案。 三、业务压力模型分析 构建业务压力模型的时候，如何具体地做。首先要对业务架构熟悉，它的逻辑角色类型是怎样的，最好画一个图出来做到心中有数，明确角色间的关系。 然后进行性能数据收集与分析，有两种方法：

• 一是收集每个项目的服务器数量和角色，看长期的监控数据、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 研发相关经验，曾就职于商派、盛大在线、盛大云，历任高级研发工程师，盛大云监控及计费产品的开发负责人。 本文主要截取账户计费系统架构演进过程的六个阶段进行整理。 服务架构的演进过程 UCloud服务架构的演进主要经历了以下六个阶段：

• 单体模式；
• 具有灰度发布能力；
• 前后端分离；
• 服务化改造；
• 按SET部署；
• 分机房按SET部署，按SET进行跨机房热备容灾。

1、单体模式架构上线业务系统 UCloud服务初期上线时的架构主要分三部分：

• PHP Web Conosle,负责所有前端展现交互、后台服务间逻辑组装；
• 平台类服务，账户、计费、监控、名字服务等公共服务；
• 各业务系统分数据中心后台服务的接入层。

PHP Web Console、业务系统分数据中心的服务、平台类服务组合上线，Web Console 通过Protobuf与所有后端服务进行通信。 2、具备灰度发布能力 要解决前面面临的问题，我们首先需要支持Web层灰度发布包含以下的灰度方式：

• 无用户态特性按照 单IP -> IP段(地区) -> 到IP取模逐步灰度控制影响范围；
• 有用户态特性按照 单内部用户(开发账号) -> 内部测试账号 -> 用户分级逐步灰度发布控制影响范围。

3、前后端分离

• 开发API Gateway 层用来管理后端 API 注册和管理、权限验证管理、流量控制；
• 开发API层，解决前台交互层，需要整合跨系统逻辑调用问题，前端只专注产品交互和用户体验；
• 开发统一的单点登陆Token，系统方便前端实现跨域API调用让前端代码可以完全静态化。

在此阶段，完成前端展现可以独立控制发布，彻底实现了前后端解耦，API协议保证向前兼容，Web端可以随意重构交互优化前端架构,实现了跨域独立部署,独立的灰度策略互相之间不受影响，极大的提高了前端团队开发效率和稳定性。 4、服务化改造 对业务端API开发效率优化：

• 按照业务模块化，所有业务API由后台产品研发部门独立部署发布上线；
• 抽象通用平台类特性例如：子账号特性，权限体系，计费等特性抽象公共能力让业务端在API中组装。

总体目标：让业务API开发效率提升并单独部署维护，提高产品特性的研发迭代效率并提高稳定性。 5、按SET部署   基础架构优化完毕，各个业务系统单独部署发布，开始对系统进行容量和容灾方面的考虑，从部分平台类系统开始考虑按SET部署架构测底解决容量和容灾问题，每个SET只服务一部分用户，保证遇到物理服务器宕机等故障情况下只影响部分用户或业务。 例如图上所示， SET 1 服务1 ～ 服务50000000 用户，SET 2 服务50000001 ~ 100000000 的用户，一个SET 出现问题只影响一个部分用户，不同的业务根据自身情况进行SET切分，规模大小也视情况而定，按SET部署后合理的划分方式下不同SET之间数据还可以互相迁移，来平衡搞负载或高容量的SET,极大的提高了可运维性。 6、分机房部署SET 按SET部署架构改造完毕后还没有达到最理想的状态，如果所有服务部署在单机房还是可能会出现问题，机房整体出现断电、断网等故障还是会出现大面积影响。

• 对SET架构进行分机房部署，让不同的用户运行在不同的机房中，这依赖一些基础设施比如跨机房光线专线。
• 跨地域SET在相邻节点部署热备，以便出现机房故障时能具备异地快速恢复服务的能力。

总体介绍了UCloud在不同的阶段架构演进的一些过程和经验，架构没有最好的，只有最合适当前业务发展的架构。

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

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