BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

朱锋:构建轻运维高可用应用的一些要点
录制于:

| 受访者 朱锋 关注 0 他的粉丝 作者 Qcon 关注 0 他的粉丝 发布于 2017年11月18日 | QCon北京2018全面起航:开启与Netflix、微软、ThoughtWorks等公司的技术创新之路!
17:11

个人简介 朱锋, UCloud高级产品经理, 于2015年加入UCloud,就职于UCloud基础云产品中心,任高级产品经理。主要负责云平台基础设施层相关的产品规划和设计。曾就职于三星电子、青云等公司,在云计算平台、虚拟化技术、SDN网络、分布式架构方面具有10年以上的丰富经验。

全球架构师峰会(International Architect Summit,下简称ArchSummit)是由InfoQ中文站主办的一次全球性架构师峰会。ArchSummit专门针对架构师人群,讲述与架构和架构师相关的各方面趋势、技术和案例。这也是继QCon之后,InfoQ中文站主办的又一次高端技术盛会。

   

2. 首先第一个问题是请您首先简单介绍一下自己,在Ucloud负责哪些工作?

朱锋:我是负责整个UCloud云计算基础设施平台的一个产品设计工作,这个平台里面可能会涉及到主机计算类的,包括网络类的和一些存储类的,这些工作我先后都曾做过,相对来说,对于整个UCloud底层的一些设计工作相对有一些了解。

   

3. 这次你演讲的轻运维和高可用的一个云产品的架构上的理解,能不能谈一谈业务高可用和数据高可靠云产品的理解?

朱锋:我觉得我现在我们在接入了这么多用户以后,我们观察到了用户的种种的一些行为、他们一些情况以后,我们深深的感觉到,对用户来说,高可用就是整个他们的生命线。因为他们的业务都是一个“时间就是金钱”。首先最基本一点,你的服务不能断,一旦断了的话,你直接损失,你的用户的流失,而且这个是很难挽回回来的,所以说我觉得首先你要确保说你的服务能够高可用这是最基本的一条,作为运维来说,我觉得作为整个系统架构的工程师来说,要做到两点,第一点你要保证这个系统的可靠性和强壮性,第二点,你要确保说这个系统的那个性能能够可以不断的去水平扩展。但第二点,如果你暂时解决不了,你可以通过一种临时的方法,就是你不断的去堆资源,那么短时间之内也能扛过去。但是第一点你的高可用做不了,你一旦挂了,你整个公司的业务就挂了,这是高可用方面的一些观点。说起高可靠这块,我觉得之前整个行业里面对这块的认识还不是很深入,相对来说,比较局限和浅显,所谓的数据高可靠,我们之前是把它关注在说,数据的一个持久性的存储上,以前某个介质,软盘不可靠,软盘不行,我们换硬盘,硬盘现在不断的把它存储的持久性做高层级,几个九再往上做六个九七个九,我们更加关注说介质本身的一个持久性,然后就把它定义为高可靠的全部,这个相对来说是比较局限的,我们现在发现说就是用户对高可靠有各种各样的需求,因为现在大数据时代你的数据是越来越多的,你可能你的数据的交互方式,和其他用户的交互方式是越来越丰富,你是需要考虑一些更加丰富的场景,去发挥你的想象力的,以前我们可能很少看到说,用户说有大量的数据去需要短时间里面去恢复,那你现在4G的时代,你的网络跟你原来2G3G的量就不是一个量级了,你原来的性能觉得OK的,如果你的数据量翻10倍,那你的处理时间是不是够的上,这是一个问题。第二个问题就是说,比如说你原来说没有频繁的跟其他用户去交换数据的这样一个需求,你现在大数据,很有可能面临这样一个挑战,你怎么用安全的、可信的方式去跟用户去交换数据,这也是可以理解为是高可靠的一部分。

   

4. 网络对云产品的影响很大,你能不能介绍一下在复杂网络环境下是如何实现的?

朱锋:这个问题很大,我们分几点去看,第一个,首先你要去做拆分,你要解决客户网络这么复杂环境,你必须要把问题简化和分解,第一个,把整个网络进行拆分,变成一个单个原子化可控制的单元,你对每一个单元你都要做好高可用的设计。第二个,你要去做一个分层,就是说这样的话,每一层之间的逻辑是很清楚的,这样的话,你可以做到不同层之间的解耦,这是现在系统里面很关键的一点,你做了分层的解耦之后,互相之间的依赖就少了,你改其中一部分的逻辑,你就不会影响到其他层的运行,这样的话,对你的整个高可用是提供了很好的帮助的,另外一个就是说,如果你做好了前述的这些工作,你过可以发现你的精细化控制的能力会提高,就是说你每一个模块你做完分层以后,你都可以对这个模块去做一些进行管理,或者说敏捷迭代,或者说那些快速的灰度的能力,这样可以让你及时发现问题、修正问题,可以在你整个问题扩展到全局,影响到你整个大局之前,你可以把它发现掉,修复掉,这是第三块是个局部的精细的运营能力,第四个高可用做得时候,一种比较简单粗暴的方法,你就追求极致的高可用了,因为这种东西有的时候就像一个三角形一样,你是没有办法去全都达到,那有可能倾向如果说,你非常倾向高可用的时候,你可能必然会牺牲一部分性能作为代价,或者怎么样,我们在这方面是尽量希望说你做到高可用时候,还要去保证性能,我觉得性能上面也是一个非常重要的考量,如果在复杂的网络环境下,你如何去通过一些比较先进的技术方案去实现说,高可用不仅可以扩展,而且你的性能不会因为你的设计,造成说你有大幅度的下降。

   

5. 那么如果说云服务做到了业务高可用,和数据高可靠,是不是用户就不需要运维团队了,会为目前的运维带来哪些影响?

朱锋:我个人认为,运维这个工作是可以很广泛的,包括它,我们是希望说,把那些脏活累活我们给接过来,我们是希望说,用户的运维可以去解放一部分烦琐枯燥和一些对他们来说是非常高风险的一个事情,就是我们通过底层去帮他们去解决掉这部分的问题,因为一个公司的运维团队即使再大,它也不可能说它会触及到各种方方面面的知识,我们因为运营了更加多的用户,这些经验的积累可以帮我们抽象出更好的高可用的产品,我们把这些事情做了以后,运维可以在这方面的精力去节省下来,他们可以投入到更加有意义的一些更加高层次的运维工作,做一些自动化,或者做一些敏捷,或者做一些看看,他们有精力的话,他们就可以去做一个运维去驱动研发的一个工作了,因为之前的逻辑基本上都是前端驱动后端的,就是老板驱动业务,业务驱动研发,研发驱动运维,大家都是一个很被迫式的一个响应,但是都是非常被动,也是非常累,但如果你有时间把这些高可用扔给别人以后,你反过来想想说,你的研发架构合不合理,你有没有值得改善的地方,反过来去推动他们,因为你有这个时间和本钱了。

   

6. 最近关于云服务的,在使用云服务的时候的数据,安全问题不断的被爆出,那么实现云上的用户数据不间断的保护有哪些难点,如何解决?

朱锋:不间断保护这个事情呢,就是说,我觉得一个是说,你要去做一个不间断保护它是很好,但是第一个难点,它不能去影响用户实时的IO的性能,因为之前做那种快照,一般的快照的时间,我在一个用户的服务器的业务的低峰区去做快照,因为快照必然会面临一个抢占它原有业务的一个IO的一个问题,所以说这是一个很大的考量问题,就是说你后台要有一种非常聪明的方式去说,可以把你的用户的实时读写去很有效的转发到后台的一个处理机群,这样让另外的一个单独的机群去处理,而不是用它原有的计算资源去处理,这是一方面,第二个方面,就是说,我觉得说你如果有办法做了一个实时的保护,第二个问题就是说你在需要的时候,你要能够快速的恢复,如果说你做的菜很好吃,你去一个饭馆吃饭,中午饭很好吃,你去那边定一个饭,但是他告诉你要说厨师还在做,你要等一等,等到晚上时候才做好,你说我们先吃晚饭吧,那肯定是不行的,你需要的时候,你必须要很快速的能够去回滚,去让他有一个很简单的方式很快速的去回滚。第三个,对用户的可操作性上来说,我们要做一些改善工作,因为即使你真的碰到这种事情的时候,都是非常头大的,因为这种事情,不动则一,不鸣则已,一鸣惊人,像病毒或者勒索这种事情一旦发生了,它就把你的核心数据给搞丢了,你必然是焦头烂额的,你当时如果你的工序非常复杂,复杂的工序本身又会带来额外的出错,我觉得在这种实时保护性上,你需要后台做大量工作,让前端工作能够尽量简单。第四个,还是说,我刚才提到的,就是说你的性能和容量的问题,你现在可能说,现在就是我们数据方舟恢复能力已经很不错了,因为就是1T的数据,假设20到30分钟之内能恢复,如果你数据小一点,可能我5分钟就能恢复,对你来说,你的业务已经感觉到很欣慰了,如果你的数据再多,如果你的数据量翻10倍,翻100倍,将来有一天,到数据能够让你到PB级的话,你这个数据又会有一个瓶颈,这个挑战是不断的在往上的,用户会不断的推动我们想办法做更高更快更好,这方面也是难点也是始终存在的。

   

7. 能否分享一下最近使用UCloud部署业务,让你觉得有挑战的案例?

朱锋:我们有挑战的案例,相对来说,这个用户,就是说它的业务种类很全,首先它对我们来说,它的资源使用量非常大,这是第一个,第二个,它自己的模块划分非常的精密,它这方面已经做得很好,就是他做了很多模块化的设计,导致说它可能,同一批云主机里面,它的实力里面有很多的互相的关联关系在里面,这是第二个。第三个,可能它原来,他是把资源集中部署在一个机房的,所以说这样的话,我们要把它给他做高可用,我们需要帮它做一个流程分解,第一步,你需要先搞清楚,它互相的一个业务的顺序,然后可能需要分解成几百步,每一步,你可能上某一个模块,关系OK的话,你再走下一步,整个一百步的流程,您演练剥开了以后,你可能再去想办法去通过这样一个流程固化以后,你再去另外一套机房去帮他重新搭一套一模一样的架构出来,这个里面挑战是非常大的,因为这个东西的挑战在于说,你的量大,但是你必须要去把它做掉,而且你要在不影响任何业务的前提下去做,你不能做一个很粗暴的说,因为搞不定,我把其他的业务停机,这个是不能做的,这个工作量是巨大的。

   

8. 意味着是否对于这次业务来说,上云的化需要做一些重构?

朱锋:有些情况是需要的,但是我们尽量希望不重构,我们提供产品的思路就是说能够通过各种产品,比如说我们的VPC,那些自定义网段那些功能,就是自定义网段,举这个例子来说,自定义网段可以让用户配他想配的任何IP,就是减少用户重复的工作,因为它原来机房用什么IP,现在我们这边也可以用原来的配置,尽量去想办法去减少它重构的一个工作量。

   

9. 最后能否请您分享一下对于业务高可用和数据高可靠的这个技术的发展趋势?

朱锋:这些都是我个人一家之言,也只是抛砖引玉,我们其实在众多的用户实践中,我们感觉可能说,整个趋势来说,用户一方面我觉得高可用这个东西会越做越细,越做越全。一开始,最早的时候大家只会关注核心的点,因为核心的点你都没有解决,你没有资格谈其他的东西,最开始核心点是什么?可能就是一个服务的入口,比如说负载均衡,最早就有那种,市面上有那种硬件的负载均衡,性能又好,可靠性又高,把这个东西一层一层做完以后,你会发现内网又会有类似的问题,想办法,内网也搞一套HA的方案,用户有什么成熟的keepalive或者其他东西出来,你会发现说,因为一个木桶效应,一旦说你能做到很好的一个原子化的定义,你会发现其中某一个模块,到最后你都必须要让它去保证做高可用,这时候你会越做越细,会让你越做越全,这是一个趋势,第二个趋势尽量去把它做包装,就是说平台化的包装,就是说你有这么多的模块要管,作为运维,他必然会面临问题我管不过来,怎么办?我觉得一种思维,上升让云平台去管这个事情。就说我们想办法把其中一部分可以做高可用的产品给产品化了,让你直接去用,数据库,我们做了一个高可用的数据库,你就自己不用去搭了,从产品层面我们想把你自己运维的产品做个高可用版本,帮你去解决,这是一种思路,第二种思路,现在也是比较流行的方法,我尽量通过一种更加抽象的方式去给你提供服务,比如说现在的一些比较火的Docker,谷歌的kubernetes,因为原来你要去专注到具体某一个业务模块上的可用性,那我现在就把这些东西组合打包起来给你,像kubernetes它就是自己后台通过负载均衡,通过一些那个节点的生命周期的管理,地址注册,服务注册那些东西,那就把你整个一整套的东西都包好了,那你就不需要考虑单个其中一个负载均衡需要怎么样,或者数据库需要怎么样去活,你只要说把你的业务扔上去就可以了,尽量把它给打包去提供,这也是另外一种思路。然后数据高可靠方面,我刚才也提到,就是说,我们要不断的扩展我们的想象力,我个人感觉,因为我们从硬件介质来说,我们持续性能力现在的已经做得很好了,但我们想办法去扩大那个数据高可用的场景,原来用户觉得我只要数据存在那边,我就放心了,我自己烦一点就烦一点。后面他会觉得说,你能帮我把这个一键化的事情做掉,或者是自动化的事情做掉,就感觉很不错了,现在可能说,它有一些新的场景,是不断的延伸的,你要想办法去适配,我刚才讲的,你之前可能你更多关注自己的数据,你自己保证好你的数据不丢,或者是不被入侵,不被感知就可以了,那你现在你的新的挑战,你跟其他用户有了这么强的数据交互以后,这块东西原来是没有定义的,你要确保说,你跟其他用户交互数据的时候,你要有一个比较好的一个安全的范式,确保说我的这个数据,不仅是说技术层面上的一个高可靠,从法律层面,或者从其他角度,我也不能被其他用户轻易的感知到,篡改到,利用到,这方面也是有需要的,我们也在对此做一些思考,比如说我们最近做了一个安全屋的产品,就是解决这方面数据可靠性方面的问题。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT