全流程上线平台

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

架构

线上

• 接入层：nginx 攻防（白名单，黑名单，封禁，限流），机房切换。
• 运行层：
  包（一个完整 可运行的业务代码 + 基础环境 + 基础包）+ 容器 + 资源隔离 + 部署。容器见：
• 运行层和接入层联动

平台

• 代码版本，配置存储；回滚；分级发布，跑 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 的生成

监控

架构

• 日志 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 集群