云儿飘啊飘的推荐 | LOFTER（乐乎） - 每个人的理想国
LOFTER for ipad —— 记录生活，发现同好
云儿飘啊飘 的推荐
&nbsp&nbsp被喜欢
&nbsp&nbsp被喜欢
{list posts as post}
{if post.type==1 || post.type == 5}
{if !!post.title}${post.title|escape}{/if}
{if !!post.digest}${post.digest}{/if}
{if post.type==2}
{if post.type == 3}
{if !!post.image}
{if post.type == 4}
{if !!post.image}
{list photos as photo}
{if photo_index==0}{break}{/if}
品牌${make||'-'}
型号${model||'-'}
焦距${focalLength||'-'}
光圈${apertureValue||'-'}
快门速度${exposureTime||'-'}
ISO${isoSpeedRatings||'-'}
曝光补偿${exposureBiasValue||'-'}
镜头${lens||'-'}
{if data.msgRank == 1}{/if}
{if data.askSetting == 1}{/if}
{if defined('posts')&&posts.length>0}
{list posts as post}
{if post_index < 3}
{if post.type == 1 || post.type == 5}
{if !!post.title}${post.title|escape}{/if}
{if !!post.digest}${post.digest}{/if}
{if post.type == 2}
{if post.type == 3}
{if post.type == 4}
{if drlist.length>0}
更多相似达人：
{list drlist as dr}{if drlist.length === 3 && dr_index === 0}、{/if}{if drlist.length === 3 && dr_index === 1}、{/if}{if drlist.length === 2 && dr_index === 0}、{/if}{/list}
暂无相似达人，
{if defined('posts')&&posts.length>0}
{list posts as post}
{if post.type == 2}
{if post.type == 3}
{if post.type == 4}
this.p={ dwrMethod:'querySharePosts', fpost:'1d615e74_959fcc8',userId:1650023,blogListLength:30};点击上方蓝色文字直接关注
本文根据高效运维系列群「运维讲坛」的嘉宾分享整理而成。运维讲坛，邀请国内运维领域优秀技术专家作为分享嘉宾，其中线上分享每周一次，线下沙龙活动每月一次。
欢迎点击上面蓝字，关注“高效运维”公众号以了解更多运维讲坛活动、并抢先赏阅原创文章，详情参见文末。编辑王玉平@UCloud（收集 & 编辑 & 发布）嘉宾介绍王晓征 中国移动通信集团浙江有限公司信息技术部总经理助理，主讲嘉宾。目前在浙江移动信息技术部分负责应用运维和平台架构。1997年毕业于浙江大学电机系工业电气自动化专业，机缘巧合加入了浙江移动一直工作至今。走管理路线之前，干过开发、系统管理员，不过大部分精力在做DBA。其实我学生时期主要梦想是做职业足球运动员，可惜我那个时代浙江没有职业球队，大四那年浙江组织半职业球队参加乙级联赛，我入选混了一年，也算在中国足协注册过，潇洒走一回泡一个赛季。汤人杰，中国移动通信集团浙江有限公司架构师，助讲嘉宾。张式勤、陈挺、郭岳和钟储建对本文亦有贡献。内容提纲中国移动云计算愿景；云计算核心技术；云的进化论；云计算建设反思；浙江移动云计算发展的一些思考；核心观点总结。分享内容中国移动云计算愿景早在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就完了，那是土老帽干的事。云计算是有规模效应的。资源池越多，资源利用率越低，建设运维效率越低，云计算的效果越不能有效发挥。好的云计算公司技术架构完全可以做到大一统，整个公司一个大集群，但是出于管理目的去分为多个资源池，那也基本接近一个资源池一个大集群。很多壕公司呢？管理随意，可能历史原因资源池就是以部门或者项目组来划分的，这是与云的思想背道而驰的。此外，技术架构不标准，不统一，落后，说是一个资源池，里面资源互相不能共享的小集群数量说出来都吓死人。这种情况却很少得到重视，也很普遍。浙江移动云计算发展的一些思考第一点，要实现大云。要有很多技术突破的，比如说前面的一个好汉三个帮，四大技术。或者再聚焦一点，分布式调度和分布式协调。谷歌那样的高大上技术控公司自己研发，我们土鳖公司怎么办？现在其实有机会的，很多这方面的技术产品已经开始逐步有开源解决方案，这就是我们中国技术圈的机会，要关注起来！第二点，传统的技术架构基本可以用IOE架构来代表。这种环境下，很多甲方技术团队其实只要按照乙方提供的方案落地，运维好就是大牛。比如说我带的团队，把Oracle数据库升级搞得炉火纯青，风生水起，但再升级也是O不是？现在直接提数据库开源化，直接把O给你去了，你说你怎么办？而且合作伙伴这个说PostgreSQL那个说MySQL，最终还得你自己做决定，自己走出自己的路，这个压力是完全不一样的。而且IOE代表着按部就班，去IOE代表着迭代思想，管理思路都不一样。当然，不一定去Ｏ就对了，只是一个举例。其实除了BAT以外，目前传统的行业IT技术发展相对较快就是银行和运营商，总体感觉云化基本都在IaaS资源池化和应用资源池化的阶段，建行最近做了PaaS，但也是真正大云那种。上图是我们自己近期做的一个云计算蓝图，还很粗略。做这个服务的目的是把技术服务和技术实现解耦，应用只需要知道他需要订购的技术服务。以下是几个概念：IaaS—-IaaS资源池化—-小云APaaS=TPaaS、DPaaS、BDPaaS—-PaasS资源池化—-中云IaaS+APaaS=技术服务层EPaaS=控制层—-控制标准化—-大云我们做这个规划，着重规划了PaaS层服务能力，希望突破近年来云平台长期处于低水平IaaS级建设的束缚，有望将虚机级弹性伸缩扩展到集群级，初步提升资源利用率和费效比，同时在快速部署开通、有效敏捷支撑业务获得明显提升。直接提出EPaaS（数据中心操作系统）的规划，希望能实现深度的弹性伸缩、提高资源利用率、降本增效，为真正实现数据中心级“大云”迈出坚实的一步。这是我们初步考虑的浙江移动云计算架构蓝图雏形，还在修订中。上图只是画到服务的颗粒度，落地层面，一个服务不一定是一个产品，也可以对应多个产品。其实PaaS里面还可以放更多的内容，比如说FaaS，但是我们量力而行，不敢过于好高骛远。EPaaS本质上核心内容和阿里的女娲和伏羲思路很接近，但之所以把他们画在PaaS层，是由于我们想突出他们对应用标准化开发的意义。我们在规划这个蓝图的时候也遇到一些困扰。比如说，纠结什么是一个技术服务？例如阿里的DRDS和RDS为什么是两个服务？一个DRDS如果底层有Oracle，MySQL，PostgreSQL三种产品支撑，为什么还能被称为一种服务？如果内存数据库有朝一日发展到和关系型数据库访问接口完全一致了，为什么还要单独列为一种服务？说白了，到底从哪些维度去定义一种服务？核心意思是，可以考虑尝试一下ZooKeeper、Meso和Yarn。当然，我觉得不太容易，这些技术都好潮，特别是对于我们低小下的运营商来说，实现起来还是比较麻烦的。我们考虑，逐步从第三阶段向第四阶段演进。把重心从应用云化这种私有化竖井化的云化思路中解脱出来，改为优先建设PaaS云平台，然后在推动应用向云平台的迁移改造，大力推动能力平台化。同时，建立云平台服务和产品目录管控机制，将云平台能力标准化、服务化和规范化，杜绝以项目组为中心的七国八制的技术架构，推进技术架构标准化。其实，就和阿里云一样，应用要使用数据库不是项目组可以随便加的了，原则上得考虑使用云DRDS上已经具备的能力，比如DRDS。当然，如果你不喜欢目前MySQL的DRDS，你能说服云计算团队，可以加一个PostgreSQL版本的DRDS。阿里就是这么做的，我们也是这样。核心观点总结X86化，虚拟机不等于云化，PaaS资源池化和核心云构件EPaaS的建设才能实现真正意义的大云，这一点对企业私有云意义尤其重大；大数据技术平台的整合发展，轻量级虚拟化技术，Hadoop和Docker的融合、ZooKeeper和Mesos技术的发展很有可能成为未来一段时间内云计算架构演进的重点；应用云化的提法很有可能已经过时，后续可考虑改为云平台建设+应用上云；云计算推广和建设应摈弃传统的自上而下的竖井式做法，改为自下而上的平台化视角；从企业整体视角，资源池应有两统一分（技术架构统一、管理平台统一、安全管理区域）的整体理念，而不是简单的以部门甚至项目为单位切分。最后一点是关于技术团队管理改革思考，如上图所述。Q/A问题1：您这边费这么大力气，建这么大的中云，动力是什么？感觉挑战应该非常大。 答： 我们这些年遇到了很多挑战。比如说，核心能力的丧失、技术架构的竖井化、应用建设的缓慢和资源池利用率低等。作为体制内的老IT，我希望能为这些多年顽症的解决，出一点力，希望能推动这些问题的解决，但体制内也只能一步一步来。算我有一点技术情节吧，我这个人有时候看到那些问题在哪里，就是有去解决的冲动。有人问，你为什么要登山，答曰，因为山在哪里。对吗问题2：“做这个服务的目的是把技术服务和技术实现解耦，应用只需要知道他需要订购的技术服务”这个解耦，能再更生动具体的例子么 答： 我姑且举一个例子，我们的一个核心系统里面用到了缓存技术，我就遇到过这样的事情，在线系统是A项目组承建，采用了MEMCACHE。现在该系统要改造，项目组提出换REDIS。Ｂ系统，Ｂ项目组承建，类似场景，他们提出索性改大一点，直接上分布式内存数据库。问题是，如果没有人去控制这种场景，那么你的技术架构就会继续竖井化下去，类似情况也出现在去Ｏ上，华为说PostgreSQL去Ｏ，斯特奇说用MySQL去Ｏ，如果我们甲方不做云平台的管理，听谁的？如果不做平台化管理，经常某个项目组说用什么就引入一个什么。提炼出服务以后，应用只需要知道用某种接口形式调用这个服务，但是不用关心服务具体是Redis实现的还是Gemfire实现的，又或者是MySQL实现的还是PostgreSQL实现的，他只要关心SQL接口,这样技术服务和技术实现就解耦了，技术实现的技术路线演进就由我们管控了问题3：传统企业要实现王总规划的大云，涉及的内容确实很多，估计没有几家能有魄力有能力来实施。在没有实现数据中心级别的大云之前，如何来解决业务的发展与数据中心容量不足的矛盾？ 答： 我考虑先做PaaS资源池，做技术平台标准化,做一些总比不做好,云平台能力要先行，大云不可能一蹴而就，但我们能做一些，就向大云迈进了一步，越进步，资源利用率越高，开发越敏捷。如何一起愉快地发展这是一个新的时代！每个人都有自己的声音，值得被尊重，并且有机会被尊重。高效运维系列微信群于2015年4月底创建，已然成为国内高端运维圈子，主力成员分布甚广，不仅来自互联网大厂，更有包括移动、银联、农业等各产业朋友。“高效运维”公众号值得您的关注。本公众号基本上每天一篇文章（90%为原创），来自高效运维系列群的讨论精华，“高效运维”也是InfoQ专栏《高效运维最佳实践》及运维2.0官方公众号。来吧朋友，共襄盛举。重要提示：在本公众号发布2天后，才能转载本文。请必须全文转载，并包括本行及如下二维码。　
　文章为作者独立观点，不代表微头条立场
的最新文章
三墩IT人于日前正式试点成立私有云SRE团队，对于云运维和云平台架构的演进有着重要的意义。12月10日浙江移动成功完成CRM系统在DCOS平台的首次正式接入，并已稳定运行一周。看完第一部分的同学们想必已经迫不及待了，今日奉上第二部分译文，介绍 PG 更重量级的特性，还不快点开？！CookBook译者之一francs再出技术译文力作！本系列分为两个部分，今天推送的是Part1。三墩IT人诚招精英！三墩IT人诚招精英！三墩IT人诚招精英！重要的事情说三遍。2000多万行代码，代码构建发布一次需40多分钟，各应用之间错综复杂，集中提交代码模式下构建发布失败率超过20%！为此，我们必须在DevOps工具链上做些实践探索，才能深化敏捷转型。浙江移动云架构师钟储建，在Mesos Meetup北京技术沙龙第三期研讨会上，做了题为“浙江移动Mesos实践”的技术交流分享。消息队列服务作为云平台重要的PaaS层服务，是后续系统中心化、服务化演进架构中服务异步调用的基本组件。浙江移动针对目前市场上主流的商用、开源产品进行了产品选型验证。浙江移动数据架构师三少，在2015 Oracle技术嘉年华现场做了题为“浙江移动容灾备份实践”的技术分享。三墩IT人此次技术分享北京之行圆满结束。三墩IT人专家代表，《PostgreSQL 9 Admin Cookbook》译者之一的谭峰，在2015大象会上做了题为“浙江移动PostgreSQL-XC应用实践”的技术分享。三墩IT人全新启动技术翻译专栏，本次翻译的是《高性能MySQL》一书的作者Baron Schwartz于11月12日在其博客上发表的文章“What Does The Universal Scalability Law Reveal About MySQL?”基于OpenStack的KVM虚拟机在运行时会出现CPU利用率过高的情况，三墩IT人针对此异常问题进行了分析、研究和优化，取得了较好的效果。在此，我们会将处理方法和经验以系列专题的方式分享给大家。日23:08，浙江移动首个运行在DCOS架构的生产系统——手机营业厅系统迁移割接成功！标志着三墩IT人承建的IT私有云正式具备了向整个企业内部的IT应用系统提供资源集中动态管理服务的能力！三墩IT人敏捷能力提升之路持续推进，且看首位女子“破风手”的敏捷成长之路。三墩IT人正在从传统的瀑布式开发向敏捷开发模式转型，为检验前期敏捷化探索的效果，开展了敏捷能力提升系列活动，并于10月完成第一期“敏捷看板站会”竞赛。如何应用手中的数据资产，指导其日常运营，战术和战略制定，提供更好的产品和服务、降低成本，控制风险成为组织和企业的首要问题。数据资产管理当前已经成为IT业界的一门新兴学科被广泛研究。9月19日，象行中国 2015 PostgreSQL 技术交流会杭州站活动举行，谭峰做技术分享此次会议标志着中国移动实现数据中心级弹性调度能力、提升云计算技术自研水平迈出全新的步伐汇总收集以下 PostgreSQL 中文资料，希望这些中文资料能够方便有需要的朋友，降低 PostgreSQL 的上手门槛该开源云平台的上线投产打破了商业虚拟化产品一统天下的局面，标志着三墩IT人在云化技术领域的核心能力自主掌控又向前迈出了实质性的一步业界首次对PostgreSQL 9.5 新特性的成体系研究，供业内PostgreSQL爱好者学习探讨6月26日，三墩IT人与惠普公司技术团队进行了下一代数据库Trafodion的技术交流传统行业工作多年的IT人对云计算的一些思考重点职位推荐：技术架构师（云平台/大数据）、技术工程师（云平台/大数据）、运维开发工程师随着7月1日8:00:00的到来，浙江移动IT系统顺利完成了2015年闰秒保障浅谈其实是深剖，运营商去IOE的经验值得传统行业借鉴大数据时代既推动了运营商的数据管理变革但又带来了压力，数据管理工作挑战巨大汤人杰受邀在全球架构师大会上分享“浙江移动云计算技术实践”系统管理员感恩日是由系统管理员泰德.凯克托斯所创立，定于每年七月的最后一个星期五，主要是感谢系统管理员及其他科技工作人员的辛劳SanDunIT移动改变生活，技术影响未来；我的三墩，我的IT。热门文章最新文章SanDunIT移动改变生活，技术影响未来；我的三墩，我的IT。