整体：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集群