VIPServer：阿里智能地址映射及环境管理系统详解

作者：
周遥，阿里技术专家，花名玄胤，毕业于四川大学。六年大型分布式与中间件系统经验，三项国家专利，参加过多次“双十一”。2013年从零开始带出VIPServer，目前已成为集团环境管理与路由的标准。
王建伟，阿里巴巴工程师，花名正己，西北工业大学计算机学院硕士毕业。目前在阿里中间件技术部软负载小组负责VIPServer系统。
本文为《程序员》原创文章，未经允许不得转载，更多精彩文章请订阅2016年《程序员》

VIPServer是阿里内部使用最广的服务地址映射及环境管理系统。本文主要阐述VIPServer的项目背景、设计目的、架构演变及内部详细实现。

背景

寻址，意味着什么？当系统比较简单时，模块都集中在同一台服务器，调用都在内部——大家同住一个屋檐下，直接调用其接口便行。但在大型软件架构中，分布式占据了极其重要位置，不同的系统被分配到了不同的服务器上。首先相互发现便成了问题，因此业界诞生了许多配置服务器，类似的有阿里的ConfigServer或外界的ZooKeeper（使用其配置同步功能）。

但生产环境的地址映射并不是一个简单的反向代理，还需要考虑许多环境及路由策略问题。例如，阿里内部将开发环境分为了日常、预发与线上三套环境，不同环境之间的服务需要做到隔离（如图 1所示），即日常的终端不能拿到其它环境（如预发）的服务地址。与此同时，线上的服务始终是一个动态的服务，可能因为各种原因进行调整，如压测需要引流，灰度发布需要流程隔离等。

我们设计VIPServer，初衷仅仅是为了替换硬件负载均衡设备如F5（基于硬件的网络负载均衡设备，早期售价高达上千美元）或者阿里内部的LVS，主要原因如下：

1. 无论LVS还是F5都是代理的形式，必然存在网络瓶颈，对网络RT也有影响（需要中途转发一次）。
2. LVS、F5都需要实体机器支撑，不利于快速部署，需要预算、采购、安装、调试等诸多流程。
3. 它们都需要大量的资金来购买设备（虽然LVS相比F5成本已经小了很多）。
4. LVS、F5的服务面仅在当前网络，在需要跨地域、跨区域服务挂载时会变得非常困难。
5. LVS、F5是分散在各个应用中的，日常的管理也是由应用自己的系统工程维护的，不利于统一协调、管理。

图1 不同环境下的服务不能错调

开始时，用户并不认可VIPServer，因为当时LVS的管理流程与功能已经相当完备。仅出于成本或者减少网络延迟考虑并不能支撑一次底层迁移。不过，随着业务量发展，集团内的环境变得越来越复杂，单元化、隔离环境、准备环境层出不穷，上述LVS弊端便慢慢显现。后面我们为VIPServer加入了更多环境管理相关功能并逐渐改造架构——去掉所有（二方及三方）系统依赖与服务下沉成为基础中的基础产品，这使得VIPServer如今成为了环境认识、变更与维护的权威。

架构

初始架构

最早我们的首要目的是去除LVS及F5这类网关类型的反向代理结点，使内部应用调用都是以直连的形式进行。在这种构想下，终端向一个服务发起请求有以下步骤：

1. 终端依赖VIPServer客户端；
2. 向VIPServer客户端提供服务标识；
3. 客户端向服务发起查询并定期更新此标识对应的数据以保证服务地址的状态正确；
4. 客户端根据标识策略性地返回一个康健的地址给终端，这里康健与否由VIPServer服务端检测；
5. 终端根据地址直接发起服务调用，完成整个请求。

上述过程涉及四个模块：客户端、服务地址管理（添加、删除、存储）、服务状态检测以及服务地址返回策略。

客户端

客户端本不知道服务端地址，因此向服务端的请求本身也是个服务发现过程，存在“先有蛋还是先有鸡”的问题。为了解决这个循环依赖，我们引入了一个称为“地址服务器”的模块，其本质就是将一个静态包含VIPServer服务端IP地址列表的文件放至于一个Web服务上（我们使用的是Nginx），再申请一个DNS域名，用于发现此Web服务器地址，这样客户端便能得到VIPServer服务端的地址列表。我们不能简单使用DNS，因此VIPServer本身也需要区分各种环境，在Web服务上，我们会根据请求客户端的IP地址列表来返回对应环境的服务端地址列表。

服务