研究讨论 OpenStack 各个模块

【Keystone 身份服务】

Keystone (OpenStack Identity Service) 是OpenStack中的一 个独立的提供安全认证的模块，主要负责openstack用户的身份认证、 令牌管理、提供访问资源的服务目录、以及基于用户角色的访问控制。

Keystone类似一个服务总线，或者说是整个Openstack框架的注册表,其他服务通过keystone来注册其服务的 Endpoint (服务访问的URL)，任何服务之间相互的调用，需要经过Keystone的身 份验证，来获得目标服务的 Endpoint来找到目标服务。

一、主要功能

• 身份认证(Authentication) : 令牌的发放和校验
• 用户授权(Authorization) : 授予用户在一个服务中所拥有权限
• 用户管理(Account) : 管理用户账户
• 服务目录(Service Catalog) : 提供可用服务的API端点

二、相关概念

• User: 指使用Openstack service的用户。
• Project(Tenant): 可以理解为一个人、或服务所拥有的资源集合。
• Role: 用于划分权限。通过给User指定Role，使User获得Role对应操作权限
• Authentication: 确定用户身份的过程。
• Token: 是一个字符串表示，作为访问资源的令牌。Token包含 了在指定范围和有效时间内，可以被访问的资源。
• Credentials: 用于确认用户身份的凭证。用户的用户名和密码，或者是用户名和API密钥，或者身份管理服务提供的认证令牌。
• Service: Openstack service，即Openstack中运行的组件服务。如nova、swift、glance、 neutron、 cinder等。
• Endpoint: 一个可以通过网络来访问和定位某个Openstack service的地址，通常是一个URL。

注意：
1、因为组件点到点的交互是通过 API 来完成的，API 由 Apache 所承载，Apache 提供了一个URL，所以 API 和 API 的对接也可以认为是 URL 和 URL 的对接。
2、OpenStack中核心、辅助组件的用户是在"yum install" 的时候创建的，OpenStack中关键的就是组件、服务之间的对接配置

三、：keystone工作流程图

创建虚拟机首先需要登录用户认证，user向keystone认证，认证没问题以后登录，user需要向nova发送请求，请求安装虚拟机的指令，nove再次向Keyston返回请求验证，验证成功，创建虚拟机是需要glance镜像资源以及neutron网络等资源，那么nova都会想keystone请求验证来获取资源，验证都无问题则会进行VM的创建，创建成功以后返回信息给user

【Glance镜像服务】

它在OpenStack中的项目名称为Glance。在早期的OpenStack版本中，Glance只有管理镜像的功能，并不具备镜像存储功能。现在，Glance已发展成为集镜像上传、检索、管理和存储等多种功能的OpenStack核心服务。
Glance镜像服务

镜像
镜像的英文为Image,又译为映象，通常是指一系列文件或 一个磁盘驱动器的精确副本。镜像文件其实和ZIP压缩包类似,它将特定的一系列文件按照一定的格式制作成单一的文件, 以访便用户下载和使用。

一、概念理解

举例子: Ghost是使用镜像文件的经典软件，其镜像文件可以包含更多信息，如系统文件、引导文件、分区表信息等,这样镜像文件就可以包含一个分区甚至是一块硬盘所有信息。Ghost可基 于镜像文件快速安装操作系统和应用程序。
举例子: VMware的虚拟机模板

二、Glance镜像服务功能

镜像服务就是用来管理镜像的，让用户能够发现、获取和保存镜像。在OpenStack中提供镜像服务的是Glance，其主要功能如下:

• 查询和获取镜像的元数据和镜像本身
• 注册和。上传虚拟机镜像，包括镜像的创建、上传、 下载和管理
• 维护镜像信息，包括元数据和镜像本身。
• 支持多种方式存储镜像，包括普通的文件系统、Swift、 Amazon S3等
• 对虚拟机实例执行创建快照命令来创建新的镜像，或者备份虚拟机的状态

三、镜像格式

虚拟机镜像文件磁盘格式

raw:无结构的磁盘格式
vhd:该格式通用于VMware、Xen、VirtualBox以及其他虚拟机管理程序
vhdx:vhd格式的增强版本，支持更大的磁盘尺寸
vmdk:一种比较通用的虚拟机磁盘格式
vdi:由VirtualBox虚拟机监控程序和QEMU仿真器支持的磁盘格式
iso:用于光盘(CD-ROM)数据内容的档案格式
ploop:由virtuozzo支持，用于运行OS容器的磁盘格式
qcow2:由QEMU仿真支持，可动态扩展，支持写时复制（Copy on Write）的磁盘格式
aki:在Glance中存储的Amazon内核格式
ari:在Glance中存储的Amazon虚拟内存盘（Ramdisk）格式
ami:在Glance中存储的Amazon机器格式

磁盘结构:
RAW :磁盘镜像实例,以进制形式存储的方式(图片)
优点:访问速度非常快
缺点:不支持动态扩容、前期消耗多(创建20G磁盘类比workstation)
Vhd:微软公司提出的格式
VMDK: vmware公司想要统虛拟化平台的一 种格式
Vdi: VirtualBox官方 支持的结构
ISO:基本类型
Qcow2: Qemu支 持的类型
AKI、 ARI、 AMI:亚马逊所推出支持的类型
容器:
磁盘存储的数据、元数据需要相互隔离,所以会使用到容器
Bare :基础类型，
Ovf:标准的格式体系，支持动态扩容,而且支持导出导入
AKi、 Ami、 Ari: 亚马逊
组件工作流程
glance- api
json yaml xml格式的

raw优点：访问速度非常块；缺点：不支持动态扩容，前期消耗多

四、镜像格式

镜像文件容器格式

bare:没有容器或元数据“信封”的镜像
ovf：开放虚拟化格式
ova:在Glance中存储的开放虚拟化设备格式
aki:在Glance中存储的Amazon内核格式
ari:在Glance中存储的Amazon虚拟内存盘（Ramdisk）格式
Docker:在Glance中存储的容器文件系统的Docker的tar档案

五、镜像状态

状态1

queued:这是一种初始化状态，镜像文件刚被创建，在Glance数据库只有其元数据，镜像数据还没有上传至数据库中
saving:是镜像的原始数据在.上传到数据库中的一种过渡状态，表示正在上传镜像
uploading:指示已进行导入数据提交调用，此状态下不允许调用PUT/file (saving状态会执行PUT/file,这是另外一种上传的方法)
importing:指示已经完成导入调用，但是镜像还未准备好使用

状态2

active:表示当镜像数据成功上传完毕，成为Glance中可用的镜像
deactivated:表示任何非管理员用户都无权访问镜像数据，禁止下载镜像，也禁止镜像导出和镜像克隆之类的操作
killed:表示镜像上传过程中发生错误，镜像不可读
deleted:镜像将在不久后被自动删除，该镜像不可再用，但是目前Glance仍然保留该镜像的相关信息和原始数据
pending_delete: 与deleted相似，Glance还没有清除镜像数据， 但处于该状态的镜像不可恢复

七、Glance详细架构图

• 客户端是Glance服务应用程序使用者，是OpenStack命令行工具、Horizon或Nova服务
• glance-api是系统后台运行的服务进程,是进入Glance的入口。它对外提RESTAPI, 负责接收用户的RESTful请求，响应镜像查询、获取和存储的调用。
• glance-registry是 系统后 台运行的glance注册服务进程，负责处理与镜像元数据相关的RESTful请
  求，元数据包括镜像大小、类型等信息。Glance-api接收的请求如果是与镜像的元数据相关的操作glance-api会把请求转发给glance-registry。glance-registry会解析请求内容，并与数据库交互，存储、处理、检索镜像的元数据。glance-api对外提供API，而glance-registry的API只由Glanc使用。

八、工作流程

• OpenStack的操作都需经Keystone进行身份认证(AuthN)并授权(AuthZ)，Glance也不例外。Glance是一个C/S架构，提供一个REST API，用户就通过RESTAPI来执行镜像的各种操作。[Glance Domain Controller是一个主要的中间件，相当于调度器，作用是将Glance内部服务的操作分发到以下各个功能层
• Registry Layer(注册层):是一个可选层，通过使用单独的服务控制Glance Domain Controller与GlanceDB之间的安全交互。
• Glance DB:是Glance服务使用的核心库，该库对Glance内部所有依赖数据库的组件是共享的。(这个库是存一些元数据信息的，不是真正存镜像的数据库)
• Glance Store:用来组织处理Glance和各种存储后端的交互，提供了一个统一的接口来访问后端的存储。所有的镜像文件操作都是通过调用Glance Store库来执行的，它负责与外部存储端或本地文件存储系统的交互。

总结：

1、glance-api是系统后台运行的服务进程，对外提供REST API，相应image查询、获取和存储的调用，glance-api不会真正处理请求
2、如果是与image metadata（元数据）相关的操作，glance-api会把请求转发给glance-registry
3、如果是与image自身存取相关的操作，glance-api会把请求转发给该image的store backend
4、查看glance-api进程：ps -elf | grep glance-api

【Nova计算服务】

一、Nova计算服务

• 计算服务是openstack最核心的服务之一， 负责维护和管理云环境的计算资源，它在openstack项目中代号是nova
• Nova自身并没有提供任何虚拟化能力，它提供计算服务，使用不同的虚拟化驱动来与底层支持的Hypervisor (虚拟机管理器)进行交互。所有的计算实例 (虚拟服务器) 由Nova进行生命周期的调度管理 (启动、挂起、停止、删除等)
• Nova需要keystone、glance、 neutron、 cinder和swift等其他服务的支持，能与这些服务集成，实现如加密磁盘、裸金属计算实例等。

二、Nova 系统架构

• Nova 由多个服务器进程组成，每个进程执行不同的功能。
  
• DB:用于数据存储的sq|数据库。
• API: 用于接收HTTP请求、 转换命令、通过消息队列或HTTP与其他组件通信的nova组件。
• Scheduler: 用于决定哪台计算节点承载计算实例的nova调度器。
• Network: 管理IP转发、网桥或虚拟局域网的nova网络组件。
• Compute: 管理虚拟机管理器与虚拟机之间通信的nova计算组件。
• Conductor: 处理需要协调(构建虚拟机或调整虚拟机大小)的请求，或者处理对象转换

三、Nova 组件介绍

（一）、API

• API是客户访问nova的http接口， 它由nova-api 事务实现，nova-api 服务接收和响应来自最终用户的计算api请求。作为openstack对外服务的最主要接口，nova-api提供了一个集中的可以查询所有api的端点。
• 所有对nova的请求都首先由nova-api处理。 API提供REST标准调用服务，便于与第三方系统集成
• 最终用户不会直接改送RESTful API请求,而是通过openstack命令行、dashbord和其他需要跟nova交换的组件来使用这些API。
• 只要跟虚拟机生命周期相关的操作， nova-api都可以响应。
• Nova-api对接收到的HTTP API请求做以下处理:
  • 1)检查客户端传入的参数是否合法有效
  • 2)调用nova其他服务来处理客户端HTTP请求
  • 3)格式化nova其他子服务返回结果并返回给客户端
• Nova-api是 外部访问并使用nova提供的各种服务的唯一途径，也是客户端和nova之间的中间层。

（二）、Scheduler（觉得实例创建在哪，创建在哪个计算节点）

• Scheduler可译为调度器，由nova-scheduler服务实现，主要解决的是如何选择在哪个计算节点上启动实例的问题。它可以应用多种规则，如果考虑内存使用率、cpu负载率、cpu构架(intel/amd) 等多种因素，根据一定的算法，确定虚拟机实例能够运行在唯一一台计算服务器上。Nova-scheduler服务会从队列中接收一个虚拟机实例的请求，通过读取数据库的内容，从可用资源池中选择最合适的计算节点来创建合适的虚拟机实例。
• 创建虚拟机实例时,用户会提出资源需求，如cpu、内存、磁盘各需要多少。Openstack将这些需求定义在实例类型中，用户只需要指定使用哪个实例类型就可以了。

Nova调度器的类型:

• 随机调度器(chance scheduler) :从所有正常运行nova-compute服务的节点中随机选择。
• 过滤器调度器(filter scheduler) :根据指定的过滤条件以及权重选择最佳的计算节点。Filter又称为筛选器
• 缓存调度器(caching scheduler):可看作随机调度器的一种特殊类型，在随机调度的基础上将主机资源信息缓存在本地内存中，然后通过后台的定时任务定时从数据库中获取最新的主机资源信息。

过滤器调度器调度过程:

主要分二个阶段

• 通过指定的过滤器选择满足条件的计算节点，比如内存使用率小于50%，可以使用多个过滤器依次进行过滤。
• 对过滤之后的主机列表进行权重计算并排序，选择最优的计算节点来创建虚拟机实例。

过滤器

• 当过滤调度器需要执行调度操作时，会让过滤器对计算节点进行判断，返回True或False。（/etc/nova/nova.conf配置文件中）
• scheduler_available_filters选项用于配置可用过滤器，默认是所有nova自带的过滤器都可以用于过滤作用（Scheduler_ vailable_filters = nova.scheduler.filters.all_filters）
• 另外还有一 个选项scheduler_ default_filters用于指定nova-scheduler服务真正使用的过滤器，默认值如下（Scheduler_ default_ filters = RetryFilters, AvailabilityZoneFilter, RamFilter,ComputeFilter,ComputeCapabilitiesFilter, ImagePropertiesFilter,ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter）

过滤调度器将按照列表中的顺序依次过滤。

RetryFilter(再审过滤器)

• 主要作用是过滤掉之前已经调度过的节点。如A、B、C都通过了过滤，A权重最大被选中执行操作，由于某种原因，操作在A. 上失败了。Nova-filter将重新执行过滤操作，那么此时A就被会RetryFilter直接排除，以免再次失败

AvailabilityZoneFilter (可用区域过滤器)

• 为提高容灾性并提供隔离服务，可以将计算节点划分到不同的可用区域中。Openstack默认有一 个命名为nova的可用区域， 所有的计算节点初始是放在nova区域中的。用户可以根据需要创建自己的一个可用区域。创建实例时，需要指定将实例部署在哪个可用区域中。Nova-scheduler执行过滤操作时，会使用AvailabilityZoneFilter不属 于指定可用区域计算节点过滤掉

RamFilter (内存过滤器)

• 根据可用内存来调度虚拟机创建，将不能满足实例类型内存需求的计算节点过滤掉,但为了提高系统资源利用率, Openstack在计算节点的可用内存时允许超过实际内存大小，超过的程度是通过nova.conf配置文件中ram_ allocation_ratio参数来控制的，默认值是1.5。（Vi /etc/nova/nova.conf ----> Ram_ allocatio_ratio=1.5)

DiskFilter (硬盘调度器)

• 根据磁盘空间来调度虚拟机创建，将不能满足类型磁盘需求的计算节点过滤掉。磁盘同样允许超量，超量值可修改nova.conf中disk_allocation_ratio参数控制，默认值是1.0（Vi /etc/nova/nova.conf-------> disk_ allocation_ratio=1.0）

权重 (weight)

• hova-scheduler服务可以使用多个过滤器依次进行过滤过滤之后的节点再通过计算权重选出能够部署实
  例的节点。

注意:
所有权重位于nova/scheduler/weights目录下。目前默认实现是RAMweighter，根据计算节点空闲的内存量计算权重值，空闲越多，权重越大，实例将被部署到当前空闲内存最多的计算节点上

（三）、Compute

1、实例具体的创建、管理工作
2、虚拟资源交互/调用
3、向openstack报告计算节点状态

• Nova-compute在计算节点 上运行，负责管理节点上的实例。通常一个主机运行一个Nova-compute服务,一个实例部署在哪个可用的主机上取决于调度算法。OpenStack对实例的操作，最后都是提交给Nova-compute来完成。
• Nova-compute可分为两类，一 类是定向openstack报告计算节点的状态，另一类是实现实例生命周期
  的管理。

通过Driver (驱动)架构支持多种Hypervisor虚拟机管理器

• 面对多种Hypervisor, nova-compute为这些Hypervisor定义统一的接口（nova-compute会提供一个统一的接口来和底层虚拟化资源交互）
• Hypervisor只需要实现这些接口，就可以Driver的形式即插即用到OpenStack系统中（调用虚拟化资源和供给到openstack内部，都是通过driver的形式来完成的）

定期向OpenStack报告计算节点的状态

• 每隔一段时间，nova-compute就会报告当前计算节点的资源使用情况和nova-compute服务状态。
• nova-compute是通过Hypervisor的驱动获取这些信息的。

实现虚拟机实例生命周期的管理

• OpenStack对虚拟机实例最 主要的操作都是通过nova-compute实现的。创建、关闭、重启、挂起、恢复、中止、调整大小、迁移、快照
• 以实例创建为例来说明nova-compute的实现过程。
  • (1)为实例准备资源。
  • (2)创建实例的镜像文件。
  • (3)创建实例的XML定义文件。
  • (4)创建虚拟网络并启动虚拟机。

（四）、Conductor

• 由nova-conductor模块实现，旨在为数据库的访问提供一层安全保障。Nova-conductor作为nova-compute服务与数据库之间交互的中介，避免了直接访问由nova-compute服务创建对接数据库。
• Nova-compute访问数据库的全部操作都改到nova-conductor中，nova-conductor作为对数据库操作的一个代理，而且nova-conductor是部署在控制节点上的。
• Nova-conductor有助于提高数据库的访问性能，nova-compute可以创建多个线程使用远程过程调用(RPC)访问nova-conductor。
• 在一个大规模的openstack部署环境里，管理员可以通过增加nova-conductor的数量来应付月益增长的计算节点对数据库的访问量

（五）、PlacementAPI

• 以前对资源的管理全部由计算节点承担，在统计资源使用情况时，只是简单的将所有计算节点的资源情况累加起来，但是系统中还存在外部资源，这些资源由外部系统提供。如ceph、nfs等提供的存储资源等.面对多种多样的资源提供者，管理员需要统一的、简单的管理接口来统计系统中资源使用情况，这个接口就是PlacementAPl。
• PlacementAPI由nova-placement-api服务来实现， 旨在追踪记录资源提供者的目录和资源使用情况。
• 被消费的资源类型是按类进行跟踪的。如计算节点类、共享存储池类、IP地址类等。

四、虚拟机实例化流程

用户可以通过多种方式访问虚拟机的控制台

• Nova-novncproxy守护进程:通过vnc连接访问正在运行的实例提供一个代理，支持浏览器novnc客户端。
• Nova-spicehtml5proxy守护进程: 通过spice连接访问正在运行的实例提供-个代理，支持基于html5浏览器的客户端。
• Nova-xvpvncproxy守护进程: 通过vnc连接访问正在运行的实例提供一个代理，支持openstack专用的java客户端。
• Nova-consoleauth守护进程: 负责对访问虚拟机控制台提供用户令牌认证。这个服务必须与控制台代理程序共同使用。

五、控制台接口

• 首先用户 (可以是OpenStack最终用户，也可以是其他程序) 执行Nova Client提供的用于创建虚拟机的命令。
• nova-api服务监听到来自于Nova Client的HTTP请求，并将这些请求转换为AMQP消息之后加入消息队列。
• 通过消息队列调用nova-conductor服务。
• nova-conductor服务从消息队列中接收到虚拟机实例化请求消息后，进行一 些准备工作。
• nova-conductor服务通过消息队列告诉nova-scheduler服务去选择一 个合适的计算节点来创建虚拟机，此时nova-scheduler会读取数据库的内容。
• nova-conductor服务从nova-scheduler服务得到了 合适的将计算节点的信息后，在通过消息队列来通知nova-compute服务实现虚拟机的创建。

【Neutron服务】

一：Neutron基本架构

与 OpenStack其他服务和组件的设计思路一样， Neutron也采用分布式架构，由多个组件（服务）共同对外提供网络服务， Neutron架构非常灵活，层次多，一方面是为了支持各种先有或者将来会出现的先进网络技术，另一方面支持分布式部署，获得足够的扩展性。示意图如下：

Neutron仅有一个主要服务进程 Neutron-server，它运行于控制节点上，对外提供OpenStack网络API作为访问 Neutron的入口，收集请求后调用插件（ Plugin）进行处理，最终由计算节点和网络节点上的各种代理（ Agent）完成请求。

网络提供者（ Network provider）是指提供者 OPenStack网络服务的虚拟机或者物理网络设备，如 Linux Bridge、 Open vSwitch或者其他支持 neutron的物理交换机。与其他服务一样， Neutron的各个组件服务之间需要相互协调通信， Neutron- server、插件、代理之间通过消息队列（默认用 RabbitMQ实现）进行通信和相互协调。

数据库（默认使用 Maria DB）用于存放 OpenStack的网络状态信息、包括网络、子网端口、路由器等等。

客户端（Client）是指使用 Neutron服务的应用程序，可以是命令行工具（脚本）、 Horizon
（ OpenStack图形操作界面）和Nova计算服务等

举列说明：创建一个vlan10虚拟网络的流程
1.Neutron-server收到创建网络（ Network）的请求，通过消息队列（ RabbitMQ）通知已注册的 Linux Bridge插件，这里架设网络提供者为 Linux Bridge。
2.该插件将要创建的网络信息（如名称、ID值、ⅥANID等）保存到数据库中并通过消息队列通知运行在各个节点上的代理
3.代理收到信息后会在节点上的物理网卡上创建Ⅵan设备（比如物理接口的子接口Eth1.10），并创建一个网桥（比如 brgXXX）来桥接网络设备

二：各个组件（服务）详解

2.1：neutron-server

Neutron-server提供一组API来定义网络连接和IP地址，供Nova等客户端调用，它本身也是分层模型设计，其层次结构如下：

neutron-server包括四个层次：
（1）Resetful API：直接对客户端API服务，属于最前端的API,包括Core API和Extension API两种类型，Core API提供管理网络，子网和端口核心资源的 Resetful API；Extension API提供给网络管理路由器，负载均衡，防火墙，安全组等扩展资源的Resetful API
（2）Common Service：通用服务，负责对API请求进行检验，认证并授权。
（3）Neutron Core：核心处理程序，调用相应的API插件来处理API的请求。
（4）Plugin API：定义插件的抽象功能集合，提供通用调用插件API的接口，包括Core Plugin API和Extension Plugin API两种类型，Neutron Core通过Core Plugin API调用相应的Core Plugin，通过Extension Plugin API调用相应的Service Plugin

2.2：插件

Neutron遵循 OpenStack的设计原则，采用开放架构，通过插件、代理与网络提供者的配合来实现各种网络功能。
插件是 Neutron的一种API的后端实现，目的是增强扩展性。插件按照功能可分为Core Plugin和 Service Plugin两种类型
Core pugin提供基础二层虚拟机网络支持，实现网络、子网和端口核心资源的支持。
Service plugin是指 Core Plugin之外的其他插件，提供路由器、防火墙、安全组、负载均衡等服务支持
值得一提的是，直到 OpenStack的 Havana版本， Neutron才开始提供一个名为L3 Router Service Plugin的插件支持路由服务。
插件由 Neutron-server的 Core Plugin API和 Extension Plugin API调用，用于确定具体的网络功能，即要配什么样的网络，插件处理 Neutron- Server发来的请求，主要职责是在数据库中维护 Neutron网络的状态信息（更新 Neutron数据库），通知相应的代理实现具体的网络功能。每一个插件支持一组API资源并完成特定操作，这些操作最终由插件通过RPC调用相应的代理（ Agent）来完成。

2.3：代理和网络提供者

代理处理插件转来的请求，负责在网络提供者上真正实现各种网络功能。代理使用物理网络设备或者虚拟化技术完成实际的操作任务，如用于路由具体操作L3 Agent
插件、代理与网络提供者配套使用，比如网络提供者是 Linux Bridge，就需要使用 Linux Bridge的插件和代理，如换成 Open vSwitch，则需要改成相应的插件和代理。

三：neutron的物理部署

Neutron与其他 OpenStack服务组件系统工作，可以部署在多个物理主机节点上，主要涉及控制节点、网络节点和计算节点，每个节点可以部署多个，典型的主机节点部署介绍如下。

3.1：控制节点和计算节点

控制节点上部署 Neutron- service（API）、 Core Plugin和 Service Plugin的代理，这些代理包括 neutron-plugin-agent、 neutron-medadata-agent、 neutron-dhcp-agnet、 neutro-l3- agent、neutron- lba as-agent等。 Core plugin和 service plugin已经集成到 neutron-server中，不需要运行独立的 plugin服务。
计算节点上可以部署 Core Plugin、 Linux Bridge或 Open vSwitch的代理，负责体提供二层的网络功能
控制节点和计算节点都需要部署 Cere Plugin的代理，因为控制节点与计算节点通过该代理才能建立二层连接。

3.2：控制节点和网络节点

可以通过增加网络节点承担更大的负载，该方案特别适合规模较大的 OpenStack环境
控制节点部署 Neutron-server服务，只负责通过 Neutron-server响应的API请求。
网络节点部署的服务包括 Core Plugin的代理和 service Plugin的代理。将所有的代理从上述控制节点分离出来，部署到独立的网络节点上，由独立的网络节点实现数据的交换，路由以及负责均衡等高级网络服务。