服务器云基础设施介绍

个人介绍

大家好，我叫张泽强，很荣幸能来到这里和大家一起分享有关游戏服务器的一些生产环境下的应用和案例，希望大家对线上环境的技术方案和选型有一个初步的了解，这样平时在学校做一些课设或项目的时候，对于技术方案多一些选择，或者说可以更接近真实环境。

先做个简单的自我介绍吧。

从毕业到现在一直在做游戏后端的开发，做过多种不同类型的游戏，像休闲/卡牌/MMO/开放大世界，早期做过页游，后来主要都是做手游。做过千万级用户的游戏，也做个没上线就拉垮的项目。维护过不同环境的线上项目，从最早的物理机上的项目到云服务，以及近两年比较火的容器化服务。这些也是今天分享的主题。

我是去年夏天加入字节跳动的，在字节做游戏和之前最大的区别就是，身边都是一些优秀的同事，研发的氛围非常好，管理也更扁平化。现在在技术中心呢，在做的也是一些更有挑战的事情，得益于抖音和头条的流量吧，现在做的所有项目都是直接面向用户的，和用户的距离更近了。

那从毕业到现在总结收获呢，首先是拥有了强者的发型，那今天和大家来一起探讨如何拥有强者的发型吗？那显然不是啊，要不吓跑一堆同学了，今天主要是和大家一起分享下如何变得更强，借着这次分享希望能结识更多的同学，也期待大家以后能来到字节一起做更有趣的游戏。

在正式开始前，先聊一些游戏服务器研发方面的问题吧，这也是平时在校招的时候很多同学经常会问的，比如，你们做游戏服务器用什么语言啊？以我接触和了解到的游戏厂商来看，不负责任的说，毕竟是一个感官上的感受，没有具体的数据统计。大致情况是这样的，北京，大部分游戏厂商，80%以上都是java，最近开始有一些golang的游戏服务器了，主要是休闲类或slg类，剩下的主要就是c++。南方来说，主要是上海杭州深圳广州，以腾讯网易为代表的主要是c++。总的来说主要还是以java和c++为主。另外一个问题，游戏服务器使用到的技术栈都有哪些？这个可以说每个项目使用到的技术栈既不同也相同，不同主要体现在，游戏的品类太多了，不同的游戏类型适合的框架不太一样，比如休闲游戏弱交互和MMO交互性强的，一般使用的框架不一样，再比如FPS等一些竞技类的游戏又不一样，再加上每个公司或者工作室因为一些历史原因，框架也不一样。但是从另外一个层面说，这些不同的框架基本上都是对底层组件的封装，而由于游戏服务器是网络应用，那底层组件主要集中在网络和存储以及线程调度上，关于这些呢其实大学课程上都有涉及，那其实大家只要把基础理论知识学好，不管哪个项目使用什么框架都能很快上手。那具体到网络组件上，大家如果想去学习的话，可以看下java的netty库，数据库的话mysql/mongodb/redis了，特别是redis推荐大家去学习下。

分享概述

那正式开始今天的分享之前呢，先大概介绍下分享的整体内容，希望通过这次分享，让大家尽可能多的了解到真实的线上环境中服务器的方案和原理，包括但不限于，计算/存储和网络等方面，主要分享的侧重点是介绍他们的原理和特性，以及实际的应用，不会过多的涉及到具体使用方面，因为如何使用这个东西即使你现在看了，可能吃了晚饭后就忘了，而且使用的话相信以后大家遇到具体案例要去实操的时候去相应的官网一看就能上手。今天主要是和大家一起了解下他们背后的原理和特性以及一些真实的案例，这样在你们以后学校的一些项目中可以多一些技术选型的参考，更接近于线上环境。

我们首先会介绍下云服务的概述，看下我们在游戏研发中碰到了哪些问题，云服务是否适合我们，帮助我们解决了这些问题。

接下来会详细的介绍一些云基础服务，以及他们在游戏服务器中的应用。

最后我们通过上面了解到的技术方案，去思考总结一下具体某个类型游戏服务器案例的使用。

云服务器概述

设想一下，如果我们现在有一款产品或游戏要发布，那我们需要考虑哪些方面呢？

首先我们在自己的开发机上开发完成，并且测试通过。接下来我们要对用户提供服务，我们可以选择将服务运行在我们的开发机上，这也是一种方案，我们都知道这种方案太草率，具体草率在哪些方面呢？稳定性不够，我们的电脑可能用来玩游戏，玩游戏有的时候还会死机，宿舍还可能会停电。安全性不够，我们电脑还运行了一些和应用本身无关的其他程序。扩展性也不够，如果我们游戏的用户多了，cpu，内存不够了，我们升级电脑硬件，如果我们游戏用户又流失了，资源又溢出了，我们不能一直换电脑吧。另一种方案，我们把服务部署在专用的服务器机房内，稳定性和安全性比我们开发机上好很多了，但是扩展性还是不够，主要受限于硬件，已经国际化部署问题。还有就是维护性方面，需要我们自己去监控机器的状态，包括内存，cpu，网络等。那么有什么方案能解决我们上面提到的这些问题呢？云服务器，大家肯定都有一些了解。那我们接下来就深入了解下云服务器的特性。

云服务是什么？

云服务是将数据中心资源虚拟化，通过互联网提供给大家使用。云服务的这句定义非常简单，其中包括两个主要的名词，一个是数据中心，那数据中心又是什么呢？数据中心指的就是计算，存储，网络等。另一个是虚拟化，什么是虚拟化呢？这个接下来我们会详细介绍。图上是国内常用的云服务供应商：腾讯云，阿里云，字节云。可以看到他们提供的产品和服务非常多，接下来我们也会介绍下主要的基础云服务设施，以及他们在游戏中的应用。

云计算的历史

我们首先来了解下云计算的历史，对他的发展有个基本的概念。云计算发展过程中有这么几个重要的节点。首先是虚拟化理论的提出和发展，虚拟化技术一会我们会根据不同的运用具体展开介绍。然后是虚拟化技术的落地，其中最重要的2001年基于x86的VM的诞生，意味着可以在一台物理机上运行多个虚拟机，启动速度和弹性远超虚拟机。另一个是KVM的出现，随后KVM模块的源码被纳入Linux内核，是现在最常用的服务器虚拟机。在虚拟化技术成熟以后，云计算才真正出现，此时基于虚拟机技术诞生了很多云计算产品，包括IaaS,PaaS,SaaS,FaaS,公有云,私有云等。接下来就是近几年大火的容器技术，容器技术对软件开发行业和微服务的发展有着深远的影响，最后就是k8s在容器编排大战的胜出。

云服务的分类

一切皆服务，他是将基于云的，以软件为主体进行交付的IT资源。我们来看最底层的数据中心，包括服务器，存储，网络等，在这之上通过虚拟化之后作为虚拟机，然后再装上操作系统，这就是一台最基础的云服务器了，这就叫基础设施即服务IaaS，在这基础之上呢，我们可以再加上数据库，中间件等一些工具，作为开发平台提供服务，这个就叫平台即服务PaaS。再往上呢，我们可以直接开发应用，把应用拿出来给用户提供服务，这个就叫软件即服务SaaS。我们大概知道了这三类云服务，如果把这三类服务举个具体的例子呢，IaaS就好比一个地块，我们可以在这个地块上修建任何建筑，自由度比较高，但是需要我们有很强的动手能力。PaaS呢，就好比在地块上已经给我们修好了一些建筑，我们可以根据自己的使用用途来自己装修了，这个就比较适合有一定动手能力的。最后SaaS呢，就好比图书馆，食堂之类的，可以直接提供服务了，我们只需要使用就可以了。我们再来看下，都有哪些厂商来提供这些云服务呢？首先是基础设施包括国外的亚马逊，Google，微软了，国内的阿里，腾讯，华为。字节呢现在主要还是提供私有云为主，服务公司内部。平台服务呢，大部分提供基础服务的都提供平台服务，像我们刚开始放的云厂商那张图片里一样，字节也提供了很多平台服务。最后是软件服务，这个大家是大家平时日常生活中接触最多的了。

什么是****PaaS

那什么是PaaS呢？为什么我们单独把这个拿出来说呢，因为iaas和SaaS比较好理解，IaaS就是CPU内存这些服务器资源，SaaS就是软件服务。PaaS是我们日常开发中接触最多的，他是以便利开发者为目标的中间件。我们再回头思考下，我们最开始提出的问题，我们知道了在本地发布我们的游戏服务器稳定性不够，物理机上发布一次性投入成本和维护成本比较高，现在我们想将服务器发布到云上，应该采用哪种方案呢？我们先来看下IaaS，云服务器，我们需要考虑考虑cpu，内存这些，还得安装我们的环境，java开发的需要安装jdk，用到数据库的话，我们还得安装数据库，这些环境配置好了之后才能运行我们的代码。那PaaS呢，PaaS就是给我们提供好了开发平台，我们直接可以写代码运行了，需要的环境都已经安装好了，对开发者来说真的很友好。那SaaS呢，直接面向用户提供服务，比如我这次的PPT主要就是在飞书doc上在线写的。通过他们这些特性呢，我们就能知道他们面向服务的群体了，PaaS面向运维工程师，iaas面向软件开发者，SaaS面向的是用户。

云服务的优势

那我们到现在对云服务有了一个概括性的了解之后呢，我们来看下他有哪些优势呢？

按需灵活配置：根据我们用户的量级预估资源的配置，申请云服务器。

简化容量管理：如果我们应用的人数比预期高了或低了，我们都能扩缩容我们的机器，现在云厂商都支持在线扩缩容了。

基础云服务及应用

现在我们对云服务有了一个大概的了解，接下来我们针对性的介绍一些基础云服务以及他们在游戏中的应用。主要包括计算类的，云主机，容器，函数服务，以及网络类的VPC，负载均衡。存储类的我们今天就不介绍了，明天我们的同事有一个非常高质量的分享，欢迎大家到时候参加。

虚拟化技术

那在介绍云服务之前呢，我们首先要了解下上面提到过的虚拟化技术，这是云服务的基础。虚拟化技术是指通过资源管理技术，将计算机的实体资源分割成几个独立的环境。

对于一台电脑来说，我们很熟悉了，可以简单的划分为三层，从下到上分别是物理硬件层，操作系统层，应用程序层。对物理资源的虚拟划分有两种著名的方案，左边的是1型：直接凌驾于硬件之上，构建出多个隔离的操作系统环境。右边的是2型：依赖于宿主操作系统，在其上构建出多个隔离的操作系统环境。这两类方案在原理上区别是什么呢？第一种vmm是完全模拟了整个cpu指令集，将虚拟机的操作直接转化成cpu指令集执行，第二种vmm在虚拟机操作系统和计算机之前扮演了一个桥梁的作用，将虚拟机要执行的操作翻译成cpu指令在计算机上执行，这两个的区别有点像解释性语言和编译性语言的区别。像我们在电脑上经常安装的虚拟机是第二类的，他是依赖于宿主操作系统的。

接下来我们来看下现在云服务上主要使用的KVM，他是开源的，并且已经集成进Linux内核了，可以认为linux内核本身就是一个vmm。从图中我们可以看到KVM本身基于硬件辅助虚拟化只负责虚拟化cpu和内存，但是一台计算机不只有cpu和内存，还有各种io设备，QEMU负责这些设备的虚拟化。

云服务器

我们知道了一台物理机如果通过虚拟化技术形成多台环境隔离的虚拟机之后，我们现在将之前的游戏服务器发布到云服务器上，就清楚了更多的细节。云服务有哪些优势呢？云服务有哪些规格适合我们的服务器呢？AI训练，现在很多竞技游戏，包括棋牌类的AI都是机器学习了，这样的机器人操作更符合正常玩家的思维，提高了游戏玩家的体验。当然如果在字节发布云服务器的话，也可以发布在我们每个人的devbox上，每个程序都会有的一台云服务器，方便我们有的时候调试。

应用

以一个MMO游戏为例吧。我们在开新服的时候，只需要新增云服务器就可以了，如果一些服务器的玩家活跃人数少了之后，我们在需要进行合服的时候，只需要下掉几台云服务器就好了。数据库呢，我们可以选择直接用paas服务提供的即可，我们不需要去部署安装数据了，我们直接使用即可。现在我们将应用部署到云服务器上就稳定和方便了很多。

容器

在了解了使用云服务器来部署我们的应用后，已经基本能满足之前我们碰到的问题了。那在实际的开发环境中，我们经常又会碰到新的问题，比如服务在我们的开发机上可以运行，但是发布到服务器上却不能运行了，这是为什么呢？因为我们本地开发的环境和线上环境是不同的，依赖的工具包和配置也是不同的，比如我们本地的开发机上使用的jdk可能是11，线上安装的jdk是1.8，我们在开发中使用了11的一些新特性比如var变量，在本地可以正常运行，但是线上1.8的就会报错。还有另一种情况，本来我们的服务运行的非常稳定，但是在版本升级了之后却出现问题了，比如我们将mysql从5.7升级到了8.0，使用了8.0的一些特性，比如用rename直接修改列名，这样在5.7上就会失败。这些例子最主要的问题还是环境的差异，那为什么会有这些环境的差异呢？这是因为我们的发布流程是我们将我们编写的代码编译成最终运行的产物，比如exe或jar包war包，我们将最终产物上传到服务器上，运行环境和依赖使用的是我们云服务上的配置，我们在新加云服务器或升级配置的时候可能造成环境不一致的情况。那针对这种情况呢，容器技术的出现提供了另一种思路，我们可以将最终产物和我们的环境依赖一起打包，然后部署上线，这样一套流程走完，所有的环境和依赖都是一致的，这是容器化技术出现最大的特性。

但是这个流程最终如何实现的呢？我们可以借鉴下前端的流程，前端是在u3d或者ue上开发，然后打包成游戏包，安卓的话是apk，ios的话是ipa，然后将游戏包发布到应用商店，appstore或googlestore上，用户直接下载安装后就可以使用了。那我们后端是不是也可以呢，将jar/exe这些最终产物带上环境一起打包发布到远程应用商店里面，服务器只需要下载安装运行就可以了。这就是容器提供的标准交付解决方案。

容器另外一个最大的特性是通过打包装箱的思想进行应用程序级别的隔离，可以在一台云服务器上运行多个环境相互隔离的应用，已达到对资源的极致利用。

容器的工作原理，容器的虚拟化不是模拟了整个操作系统，他只是隔离了应用的环境，使用的还是宿主机的操作系统，非常轻量级。

容器编排

通过我们之前对容器的介绍，知道容器自身的价值主要是提供了标准化的交付，打包和分发的作用，和轻量级的应用环境隔离，但是如果不形成规模化的效应，是无法发挥出对资源利用的优势的，那形成规模化效应最大的问题就是容器的调度和编排上应该如何进行，所谓编排就是不同应用的容器间的关系的组织。那在这些编排工具中使用最广泛的就是我们要介绍的k8s，k8s是什么，他本身是一个跨主机的容器编排工具，他使用网络将多个主机构建成统一的集群，主节点作为控制中心，负责管理整个集群系统，其他节点为工作节点，工作节点以pod的形式运行服务，这种服务一般都是计算服务。总结来说k8s编排工具主要提供了容器间部署，更新，伸缩的管理服务，以及容器周边的编排比如网络存储等。k8s最主要的特性就是声明式api，我们只需要告诉他我们预期的结果是什么样就可以，剩余的事情全部交给k8s来完成。k8s的控制器模式来负责实现用户期望的状态，因此我们用k8s举例来说，大概就是我们告诉k8s，我们希望运行两个pod，pod如何去下载镜像，下载完后这个pod具体运行在集群中的哪个节点上，万一pod所在的节点宕机了，如何再重新启动起来等等这些，统统交给k8s来解决。我们使用声明式api的形式就是通过json文件或yaml文件来组织声明式api即可，和dockerfile一样简单。

到这里可能大家会有个疑问，我们之前介绍了容器，现在在说容器编排，但是他本身调度的不是容器而是pod，那pod又是什么呢？pod是k8s上运行应用的最小单位，pod是一到多个容器的集合，这些容器共享network，IPC，uts，这些主要是和网络通信和主机名相关的名称空间，还可以共享数据卷，我们之前介绍过容器间的文件是相互隔离的，那pod间的多个容器是如何实现共享的呢，每个pod上都会启动一个基础容器，叫pod infrastructure，他主要负责创建这些共享的名称空间，以及绑定数据卷，这样在这个pod上运行的其他容器就可以共享这些了。mount和user是隔离的，我们可以理解成pod是一组紧密相关的容器组成的，但事实上可能我们一个pod就只跑一个容器。一般我们不建议一个pod上跑多个容器，除非是必须的，比如sidecar模式，我们使用ipc进程间通信，提高性能，比如我们每个pod上可以跑一些日志采集的服务，或者性能分析的服务，那这些如果部署成不同的pod的话，就需要通过network进行通信呢，我们这时候可以选择以sidecar的模式将他们部署成一个pod。

有了这些基础了解之后，接下来我们来看下k8s的基础架构。我们刚才提到过一个k8s的系统主要由两类结构组成，一个是控制节点，另一个叫计算节点，主要是来运行我们的程序的。一般来说控制节点1个就能实现功能了，但是这样控制节点就成为了单点问题，实际中我们一般也会部署三个控制节点，因为他其中使用的etcd使用raft协议，进行选举时最好不少于三个节点。那计算节点按照我们的需求来部署相应的数量即可。控制节点呢主要由这几个组成，apiserver整个k8s程序的入口，所有数据的出入都通过apiserver完成。controler manager就是刚才提到的控制器模式，都放在这里。scheduler是负责调度用户或控制器创建的新的节点，究竟这个pod该运行在哪个节点上呢，就是有scheduler决定的。etcd是用来用来存储服务的状态，他是通过raft协议来构建的支持kv存储的一致性数据库。再看计算节点，每个计算节点上都会运行这样三个组件，一个是kubelet，是apiserver的客户端，负责和apiserver通信，接收apiserver的scheduler分发的由自己负责执行的任务。创建完pod后需要和其他pod进行通信，kube-proxy进行的，他还负责低层级的服务发现和负载均衡。最后就是我们真正运行的容器了。k8s可以运行在物理机，虚拟机，公有云私有云上面。

VM vs Docker

介绍了vm和docker后我们来看下这两个主要的区别的。

容器和虚拟机走的是完全不同的路线，虚拟机的目标是虚拟化出一台完整的计算机，拥有底层的物理硬件，操作系统，应用程序执行所需的环境。为了让虚拟机达到能模拟真实物理机上运行的环境，vmm做了很多繁重的事情，但其实对于应用程序来说这套环境可以说是有用但是又不完全有用，应用程序只需要独立的应用执行环境就可以了。这样做有什么好处呢？虚拟出一台计算机的代价是比较大的，可能一台物理机上虚拟出10台虚拟机就非常吃力了，但是虚拟出上百个独立的执行环境却非常轻松，另外一台虚拟机的启动远远比容器的启动要慢很多。另外容器的程序代码指令不需要翻译，就可以直接在cpu上运行，因为大家其实公用的是同一个操作系统，只是进行了软件层面上的逻辑隔离，性能更好。缺点呢就是隔离性比虚拟机要差，一旦利用内核漏洞发起攻击，程序突破容器限制，实现逃逸，危机宿主计算机，就会影响到整台物理机上的所有容器。

应用

我们都知道传统游戏不像app一样有那么高的日活，纵观游戏的生命周期我们发现大部分游戏都会有他的一个峰值时间点，而且大部分游戏的生命周期可能也不是很长，而且在一些节日活动的时候伴随着游戏中的活动，在线人数会迅速攀高，即使按天的时间来观察，也会发现游戏会有一个明显的高峰和低谷，以今年抖音和春晚的合作为例，芒果斗地主在抖音主会场的露出带来了大量的用户，而且由于春晚红包雨的这种瞬时高流量的玩法，给游戏部署带来了更多的挑战，如果是传统的云服务器的话，那我们可能事先就需要准备大量的服务器了，而且等春晚活动过后玩家一定会逐渐回归到一个正常的水平，那这些空闲的服务器归还也是一个问题。那得益于字节云提供的容器化服务，我们可以做到快速的响应，达到迅速自动扩缩容的要求，进一步控制成本。在几个热点服务上，比如牌局服务，这个是频繁创建和销毁的，为了应对春晚的流量，单个服务的容器就达到了几百个，这个如果是部署在传统的云服务器上，成本会比容器高很多。

函数服务

接下来我们介绍下函数服务，这个可能大家平时了解的比较少，函数服务也叫无服务器架构，他不同于我们上面介绍的云服务提供完整的应用功能，只是提供应用中某个功能的服务。这里的无服务器指的不是没有云服务器，而是无需我们关心云服务器。那具体他是怎么实现的呢？回忆下我们之前介绍的IaaS,PaaS平台，我们发布应用的时候需要将我们的可执行程序发布到服务器上，然后启动运行，我们拥有的是对后台服务器的权限，这也意味着我们需要去关心服务器的状态，包括我们之前提到的运行环境，负载均衡和容量等等，那如果我们的某些服务是一些非常轻量级的呢？可能这个服务的功能开发比我们去部署和管理的成本还高，那就可以选择函数服务，我们看函数服务的云服务器和之前相比位于更后端了，这个不代表云服务没了，只是不需要我们关心了，这些服务器的状态又厂商根据我们的需求来调整，我们只需要将代码上传到指定的地方，一般就是svn或gitlab了，上传之后一般通过事件来触发代码打包和执行，事件一般包括有对象存储事件，也就是说检测到有代码上传了，或者是一些指令事件，比如手动触发等。这样代码就在后台服务器执行了。相比之前我们现在只需要上传代码就可以了，环境和高可用这些就不需要我们关心了。而且函数服务一般是按需收费，就是代码真正运行的时候才收费。

应用

这俩游戏可能大部分同学都有玩过吧，尤其是上面的原神，下面这个是朝夕光年自研的航海王。现在很多游戏都有自拍分享功能，我们会上传分享自己在游戏中的一些图片，或者上传一些游戏中的高光时刻视频。那这个上传服务就可以使用函数服务，我们将图片，视频上传至后台对象存储，上传成功事件触发我们的函数服务，包括检测图片或视频中是否有一些违规或敏感信息，然后将文件进行压缩回传。这样我们不需要关心我们这个服务可以承载多少qps，这些有服务提供商来进行动态调整，而且只有在函数提供服务的时候我们才按需付费，节省了成本。

VPC

虚拟私有云，这个名字可能会让我们感觉怎么云服务里面还有云呢？那他其实是云里面的局域网。我们类比下本地局域网，本地局域网大家比较熟悉了，比如我们动画学院是一个子网，其他不同的学院也是不同的子网，不同的子网之间通过路由组成了整个学校的局域网。vpc就相当于云服务上的局域网，我们不同的服务在同一个子网下，比如之前我们提到的游戏服务器在同一个子网下，存储服务在另一个子网下，但他们整体在同一个局域网下，这样保证了通信的效率和安全性。

SLB

随着我们的游戏越来越火，我们服务器不能部署在一台服务器上，一个是随着硬件需求的增高，成本也在翻倍，单台服务器也有性能的瓶颈。另一个只有一台，服务器不能保证高可用，服务器一旦宕机了，整个服务就不可用了。我们之前提到的例子中呢，大部分其实都做成一个子网，由多台服务器组成，那slb就负责对多台云服务器进行流量分发和负载均衡。我们接下来看下slb工作的流程，游戏的请求发送到slb服务loadbalancer，loadbalancer也可以是多台部署，完全消除单点的隐患。然后loadbalancer根据我们定义的负载均衡策略和转发规则，将请求转发到我们后端的不同业务服务器，业务服务器也是多台部署，没有单点问题，业务服务处理完请求后，将消息结果返回给loadbalancer，再有loadbalancer返回给前端。

那slb除了流量分发之外还提供了很多其他特性，包括虚拟服务IP地址，我们可以把后端所有的服务节点视为同一个虚拟服务对外提供，保证了高性能和高可用的服务池。我们还可以自定义我们的协议转发规则，比如一些战斗协议转发到战斗服务器集群，消费协议转发到支付服务器集群等。还可以自定义调度规则，比如优先使用同地区的服务集群，或者最空闲的服务集群等。还提供了健康检测，新增服务器和删除服务器的时候，slb自动从可用节点中加入或删除，提高应用整体服务能力。防护能力，防DDoS攻击，还可以添加SSL证书，这样https的请求，就不需要我们在业务服务器中单独处理了。另外就是多区域容灾，这样即使我们的某一个机房出现问题，也不会影响我们服务的整体可用性。

应用

以我之前做过的一个卡牌游戏举例，在其中应用到多台slb的服务，一个是游戏更新的服务，在这个服务中包括了多台负责在游戏中一些需要资源热更的地方，slb将资源更新的请求发送到负载比较低的后台web服务上。另一个是游戏运行服务，所有游戏运行服务的节点都挂在这个slb下面，slb负责将玩家请求分发到对应的服务器上。首先通过不同的slb进行了业务方面的分流，不同的slb内部有不同的服务器去负责处理请求，这样极大的提升了系统的可扩展性，业务之间呢也相互隔离。然后每个服务之内呢也是部署了多台节点，保证了服务的高可用。