灰度发布_和 abtest (属于大数据架构部) 可衍生至 一键降级

流量选取适用于灰度发布，对选中的流量再次分组适用于AB测试及其他需要的场景。

处理方式：通常有物理隔离和逻辑隔离两种，物理隔离是将不同版本部署在不同集群，这样可以减少对代码的侵入，但是不够灵活，也难以支持大量的灰发或者实验并发；逻辑隔  离就是在代码里通过if else的方式对功能进行隔离，这种方式更为灵活，Apollo推荐的也是这种处理方式。

这种灰度设计好挫. 最好的灰度设计是通过dns解析或者流量路由到灰度集群上.灰度开关判断.

和ngnix的流量粘连设计类似.

交互模型：用户先在平台创建开关（灰度或者实验标识），然后在业务代码中将流量交给apoll 引擎（现在是sdk作为引擎）处理：.

技术点:

0. 重客户端,轻服务端. 本地缓存规则.  (和降级服务类似.

错误收集和使用两个地方)

1. 规则引擎 对应着就是一堆的json, mongo文档.

2. 灰度发布返回的是整型. 实验是返回的参数,控制相应的参数值. 比如一个模型的参数.

   记录进入实验的key, 用这些key向业务指标计算框架获取数据.

3. 业务指标系统hadoop. 业务部门开发,提供接口. 其实sql能搞定. 动态脚本 或者python引擎.

统一hash算法.. 通过转换成整型.

hashArray = SHA1(用户key+toggle名+规则名）：hashArray为20 byte。

算法是 安全 哈希算法（Secure Hash Algorithm）主要适用于 数字签名标准

abtest 平台化(没有大数据数据,无法有效的指标观察):

哪些平台适合apoll

• “有个功能有XX风险，希望必要的时候能够紧急关闭掉”
• “有个功能希望只有北京的人看到”
• “有个功能希望先让1%的用户看到”
• “有个功能希望只有1000个用户看到”
• “有个功能希望2015.09.09 19：09发布给所有用户看到”
• “有个功能我希望只让我女朋友看到”
• “有个功能希望安卓用户，oppo手机，坐标北京，有车，白领，没孩子，cbd上班，喜欢打车的10%用户在2015年10月1日看到”
• “我们产品线功能开发不完了，其他产品线不让延期怎么办？”

核心:

1. 可配置化的分组配置(主要是用户id,城市)

2.可配置统计的指标(根据用户id 聚合指标)

1.第一步：申请ABTEST平台权限

2. 第三步：平台配置

2.1 新建配置id.

2.2 城市维度选择,用户id导入,用户类型导入. ( 如何避免所有流量都要来查询是否单测. )

   先计算后得到一个用户是否需要ABTest评估. 倒排 生成一个Key(用户id)Value(规则列表). 这样获取不到即代表无,也不用

2.3 订阅指标