浙江移动关于云计算发展的一些思考
发布时间：2022-10-14 10:36:30 所属栏目：云计算 来源：
导读： 中国移动云计算愿景
早在2011年中国移动就提出了云计算发展的思路和愿景，云计算将逐步成为构建中国移动各IT系统的核心，通过云计算技术降低系统建设和运营的成本，提高信息处理能力，实现服务创新，增强
早在2011年中国移动就提出了云计算发展的思路和愿景，云计算将逐步成为构建中国移动各IT系统的核心，通过云计算技术降低系统建设和运营的成本，提高信息处理能力，实现服务创新，增强
|
中国移动云计算愿景 早在2011年中国移动就提出了云计算发展的思路和愿景，云计算将逐步成为构建中国移动各IT系统的核心，通过云计算技术降低系统建设和运营的成本，提高信息处理能力，实现服务创新，增强企业核心竞争力。在中国移动，主要分成私有云和公有云部分。 统一规划建设企业私有云（支撑云和业务云）以资源池形式支撑内部IT系统的资源需求，具备根据需要分配资源和弹性扩展的能力采用多租户形式实现IT应用系统的集中。 面向公众客户（中小微企业、个人用户），提供标准化的通用资源和服务，类似亚马逊AWS；面向大中型政企客户，提供针对客户需求定制化云服务平台，如盘古搜索进一步发展基于云计算的移动互联网业务。 现在，云计算已经被炒得火热了，很多传统企业也在构建自己的私有云和公有云。中国移动省级单位一般至少会分成三块：支撑云、业务云和公有云。 但是，很多公司的管理者乃至部门的管理者对云计算的理解都大相径庭。同时，出现了很多怪现象。有些企业，长期以来把云化和X86化，虚拟机化划等号的概念大行其道。究竟什么是云化，云化比例应该如何出统计口径，也一直没有明确的说法。 其实，很多公司几年前就建设了多个资源池，但成本还是没降到理想满意度，而且经常遇到很多困惑，如上图中提高到的那些问题。很多资源池的利用率尤其是CPU利用率，其实非常低。 经常遇到一方面资源池利用率上不去，一方面很多业务需求要实现却老是要等设备配套、等机器就绪，这岂不是咄咄怪事？ 另外，还有些单位成立了专门的部门管私有云，这些部门把X86设备一安装，VMware一部署，虚拟机一划就宣布云计算建设完成。把应用扔在脑后不管。 应用的云化和迁移到底应该谁负责？应用的云化到底算云计算部门的责任还是应用开发部门的责任？如果后台云服务挂了，比如说数据库变蜗牛了，到底如何区分应用的责任和平台的责任？这是一笔糊涂账。我参加阿里云用户大会的时候曾向阿里的人请教过这个问题，但没有得到答案。 有时候，虚拟机建设了一大堆，上层基础软件和技术架构却是一盘散沙，甚至放任每个开发小组自行选择，弄得七国八制，乱七八糟，这种情况怎么看呢？ 作为在传统行业工作多年的IT人，总觉得有些如鲠在喉，不吐不快。于是就有了下面这些文字。 云计算核心技术 云计算的特征有很多，个人抽象了最关键的一些属性以及云计算带来的一些核心价值。要分析问题，必须从这几个关键概念开始说起。 很多传统企业存在开发外包的情况，开发外包——片面追求对业务部门的服务，追求对业务需求快速实现的妥协，最终很容易演变成对IT架构的失控，对IT核心能力的失控。其中一种体现，就是竖井化的建设随处可见，应用和平台的耦合非常严重，甲方对开发商的依赖度偏高。系统云化程度低又造成了计算资源难以共享，总体TCO的失控。 云计算要么就不要搞，要搞就要搞出名堂来，要搞就要瞄着谷歌、BAT的架构来，去IOE是不是像纸面上说的那样，至少推动IT架构从集中、商业、封闭向分布式、开源好开放方向发展，这是必须的。 云计算涉及的技术很多，大家一定可以列举出更多。不过并行计算的概念特别重要，值得特别提一下，是后面讨论的基础。 拿阿里云打比方，可能很多互联网公司的兄弟早已看明白这张图，不过我觉得对于传统行业来说，还是要提点一句，不要被那些花里胡哨的技术服务迷了眼睛，阿里飞天平台才是真正的核心，才是值得很多传统行业去关注的地方。(注意橙色部分) 我们公司的有些领导技术背景很强，提出过大云小云的说法，梦想是实现大云，也就是谷歌和BAT那样的，可以在整个数据中心实现资源的动态部署，作业和流量的动态调度的真正云。与之相对应的，就是资源和调度都是在非常有限的范围内禁锢住的云，比如说仅仅实现了虚拟机，称之为小云。 这个说法业界是没有的，但是我觉得蛮形象的，所以在这里借用一下。 为什么说阿里是真正的大云呢？通俗的说，真正的大云必须实现弹性伸缩，也就是实现数据中心级的集中化、动态化，标准化的资源管理和调度管理。 实现弹性伸缩和资源管理就已经很牛了。但是只是把基础资源管起来，没有应用的配合还是等于零。那么，要实现应用的集中化和动态部署，就必须有统一的分布式协调服务。因为只有基于分布式协调服务，才能标准化地去实现应用的名字管理，也有助于实现应用的无状态。应用实现无状态和统一名字管理是实现应用动态部署的前提。 结论：分布式协调技术很有用，缺了大云不转。 虚拟化技术也不能用虚拟机这样的重量级虚拟化，否则你起个虚拟机N分钟，得急死个人！这种情况就决定了我们必须使用轻量级虚拟化技术，现在一般都是基于LXC（Linux Container）技术，最热的就是Docker，轻量级虚拟化技术是实现大云的重要一环。 有了轻量级虚拟化，分布式调度，分布式协调，计算资源就可以动态伸缩了，但是光这样也不行，还要将负荷引过来。这就需要分两种情况了： 后台作业，这种情况分布式调度技术框架一般结合一下计算框架自己就搞定了; 前台流量，这种情况一般需要用到负载均衡技术。 结论：要实现真正意义的大云，关键是实现分布式调度。但实现这一点，又依赖于：负载均衡技术、轻量级虚拟化技术、分布式协调技术。 以上四大技术中，个人以为最难搞的是在与分布式调度和分布式协调。 要实现大云不容易,阿里和谷歌这样才做到一个数据中心是一个大的操作系统。 云的进化论 这一页说服老板估计应该用得到。 其实一句话就可以说清楚，真正的云化不是大变小，而是要实现小变大。凡是不能标准化实现小变大的云都是伪云、小云，能实现的才是真云、大云。 这一页是我和兄弟们自己抽象出来的，没查到资料。 大多数运营商或者银行，其实以前更多做的IaaS层的虚拟化以及应用的云化，本质上是一种竖井式的云化，甚至包括运营商的大网，就是核心电信网，ims msc从IT的角度看都是应用级云化。 经常被老板问的一个问题是数据库能不能实现云化，图中也给出了解释。 总之，一般来说现阶段，在数据库层实现阶段四“PaaS集群化”是比较靠谱的，非要做到阶段五，把数据库去和那些无状态的应用一样去动态分配资源，既无技术，也无必要。 也许云数据库可以实现动态分配资源，但如果是生产一个空的数据库分片，无数据的数据库那属于无状态，这种场合偷换了概念。而且，如果是生产库，肯定需要做数据再分布，这种动作一般不可能对前台应用无感知，所以本质上还是不能做到和无状态应用那样无压力的动态资源分配。 结论：暂时数据库以阶段四为目标就差不多。而且一般用户用一下EXADATA其实很合适，何必把平台能做的东西硬押给TDDL呢？去O考虑全生命周期事实上不省钱。云计算建设反思 时代变了，还是拿着新武器去打老仗？看上去很可笑吧？不过这可是真发生过的。别笑，现实中很多企业现在还在干这种事情。 应用视角的竖井式云化建设多，云平台自身建设考虑少。所谓系统的云化变成了应用的竖井化改造，能力未能沉淀和积累，事实上形成新的竖井。应用云化只是一个过渡性的概念，必将被基于PaaS资源池化和EPaaS化的应用上云概念取代。云计算必须以技术标准化、能力平台化作为方向。而不是简单买一堆X86，安装一堆VMware就完了，那是土老帽干的事。 云计算是有规模效应的。资源池越多，资源利用率越低，建设运维效率越低，云计算的效果越不能有效发挥。好的云计算公司技术架构完全可以做到大一统，整个公司一个大集群，但是出于管理目的去分为多个资源池，那也基本接近一个资源池一个大集群。很多壕公司呢？管理随意，可能历史原因资源池就是以部门或者项目组来划分的，这是与云的思想背道而驰的。 此外，技术架构不标准，不统一，落后，说是一个资源池，里面资源互相不能共享的小集群数量说出来都吓死人。这种情况却很少得到重视，也很普遍。 浙江移动云计算发展的一些思考 其实除了BAT以外，目前传统的行业IT技术发展相对较快就是银行和运营商，总体感觉云化基本都在IaaS资源池化和应用资源池化的阶段，建行最近做了PaaS，但也是真正大云那种。上图是我们自己近期做的一个云计算蓝图，还很粗略 做这个服务的目的是把技术服务和技术实现解耦，应用只需要知道他需要订购的技术服务。 以下是几个概念： 我们做这个规划，着重规划了PaaS层服务能力，希望突破近年来云平台长期处于低水平IaaS级建设的束缚，有望将虚机级弹性伸缩扩展到集群级，初步提升资源利用率和费效比，同时在快速部署开通、有效敏捷支撑业务获得明显提升。 直接提出EPaaS（数据中心操作系统）的规划，希望能实现深度的弹性伸缩、提高资源利用率、降本增效，为真正实现数据中心级“大云”迈出坚实的一步。 这是我们初步考虑的浙江移动云计算架构蓝图雏形，还在修订中。上图只是画到服务的颗粒度，落地层面，一个服务不一定是一个产品，也可以对应多个产品。其实PaaS里面还可以放更多的内容移动云计算，比如说FaaS，但是我们量力而行，不敢过于好高骛远。 EPaaS本质上核心内容和阿里的女娲和伏羲思路很接近，但之所以把他们画在PaaS层，是由于我们想突出他们对应用标准化开发的意义。 我们在规划这个蓝图的时候也遇到一些困扰。比如说，纠结什么是一个技术服务？例如阿里的DRDS和RDS为什么是两个服务？一个DRDS如果底层有Oracle，MySQL，PostgreSQL三种产品支撑，为什么还能被称为一种服务？如果内存数据库有朝一日发展到和关系型数据库访问接口完全一致了，为什么还要单独列为一种服务？说白了，到底从哪些维度去定义一种服务？ 核心意思是，可以考虑尝试一下ZooKeeper、Meso和Yarn。当然，我觉得不太容易，这些技术都好潮，特别是对于我们低小下的运营商来说，实现起来还是比较麻烦的。 我们考虑，逐步从第三阶段向第四阶段演进。把重心从应用云化这种私有化竖井化的云化思路中解脱出来，改为优先建设PaaS云平台，然后在推动应用向云平台的迁移改造，大力推动能力平台化。 同时，建立云平台服务和产品目录管控机制，将云平台能力标准化、服务化和规范化，杜绝以项目组为中心的七国八制的技术架构，推进技术架构标准化。其实，就和阿里云一样，应用要使用数据库不是项目组可以随便加的了，原则上得考虑使用云DRDS上已经具备的能力，比如DRDS。当然，如果你不喜欢目前MySQL的DRDS，你能说服云计算团队，可以加一个PostgreSQL版本的DRDS。阿里就是这么做的，我们也是这样。 核心观点总结 最后一点是关于技术团队管理改革思考，如上图所述。 Q/A 问题1：您这边费这么大力气，建这么大的中云，动力是什么？感觉挑战应该非常大。 答： 我们这些年遇到了很多挑战。比如说，核心能力的丧失、技术架构的竖井化、应用建设的缓慢和资源池利用率低等。作为体制内的老IT，我希望能为这些多年顽症的解决，出一点力，希望能推动这些问题的解决，但体制内也只能一步一步来。算我有一点技术情节吧，我这个人有时候看到那些问题在哪里，就是有去解决的冲动。 有人问，你为什么要登山，答曰，因为山在哪里。对吗 问题2：“做这个服务的目的是把技术服务和技术实现解耦，应用只需要知道他需要订购的技术服务”这个解耦，能再更生动具体的例子么 答： 我姑且举一个例子，我们的一个核心系统里面用到了缓存技术，我就遇到过这样的事情，在线系统是A项目组承建，采用了MEMCACHE。现在该系统要改造，项目组提出换REDIS。Ｂ系统，Ｂ项目组承建，类似场景，他们提出索性改大一点，直接上分布式内存数据库。 问题是，如果没有人去控制这种场景，那么你的技术架构就会继续竖井化下去，类似情况也出现在去Ｏ上，华为说PostgreSQL去Ｏ，斯特奇说用MySQL去Ｏ，如果我们甲方不做云平台的管理，听谁的？如果不做平台化管理，经常某个项目组说用什么就引入一个什么。 提炼出服务以后，应用只需要知道用某种接口形式调用这个服务，但是不用关心服务具体是Redis实现的还是Gemfire实现的，又或者是MySQL实现的还是PostgreSQL实现的，他只要关心SQL接口,这样技术服务和技术实现就解耦了，技术实现的技术路线演进就由我们管控了 问题3：传统企业要实现王总规划的大云，涉及的内容确实很多，估计没有几家能有魄力有能力来实施。在没有实现数据中心级别的大云之前，如何来解决业务的发展与数据中心容量不足的矛盾？ 答： 我考虑先做PaaS资源池，做技术平台标准化,做一些总比不做好,云平台能力要先行，大云不可能一蹴而就，但我们能做一些，就向大云迈进了一步，越进步，资源利用率越高，开发越敏捷。 如何一起愉快地发展 这是一个新的时代！每个人都有自己的声音，值得被尊重，并且有机会被尊重。 高效运维系列微信群于2015年4月底创建，已然成为国内高端运维圈子，主力成员分布甚广，不仅来自互联网大厂，更有包括移动、银联、农业等各产业朋友。“高效运维”公众号值得您的关注。本公众号基本上每天一篇文章（90%为原创），来自高效运维系列群的讨论精华，“高效运维”也是InfoQ专栏《高效运维最佳实践》及运维2.0官方公众号。 来吧朋友，共襄盛举。 （编辑：天瑞地安资讯网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐