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

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

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

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

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


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



技术点:

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

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

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

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

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

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

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

统一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 订阅指标灰度发布_和 abtest (属于大数据架构部) 可衍生至 一键降级_第2张图片

你可能感兴趣的:(架构,微服务)