【3.工程开发】-全流程上线平台

整体：https://segmentfault.com/a/11...。服务化建设，服务多，上线和部署成本高，本文介绍全流程上线部署平台的设计方案。

架构

线上

• 接入层：nginx攻防（白名单，黑名单，封禁，限流），机房切换。
  1）.nginx的限流:令牌桶思想

  算法思想是：
  令牌以固定速率产生，并缓存到令牌桶中；
  令牌桶放满时，多余的令牌被丢弃；
  请求要消耗等比例的令牌才能被处理；
  令牌不够时，请求被缓存。
  ms = (ngx_msec_int_t) (now - lr->last)
  excess = lr->excess - ctx->rate * ngx_abs(ms) / 1000 + 1000;
  if ( excess > limit->burst) { busy }
  比如1s最多10个、10ms来了一个。突发最大多5，  acess=1000- 10*10 = 900 < 5000
  11ms来了一个。    acess=900-10*1+1000=1890
  12ms             access=1890-10+1000=2890
  13                                    3890
  14ms                                4890
  15ms                                busy
  34ms                 4890-30*10+1000=4990就可以继续

  2）.这里的最大并发，brpc有一个自适应限流：https://github.com/apache/inc...
  max_concurrency自适应latency公式：
  max_concurrency = max_qps ((2+alpha) min_latency - latency)
  min_latency是最近一段时间测量到的latency较小值的ema，是noload_latency的估算值。
  latency是当前采样窗口内所有请求的平均latency。
  max_qps是最近一段时间测量到的qps的极大值（回复的）

  min_latency：每隔一段时间缩小max_concurrency，过一小段时间后（ latency * 2）以此时的latency作为noload_latency
  if latency > min_latency:
      min_latency = latency * ema_alpha  + (1 - ema_alpha) * min_latency
  else:
      do_nothing
  
  max_qps:
      if current_qps > max_qps:
          max_qps = current_qps
      else: 
          max_qps = current_qps * ema_alpha / 10 + (1 - ema_alpha / 10) * max_qps
  将max_qps的ema参数置为min_latency的ema参数的十分之一的原因是: max_qps 下降了通常并不意味着极限qps也下降了。而min_latency下降了，通常意味着noload_latency确实下降了。

  慢启动解决：

  1. 采样方面，一旦采到的请求数量足够多，直接提交当前采样窗口，而不是等待采样窗口的到时间了才提交
  2. 计算公式方面，当current_qps > 保存的max_qps时，直接进行更新，不进行平滑处理。
• 运行层：
  包（一个完整 可运行的业务代码+基础环境+基础包）+容器+资源隔离+部署。容器见：
• 运行层和接入层联动

平台

• 代码版本，配置存储；回滚；分级发布，跑case,监控
• 文件发送：
  

  产品线生产数据①之后，调用文件飞线的客户端（图中为orp_scp.sh）,指定好数据源，发到服务端（图中为中控机），服务端从ORP的基础设施NamingService读取产品线所在的机器及相关路径，然后进行部署（③④⑤）。产品线用户可以通过查看ORP平台，获得部署的进度和部署的结果（成功或失败）

• 定时任务：
  添加任务：发到任务平台，注册到计时器，存到任务集
  独立计时器触发，任务平台去任务集中取任务部署到任务平台，工作。
• 日志重建
  线上日志采集agent。发到传输集群。消费到日志机器
• 集群管理
  机器 backpool->online->故障池->backpool
  容器 创建资源（更新nameserver，新增ip）->迁移/释放=》更新nameserver（监控）=》更改接入层
  router这里做机房切换。节点监控改router
  内部可以服务发现+rpc,每次获取nameserver转发，或Push
  nameserver 发给mq 发给接入层/监控等
• 部署
  提交到任务队列（有序）-》mq=》部署拉取=》线上脚本执行重启等
  
  deploy会先将任务存进任务队列，然后推给消息中间件。消息中间件后端会重新发回deploy（如果失败，消息中间件负责重试）。Deploy会对文件进行下载、打包封装，然后调用archer将文件分发到机器上的临时目录上。最终调用deploy的后置脚本进行最终的部署。

详细公司内部部署方案

• 过程
  
  0.外部请求输
  1.打包，打包机将部署包存放在指定的Artifact上
  2.发起上线
  Api实现上线的控制逻辑，相当于传统的中控
  Api向部署Agent发送上线指令
  3.执行上线
  部署Agent下载部署包
  部署Agent指定上线业务
  部署Agent向Api上报 上线的执行结果
• agent
  
• build:
  完成 源文件的build，产出可执行文件
  完成 配置管理的替换，产出可用配置文件
  完成 进程托管配置supervisord.conf的生成
  完成 服务描述文件me.json的生成

公司配置平台

配置（小于1m）

• 同步下发过程

平台=》分发集群+zk=》业务机器的agent=》业务sdk

• 缓存
  agent缓存到本地文件，sdk读取本地文件到内存（稳定性）
  db=>zk=>本地文件=>sdk内存
• 一般都是拉（包括上线，配置，文件等）

公司ab实验/灰度发布平台

• 配置发布解析略
• 流量划分：hash+salt/固定桶。相同实验的salt一样保证key返回不变
• ab实现的信息统计
  
  异常剔除：boxplot箱线图
  把离线计算给了平台统一，基本上spark，存储parquet。查询hbase0维度聚合之类的
  实时分析：kafka+自定义index+ES

监控

架构

• 日志agent
  
• collector是用户上传数据等另一种输入
• nsq:负责接收，排队，消息投递；消息缓存
• 存储
  transfer:按照一致性哈希规则进行数据分片，并将分片后的数据推送到graph中存储,基于RRD规则，对数据进行简单处理，包括时间戳按照step对齐、添加必须的字段(MAX/MIN等)
  graph,接收transfer上报的数据，raph推送数据到index，中间通过nsqd 做消息队列(没有proxy转发)，减轻index的实时压力
  Round Robin是一种存储数据的方式，使用固定大小的空间来存储数据，并有一个指针指向最新的数据的位置
  RRDtool 要求定时获取数据，如果在一个时间间隔内（heartbeat）没有收到值，则会用 UNKN (unknow)代替
• 报警
  1）.monitor-judge
  通过config获取报警配置策略
  通过index获取索引，通过query查询数据
  judge数据直接推送到nsqd的4151端口(nsqd广播数据到lookupd的4160端口)
  judge产生报警事件
  2）.odin-monitor-alarm
  通过monitor-web接口获取报警策略、屏蔽策略
  通过nsq的lookupd(4161端口)查询对应nsqd地址并消费报警事件
  通过本机部署的redis(监听端口6379)，作缓存
  报警事件写入到后端数据库中(dba维护)
  报警通知 经过nginx做中转，转发到notify集群