【3.工程開發】-微服務建設相關

本篇只講下僅僅因爲微服務後，須要改變增長的東西。
可見：服務發現。拓撲。問題定位。監控。
可控：全鏈路故障演練/壓測。配置中心/全流程部署（部署會頻繁，擴縮容頻繁）
本文服務發現
問題定位/拓撲：https://segmentfault.com/a/11...
全流程部署/配置中心/監控：https://segmentfault.com/a/11...
全鏈路故障演練/壓測：https://segmentfault.com/a/11...
更多工程：https://segmentfault.com/a/11...

服務發現過程

服務發現和註冊文章：https://www.nginx.com/blog/se...。這裏只講下公司的應用方案

服務發現

背景：替換原有Thrift要配置全部IP
一個新服務，人工服務註冊：建立一個服務發現節點，路由規則配置；流量調度；人工服務摘除；
1.調用方
每臺機器上有agent.sdk.兜底文件，實時文件，訪問disf先本地實時文件，兜底ip

• 兜底文件的產生：
  1.1代碼掃描 與平臺配置結果比對，校驗
  1.2.編譯後生成output/__naming__/__self.json
  1.3.odin構建到disf平臺取配置做爲兜底文件
  2.部署包根據部署集羣，部署本身集羣的__naming__/兜底
  ps:打包時會額外作：第一次打包生成__naming__目錄,兜底包含全部ip，更新推方式更改掃描檢查配置,第二次生成.deploy (部署節點信息,odin根據不一樣節點打包生成每一個集羣的ip)
• 實時文件產生
  agent啓動時。odin部署系統上線中，啓動前會上報集羣。到disf-agent。取配置。生成到/home/xiaoju/.service/disf中
  配置變動時。在平臺操做，文件直接推送到agent。
  常態運行時，agent按期掃描文件版本上報平臺，平臺校驗後下發版本異常文件到agent
  
• agent與conf長鏈接（grpc）
  交互過
  
• 自動摘除/發現
  摘除：php類點多服務公用一個端口，一個unregester會致使全部都。上線時會大量的unregester或者exist出現抖動,機器掛掉不會自動摘除，只是返回一個ip列表（只有服務發現。dirpc負責負載均衡，健康檢查，自動摘除）
  發現：不自動發現，起了服務不必定要正式到線上

xrpc

功能

內置服務發現 （直接獲取endpoint等）
支持多語言多協議
標準化日誌輸出&監控，標準化服務調用規範（統一提供sdk）
容錯機制（故障摘除，過載保護，負載均衡）

代碼

1.獲取endpoint信息，生成sign等初始
2.server管理服務器，負載均衡，過載保護
以邏輯機房爲管理力度，minHealthyRatio等配置，ip/port列表，狀態，balancer

• filter 白名單，黑名單，是否跨機房
• 故障摘除
  對節點採起投票，訪問失敗+1，訪問成功-1，票數最低爲0；每一個節點的票數表明了其健康度，值越大說明越不健康，越小越健康； 投票數超過閾值即被認定爲不健康，默認指導配置爲10，即一個節點的投票數大於10則被認定爲不健康。
  流量調度只在健康節點進行選擇，即非健康節點則認爲被故障摘除。
  另外節點被標記爲非健康的時間超過冷卻時長後，下次從新生成健康列表時，則將其看成健康節點對待，即故障恢復。默認指導值爲60s。

• 過載保護（只是防止可用節點太少，可用節點被打掛）

  防止大量節點被標記爲非健康後，流量打到集中的下游上，設置一個最低健康比例，當健康節點數的佔比低於最低比例時，按最低比例挑選健康度最好的節點，構建健康列表，即最小可用度。

  隨着業務的不斷變遷，理想狀況下最小可用度要能根據全鏈路容量壓測進行自動適應。但根據滴滴目前的現狀，資源管理還比較粗放，前期這個值能夠設置的相對保守。當前最小可用度默認指導配置爲0.67，即保證至少有2/3的節點可用，也即最多可剔除對1/3故障節點的訪問。

• 負載均衡
  只支持在健康節點之間挑選，當最小可用度不足時，經過非健康節點補充。目前已支持Random、Hash兩種調度策略，RR暫不支持。

3.send
4.根據是否成功 vote php是記到apcu(緩存中),不支持就沒法投票。這個各自調用方投票記錄在不一樣地方，各自判斷，各自摘除。沒法相互獲取到其餘的投票結果。
5.記錄log

servicemesh概述

架構上分爲數據平面和控制平面兩個部分，其中數據平面負責代理微服務之間的通訊，具體包含RPC通訊、服務發現、負載均衡、降級熔斷、限流容錯等，數據平面能夠認爲是微服務框架的通訊和服務治理能力獨立而成的一個單獨的語言無關的進程，而且更注重通用性和擴展性，在Service Mesh中，再也不將數據平面代理視爲一個個孤立的組件，而是將這些代理鏈接在一塊兒造成一個全局的分佈式網絡；控制平面負責對數據平面進行管理，定義服務發現、路由、流量控制、遙測統計等策略，這些策略能夠是全局的，也能夠經過配置某個數據平面節點單獨指定，控制平面經過必定的機制將策略下發到各個數據平面節點，數據平面節點在通訊時會使用這些策略。

Istio

以Envoy爲基礎，將Envoy做爲默認的數據平面，同時提供強大的控制平面能力。

控制：
Pilot、Mixer和Security是Istio 的3大核心組件，分別負責Istio配置管理、策略和遙測以及通訊安全的實現。
pilot:提供通用的配置管理能力，保證不一樣平臺、不一樣環境下的配置均可以經過一致的方式對Envoy進行配置和下方,負責Envoy的生命週期管理，啓動Envoy，而後監控Envoy的運行狀態.啓動，調度到其餘節點等
mixer: 收集遙測統計相關的數據和指標，能夠對服務進行全方位的監控,策略控制:對於一些核心資源，須要經過必定的策略，在不一樣消費服務以及服務的不一樣實例中進行分配，保證資源可以按照預期進行管理.

數據envoy

是一個用 C++ 編寫的雲原生高性能邊緣代理、中間代理和服務代理，做爲專門爲微服務架構設計的通訊總線。
Envoy做爲一個獨立進程，設計爲和每一個應用程序一塊運行，全部的 Envoy 造成一個透明的通訊網格，每一個應用程序發送消息到本地Envoy代理或從本地Envoy代理接收消息，但不須要知道具體的網絡拓撲。