实践课堂|如何使用云端资源构建一个高可用、可伸缩的后端系统



  • 主持人:各位QingCloud的小伙伴,大家好。非常荣幸今天邀请到这么多小伙伴参加QingCloud实践课堂,我是QingCloud华南区的客户经理。实践课堂的第一季和第二季,我们选择在深圳启航,这是QingCloud对深圳的偏爱和对深圳朋友的期待。我们希望通过本次活动,邀请大家共同交流,让大家近距离、更直观的认识QingCloud、了解QingCloud。

    QingCloud,全球首家首先资源秒级响应、按秒计量的基础云服务商,致力于提供安全可靠的服务交付平台。QingCloud提供私有云和公有云服务,目前服务超过4.5万家企业,在中国运行11个数据中心和骨干网,今年计划新增5个数据中心。

    接下来,青云QingCloud CTO 甘泉将分享如何使用云资源构建高可用的可伸缩的后端系统,有请。

    1274568896.jpg

    演讲内容

    甘泉:今天是第二季实践课堂,去年是第一季。那时候QingCloud还刚刚在企业立足,基本没有PaaS服务,我们在IaaS做得比较多。今年我们有PaaS服务也会比较完整,整个云平台也会显得比较完整。深圳团队也发展壮大起来了,今天的主题有很多是深圳的研发团队做的。这次我们像到了主场,上次感觉自己像是客人。

    今天的主题是如何使用云资源构建高可用、可伸缩的后端系统。我们的同事王煜谈过这个主题,你们可以在网上搜索这个主题的内容。他从用户使用角度构建高可用、可伸缩的系统。今天我会从QingCloud开发者的角度,从一个QingCloud工程师的角度理解在云上高可用、可伸缩的后端系统。

    首先,IaaS层高可用,这是一件很自然的事情。QingCloud一开始就是做IaaS的,我们之所以做IaaS,我们的理念是从IaaS往上做,做到PaaS、SaaS。IaaS层的高可用对我们而言至关重要,也是我们做IaaS最大的挑战。我跟很多人沟通,很多人认为IaaS并不难,无非实现虚拟化,我理解到它确实不难,难在如何做IaaS时交付高可用的虚拟资源。IaaS要做的是接管对物理资源的管理,屏蔽物理硬件的复杂性。高可用虚拟资源包括几个层次,这里PS指的是物理存储,我们附加的是数据不能丢。对用户来讲,也许可以随便换物理机,但数据不能丢。我们要给用户虚拟网络,地址不能变,因为地址从用户的角度来讲,这是virtual machine的唯一标识,相当于他的身份证,不管拓扑、物理网络如何变化,这是不能变的。我们提供的资源还是machine,但它的内涵发生了深刻的变化,它是一个virtual machine的概念,它的能力本身是一台高可用的主机,不再是纯粹意义上的物理主机。物理主机可以关,虚拟主机是一直都在的。

    如果说IaaS只是实现高可用有很多办法可以做,我们遇到很多困难,这些困难是后面的附加条件造成的。除了要实现高可用的主机外,还要满足这些条件,你要满足高性能的条件,这个性能不仅仅是比竞争对手高一点,而是高很多,至少在当时要高很多,同时要实现秒级调度,它要是高弹性的主机。为什么要做秒级调度,我后面会谈到,这跟可伸缩有直接的关系。这些条件在我看来是相互矛盾的,你实现高可用,这时候意味着如何实现高性能。实现高性能,如何实现灵活调度,能够秒级创建、秒级销毁。我们当年花了大半年想我们用什么样的办法做这个方案。

    备份,备份是长时间,大尺度的机制。它对于IaaS的高可用是显而易见的,起着非常重要的作用。

    PaaS层的高可用,假设我们有高可用的IaaS平台,为什么我们还需要PaaS层的高可用?如果有PaaS层的高可用,为什么还需要IaaS层的高可用,在很多人心目中都是疑问。能否跳过IaaS,直接做PaaS,很多人这么做,同时置疑QingCloud在IaaS层上花这么多时间是否值得,我觉得值得。PaaS层的高可用,举例子LB,对公网流量的处理,一个公网IP进来可以由很多LB处理分流,在每一个LB上做交流,不会影响整个公网IP流量的处理。RDS、BIGDATA也非常容易理解,自己有机制。BIGDATA更加明显,BIGDATA天生是Cluster System,包括Storm、Kafka、这是天生设计时就要处理集群系统。你会看到很多PaaS有自己的高可用,是否需要IaaS的高可用,这里需要探讨IaaS的高可用和PaaS的高可用之间的关系是什么?分几个层面来讲。

    一是从网络角度来讲,PaaS的高可用附着在IaaS的高可用上,没有独立的PaaS高可用网络存在,我们所有的组件,包括LB、RDS、BIGDATA所有的网络高可用基本上都是基于IaaS的,不会有一个纯粹的PaaS Network System。我看不出来这样的意义所在。

    二是对于PaaS而言,存储的高可用是否需要用IaaS?这在于Application的设计。IaaS的存储和PaaS的存储之间是松耦合的。如果你用了Application,可以不用IaaS层的Application。它本身在Application层的存储有备份,我可以不用Application。这个世界上有很多Application本身并没有具备Application的能力。我们对没有能力的Application,我们同样有存量备份、增量备份。对我们而言,PaaS存储的高可用和IaaS的高可用之间是松偶合的关系。IaaS和PaaS之间也有强偶合的关系,松偶合是存储。如果你要跳过IaaS做PaaS,我只能祝你幸运。

    跨机房高可用,这是我们今年的重点。我们在建设北京3区的环网、骨干网建设,基本上已经投入运行中,正在部署基于同城管网的Application应用。跨机房高可用首先是数据优先,要面对IaaS如何处理灵活的,基于本数据中心以及异地数据中心的灵活配置。我在本数据中心有两份拷贝,同时在异地数据中心还要有一份远程拷贝,他们之间所要求的备份力度也许都是不一样的,你必须有一种机制支持调度。你需要几个Replication,我在本数据中心有一个Replication,我在另一个数据中心也有一个Replication,才有可能实现数据优先。我们骨干网和环网的重要就是基于这个。

    拓扑管理,当我们网络准备好了,我们要完成管理,把数据中心A,用户所创建的拓扑无缝搬到数据中心,这不是靠手工做,而是靠代码管理或是复制、延伸这边的,从A复制到B,实现二数据中心的高可用。

    可伸缩,我要谈谈可伸缩的前提。谈到可伸缩,我们会想什么样的系统是可伸缩的,IaaS对于物理资源的屏蔽,这是可伸缩的前提之一,而且是非常重要的可伸缩前提。我们知道物理硬件没什么可伸缩的能力,我们需要用IaaS将物理硬件屏蔽掉,呈现出高可用的virtual machine,不管什么样的machine,这个machine本身脱离物理硬件。只有做到这一点才能做到可伸缩,这是我们必须做IaaS,不能跨过IaaS做PaaS的原因。

    秒级计费和秒级调度,我不想说太多,但总有人说。前几天看到有文章批判用户根本不需要按秒计费、按秒创建虚机。我按分钟级、小时级,一点问题都没有。如果我没有按秒计费,如果我都是包年包月,你如何做弹性扩张。如果业务量来了,需要把系统扩大,如果系统扩大,你需要下个月1月1日才能生效,这对我来说有什么意义。如果我不是包年包月,但是我的资源调度不是秒级的,我需要你做弹性扩展或是收缩,你就能做到,5至10分钟后,这对我和用户而言是难以容忍的。我们做这些的目的不是为了让自己看上去很炫,而是为用户的需求着想。只有实现这两点,才能说我的系统可以伸缩。一是IaaS
    对于物理资源的屏蔽,二是秒级计费以及秒级调度,这是用户实实在在的需要,希望大家能理解。

    轻量化,出现一种声音说容器的出现让KVM走向末路,说容器统治一切。为什么我们不能和平共存,为什么非要A代替B,B代替C。QingCloud从来没说这样的话。我理解容器跟KVM之间的关系。如果从功能完整的程度或是对你的束缚程度来讲,物理主机对功能的完整性是最高的,因为你以前想做的事情在物理机上都能做。VM是其次,VM提供的是完整的操作系统,包括你可以控制操作系统的硬件,可以随意操作操作系统的硬件。unikernel比较有意思,它比KVM轻量,但它有它的束缚。这意味着如何改造Application,合并后上下文本交换节省了时间,效率会更高。但是它带来的是你需要变成unikernel化的Application才能跑。

    container,它得做轻量,也是束缚最大的。我的隔离怎么做,因为container附用Kernel,如果我不给你权利,意味着你什么都做不了。这是一个矛盾。对于用户而言,我们要跑Docker,你要遵从一个Docker里只能跑一个,意思是从左到右,我们的功能会越来越受限制,但是它会越来越轻量化。如果这么比较就会知道他们之间根本不是取代关系,根本不是“你死我活”的关系。我们作为云平台,我们要把用户如何布置Application留给用户,而不是你强制用户使用什么样的部署方式。用户业务中的适合container,可以跑container,如果适合跑KVM,也可以跑KVM。你这样做是不是因为你懒惰呢?这是QingCloud的看法,我认为这几项都是应该由云平台支持,这是QingCloud对于容器以及KVM的看法。

    组件化,我们有Load Balancer、ZooKeeper、MySQL、Memcached、PostgreSQL。我是做编程的,我愿意把他们类比成在编程语言经常看到的,比如函数、OOP、对象、存储过程。当你需要一个服务的时候,比如我们需要一个Hadoop的服务,实际上我们给你一个Hadoop的对象,你在操作的方法,实现它的功能。我们会给你一个Hadoop对象、Queue对象等,这些都是组件,你可以想像成什么都可以。
    组件干什么用?把他们串起来是什么?API,在我的眼中,API是我们的编程语言。我们的IaaS、PaaS以及自动伸缩所有的一切都是通过API完成的。现在已经有超过300个API,也就是我们有大概各种各样的方法控制和调度我们的IaaS层。当你有组件、API、灵活强大的IaaS、轻量化的machine、服务等,把这些串起来才谈得上可伸缩。对于QingCloud而言,我们一直做的是遵循这个理念,把这个东西一步一步的实现。这些实现都不是一天一上线就能完成的,这是一步一步累计的。直到现在才敢说QingCloud可以实现可伸缩平台。

    我谈到很多东西,比如我们对于物理硬件、上层软件,我们的编程软件、组件、对象,我们在做什么?QingCloud做的是云计算时代的操作系统。操作系统在做什么,Kernel在做什么,大家都在用Linux Kernel,它操作的是硬件,你底下的硬件对于Kernel而言都是一个个控制者。对象调度Application,只是我们的维度比单机版的要大得多。我们在数据中心的层面做操作系统。

    我们跟硬件之间的关系就是这样,Software is the brain!Hardware is the muscle。

    回到主题,为什么要使用云计算构建后端系统?在我看来我们可以实现更便宜、更灵活、更可靠、更强大。如果你不细或是我们没做到,那是我做得不好,我道歉。QingCloud正在努力让自己变得更好,谢谢大家。

    Q&A

    提问:用了很多组件搭建环境,QingCloud可以提供组件的服务,把几个组件串起来,有没有案例给我们展示?比如Hadoop等各种组合起来。

    甘泉:(上图)是如何在云上构建复杂的云计算以及企业运用的PPT里谈过,这个运用是一个例子。我们标出来的都是我们的组件,网络组件,交换机和路由器,LB会接交换机,交换机接主机,主机会有PostgreSQL组件。你在界面上创造PostgreSQL,加入网络里,把它变成内网的一部分,它有IP地址、访问端口,它本身是高可用的,不用管组件如何做HA、主从切换。如果可以通过代码完成的事情,绝不烦到大家。你可以创建队列服务,队列服务会暴露接口给你直接使用。

    提问:QingCloud在做企业私有云的时候,有没有考虑与第三方厂商的融合,比如厂商用的是负载均衡器,现在希望迁入QingCloud私有云的时候,我可以提供它的API给你。我目前看了一些资料,没有发现这一块,不知道QingCloud未来的发展是怎样的。AWS公有云里有F5类似的组件,未来QingCloud会不会走这条路?

    甘泉:对于第一个问题,QingCloud始终是开放的心态,我知道很多人不信任,每个人都说自己开放,但没几个能真正做到开放。我个人表态,我们QingCloud真的是一个开放的心态看待这个问题。对于我们而言,我们自己做Load Balancer,因为我们有自己的用户需要Load Balancer。我说过我们的Load Balancer从性能来讲,很难跟F5相比,因为我是软件的识别方案。我靠一个大的集群也许能给你产生差不多的效果,问题在于对于用户实际环境而言,我们并不希望使用QingCloud的云系统,就要放弃你以前的东西,这是没有道理的。如果你觉得F5用得好,可以用,一点问题都没有。我们能否调度,绝对是可以的,我们从来没说只能用我们的东西,不能用别人的东西。

    关于AWS的问题,我们当然会去做这个事情。QingCloud跟AWS最大的差别在于积累,我们QingCloud也在努力的构建自己的“大厦”,但现在还不足,但不代表我不愿意做,只是我现在还没做到,非常抱歉,我们会做到的。


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待