【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集羣