aserver配置解析之单元化规则

最近有空把aserver的线上配置看了一遍，大体上了解了接入层对整个请求的流转和控制。
aserver是tengine的一个分支，其中包含了很多的私有指令，不过大部分根据指令名称也能猜出个大概。
本篇主要是讲解一下单元化规则的相关内容。
我理解的单元化规则问题，就是当用户请求过来的时候，aserver如何能转发到对应单元的后端upstream机器。那么就来看一下如何根据用户区分单元。
在cell_location_mtop.conf里，

set $cell_random 1;
set_by_lua_file $armory_self_cell /home/admin/cai/conf/nginx_lua_armory_cell.lua;
set_by_lua_file $cell /home/admin/cai/conf/set_user_unit.lua $cookie_unb $router_rule;
这里设置cell_random为1，是表示当用户未登录或者为访客时，将进行随机的单元化分配，而默认情况下，客户端连接的是最后一次分配到的单元aserver。

再来看nginx_lua_armory_cell.lua，
首先判断armory_cell这个变量是否存在，这个变量是从armory上取下来的，指令是在nginx_aserver.conf的这里：

armory_role $armory_cell CENTER_UNIT.center;
这条指令的含义是：从armory上取本机所属的单元，若取不到则置为中心。
接着进行判断，

若不存在，则直接取center
若存在，则取CENTER_UNIT.之后的单元字符串 这样，便取到了armory_self_cell的值，理论上应该为center,unit,unsz,unyun这几个值
接下来看set_user_unit.lua
先取一个默认的单元，

local default_unit
if ngx.var.cell_random then
default_unit = ngx.var.armory_self_cell
else
default_unit = “center”
end
接下来获取用户的userid，一共有3个来源

cookie里的unb
cookie里的munb
http请求头里的x-uid
local userid = ngx.var.cookie_unb
if userid == nil or userid == “” then
userid = ngx.var.cookie_munb
if userid == nil or userid == “” then
userid = ngx.req.get_headers()[“x-uid”]
if userid == nil or userid == “” then
return default_unit
end
end
end
下面是解析用户尾号的分布了，我们从diamond的dataid为com.ali.unit.routerule，groupid为DEFAULT_GROUP拉取单元化规则，这个指令是在nginx_aserver.conf里。

diamond_app DEFAULT_GROUP com.ali.unit.routerule $router_rule $router_ver;
这个配置是下面这种格式：

unit:{(userId % 10000) % 10000 in (6700…6799)}
{10.177.32.0/24,10.177.33.0/24,10.177.34.0/24,10.17
第一行用来判断用户尾号是否在对应的区间内。其中有两种规则：
精确规则： 形式是unit:{1 3 5 7 9}，此种模式可以将指定的多个独立尾号用户引流至同一单元，且此种模式优先级要高于普通规则。
普通规则： 形式是unit:{(userId % 10000) % 10000 in (6700…6799)}，这个就不说了，要注意的是这种规则下只能指定一个区间。
第二行用来指示该单元对应的机器网络分布。这样后面从vipserver拉取upstream的机器列表的时候，就能够判断区分到底取哪些单元的机器了。
那么问题来了，假如多个单元的分布规则区间合并完并不能包含所有尾号，那么怎么分配呢？比如像下面这样：

unit:{(userId % 10000) % 10000 in (6700…6799)}
{10.177.32.0/24,10.177.33.0/24,10.177.34.0/24,10.17

unsz:{(userId % 10000) % 10000 in (7000…9999)}
{10.185.36.0/24,10.185.37.0/24,10.185.38.0/24,10.18

unyun:{(userId % 10000) % 10000 in (10000…10000)}
{10.185.248.0/24,10.185.249.0/24,10.185.250.0/24,10

CENTER:{(userId % 10000) % 10000 in (0…6699)}
{10.0.0.0/8,172.0.0.0/8,192.168.0.0/16}

那么尾号6900的用户如何分配呢？
以前的逻辑是返回default_unit，如上面代码的分析，这个值取的是机器所在的单元。
那么当某个单元流量已经切走，而客户端的单元规则还没有更新的时候，客户端就仍然请求到了这个没有流量的单元，这样，跨单元的问题最终只能在hsf被纠正。这也是一个"诡异"的跨单元问题排查产生的原因。不过现在已经修改过了，找不到匹配的区间，直接返回’center’。

整体的判断逻辑如下：

这个只是aserver上的规则判断，其实有很多细节问题还没有搞清楚，尤其是和客户端的策略配合，是比较复杂的，后面得慢慢了解。下篇会再讲一下详情的配置。