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

0

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

架构

clipboard.png

线上

  • 接入层: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,监控
  • 文件发送:
    clipboard.png

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

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

详细公司内部部署方案

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

公司配置平台

配置(小于1m)

  • 同步下发过程

clipboard.png

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

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

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

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

监控

架构
clipboard.png

  • 日志agent
    clipboard.png
  • 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集群

你可能感兴趣的

载入中...