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

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

甘泉：今天是第二季实践课堂，去年是第一季。那时候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，用户所创建的XX无缝搬到数据中心，这不是靠手工做，而是靠代码管理或是复制、延伸这边的，从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正在努力让自己变得更好，谢谢大家。

提问：用了很多组件搭建环境，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也在努力的构建自己的“大厦”，但现在还不足，但不代表我不愿意做，只是我现在还没做到，非常抱歉，我们会做到的。

Xuanwo@QingCloud