其实说白了，Octavia就是将用户的API请求经过逻辑处理，转换成Haproxy或者Nginx的配置参数，下发到amphora虚机中。
Octavia的内部实现中，逻辑流程的处理主要使用TaskFlow库。
【基本概念】
·LBaas
Load Balancing as a Service，在openstack平台上，LB被作为一种服务提供给用户，用户可以按需获取可配置的业务负载分担方案。
·loadbalancer
负载均衡服务的跟对象，一般为虚机，用户基于此对负载均衡进行配置和操作。
·VIP
与LB关联的IP地址，作为外部访问后端服务的入口。
·Listener
监听器，用户可通过其配置外部对VIP访问的端口，算法，类型等等。
·Pool
负责后端的虚拟机池。在Haproxy为driver的情况下，一个Pool对应着一个独立的network namespace中运行的HaProxy进程中管理的backend。
一个VIP只会有一个Pool。
·Member
Member 对应的是 pool 里面处理网络请求的一个 OpenStack Nova 虚机。
·Health monitor
它用来检测pool里面的member的状态，支持很多种检测方法，在neutron里面是可选的。
·L7 Policy
七层转发策略，描述数据包转发动作。
·L7 Rule
七层转发规则，描述数据包转发的匹配域。（匹配部分云主机）
基本概念之间的交互流程如下图：
【基本架构】
我们依旧从部分开始介绍：
·Amphora
负载均衡的载体，一般为云主机。（当然也可以使用物理机，将多个负载均衡配置到同一/两台Amphora节点上，提高数据包转发效率，但是有单点故障隐患）
·manage-network
管理网络，通常管理数据走这条线路，东侧连接Amphora，西侧连接Octavia服务进程。
·tenant-network
租户网络，内部通信使用，SLB转发报文通过租户网络到各个后端服务器上。
·vip-network
服务地址，主要用于对外提供服务。
PS：vip-net和tenant-net可以是同一个网络，但是在生产环境中建议分开，以便于更好得划分网络安全隔离。
·VM
后端服务器，用户的真实服务器。
·health-manager
octavia里面进行健康检查的进程，主要有以下两个作用：
1. 监听来自amphora虚拟机发来的运行状态数据，以此更新lb，listener，pool，member的状态，同时更新listener_statistics表（可作为计费依据），最重要的是更新amphora_health表。
2. 根据amphora_health数据表中的数据，找到异常状态的amphora虚拟机，对该虚拟机进行更换操作。（即删除旧的虚拟机，创建新的虚拟机并下发配置）
·house-keeping
名副其实的 Housekeeping（家政）服务，保障 Octavia 的健康运行。
主要实现三个功能：
SpareAmphora: 清理虚拟机的池子, 确保空闲的amphorae池大小。
DatabaseCleanup: 定期清理数据库中已删除的amphorae记录。
CertRotation: 定期更新amphorae中的证书。
·Octavia Worker
负责完成 API 请求，是 Octavia 主干功能的执行者。
主要作用是和nova，neutron等组件通信，用于虚拟机调度以及把对于虚拟机操作的指令下发给octavia agent。
基本流程如下：