1到底什麼是微服務

• 單體應用
  • 部署效率低
  • 團隊協作開發成本高
  • 系統高可用性差
  • 線上釋出變慢
• 什麼是服務化
  • 單體應用中通過jar包依賴產生的本地方法呼叫，改成通過RPC遠端方法呼叫
• 什麼是微服務
  • 服務拆分力度更細
  • 服務獨立部署
  • 服務獨立維護
  • 服務治理能力要求高
    #2單體走向微服務#
• 單體遷移到微服務遇到的問題？
  • 服務如何定義
  • 服務如何釋出與訂閱
  • 服務如何監控
  • 服務如何治理
  • 故障如何定位
    #3微服務架構#
• 基本元件
  • 服務描述
    • 服務如何對外描述？
    • 服務名叫什麼？
    • 呼叫這個服務需要提供哪些資訊？
    • 呼叫這個服務返回的結果是什麼格式的？
    • 該如何解析？
  • 註冊中心
    • 解決服務的釋出與訂閱
      • 提供者登記
      • 消費者獲取地址 發請求
  • 服務框架
    • 服務通訊採用什麼協議？
    • 資料傳輸採用什麼方式？
    • 資料壓縮採用什麼格式？
  • 服務監控
    • 指標收集
    • 資料處理
    • 資料展示
  • 服務追蹤
    • 服務呼叫情況
  • 服務治理
    • 單機故障
    • 單IDC(網際網路資料中心)故障
    • 依賴服務不可用
      #4如何釋出與引用服務#
• 方式
  • restful api
    • 跨語言
  • xml
  • idl檔案
    • 跨語言
      平臺呼叫
    • Thrift協議
    • gRPC協議
      #5如何註冊與發現服務#
• 註冊中心原理
  • 服務提供者RPC server
  • 服務消費者 RPC Client
  • 服務註冊中心 Registry
• 註冊中心實現方式
  • 註冊中心API
    • 服務註冊介面
    • 服務反註冊介面
    • 心跳彙報介面
    • 服務訂閱介面
    • 服務變更查詢介面
  • 叢集部署
    • 叢集部署保證高可用性
    • 分散式一致性保證資料一致性
  • 目錄儲存
  • 服務健康狀態監測
  • 服務狀態變更通知
  • 白名單機制
    #6如何實現RPC遠端服務呼叫#
• 服務消費者
  • 客戶端
• 服務提供者
  • 服務端
• 呼叫過程
  • 成一次 RPC 呼叫，就必須先建立網路連線。建立連線後，雙方還必須按照某種約定的協議進行網路通訊，這個協議就是通訊協議。雙方能夠正常通訊後，服務端接收到請求時，需要以某種方式進行處理，處理成功後，把請求結果返回給客戶端。為了減少傳輸的資料大小，還要對資料進行壓縮，也就是對資料進行序列化
• 客戶端和服務端如何建立網路連線？
  • HTTP通訊
    • 基於TCP/IP協議
  • Socket通訊
    • 運行於客戶端 clientSocket
    • 運行於服務端 serverSocket
    • 步驟
      • 伺服器監聽
        • serverSocket bind()繫結埠，呼叫listen()實時監控網路狀況，等待客戶端的連線請求
      • 客戶端請求
        • clientSocket connect()函式 向serverSocket繫結的地址埠發起請求
      • 連線確認
        • 服務端監聽或收到客戶端的連線請求時，呼叫accept()響應客戶端請求，並建立連線
      • 資料傳輸
        • 建立連線後，客戶端呼叫send() 服務端呼叫receive()函式，服務端處理完請求後，服務端呼叫send()客戶端呼叫recevice()得到返回結果。
    • 異常情況
      • 鏈路存活檢測
        • 客戶端定時傳送心跳檢測給服務端，連續N次或者超出規定時間沒有回覆則認為鏈路已經失效
      • 斷連重試
        • 等待固定時間發起重連
• 服務端如何處理請求？
  • 同步阻塞BIO
  • 同步非阻塞NIO
  • 非同步非阻塞AIO
  • 建議採取業界開源框架 Netty Mina
• 資料傳輸採用什麼協議？
  • Http協議
  • Dubbo協議
• 資料該如何序列化和反序列化？
  • 編碼與解碼就是序列化與反序列化
  • 常見序列化方式
    • 文字類
      • xml
      • json
    • 二進位制
      • PB
      • Thrift
  • 使用考慮因素
    • 支援資料結構的豐富程度
    • 跨語言支援
    • 效能{壓縮比與序列化速度}
      #7如何監控微服務呼叫#
• 監控的物件是什麼？
  • 使用者端監控
  • 介面監控
  • 資源監控
  • 基礎監控
• 具體監控哪些指標？
  • 請求量
    • 實時請求量QPS 每秒查詢次數
    • 統計請求量PV 一段時間內使用者訪問量
  • 響應時間
    • P99=500ms 意思是 99% 的請求響應時間在500ms以內，它代表了請求的服務質量，即 SLA。
  • 錯誤率
    • 一段時間內呼叫失敗的次數佔呼叫總次數的比率來衡量
• 從哪些維度進行監控？
  • 全域性維度
  • 分機房維度
  • 單機維度
  • 時間維度
  • 核心維度
    • 核心與非核心部署隔離，分開監控
• 監控系統原理
  • 資料採集
    • 分類
      • 服務主動上報(程式碼中加入收集邏輯)
      • 代理收集(日誌檔案–>解析–>上報)
    • 考慮點
      • 取樣率 採集資料的頻率
      • 動態採集
  • 資料傳輸
    • 傳輸方式
      • UDP
      • Kafka
    • 資料格式十分重要
      • 二進位制協議
        • 最常用的就是 PB 物件，它的優點是高壓縮比和高效能，可以減少傳輸頻寬並
          且序列化和反序列化效率特別高
      • 文字協議
        • 最常用的就是 JSON 字串，它的優點是可讀性好，但相比於 PB 物件，傳輸佔
          用頻寬高，並且解析效能也要差一些
  • 資料處理
    • 資料聚合維度
      • 介面維度
      • 機器維度
    • 持久化資料庫
      • 索引資料庫 ES
      • 時序資料庫 OpenTSDB
  • 資料展示
    • Dashboard
  • 擴充套件
    • skywalking是一款優秀的支援java語言的監控系統
    • 錯誤率是個很重要的業務指標
      #8如何追蹤微服務呼叫#
• 服務追蹤的作用
  • 優化系統瓶頸
  • 優化鏈路呼叫
  • 生成網路拓撲
  • 透明傳輸資料
• 原理
  • 呼叫鏈：通過全域性ID將分佈在各個服務節點的同一次請求串聯，還原所有呼叫關係
  • 基本概念
    • traceId
      • 標識某一次具體請求ID
    • spanId
      • 標識一次RPC呼叫在分散式請求中的位置{0 0.1 0.1.1 0.2}
    • annonation
      • 業務自定義埋點資料
• 服務追蹤系統實現
  • 資料採集層
    • 資料埋點
      • cs
      • sr
      • ss
      • cr
  • 資料處理層
    • 實時資料處理
      • 採用Storm,呼叫鏈路資料的實時查詢主要是通過Hbase，使用traceID作為RowKey，能天然的把一整條呼叫鏈聚合在一起，提高查詢效率。
    • 離線資料處理
      • Mapreduce Spark批處理，儲存使用Hive
  • 資料展示層
    • 呼叫鏈路圖
    • 呼叫拓撲圖
      #9微服務的治理手段有哪些？#
• 常用服務治理手段
  • 節點管理
    • 註冊中心主動摘除機制
      • 服務提供者心跳彙報，超時摘除
    • 服務消費者摘除機制
      • 如果服務消費者呼叫服務提供者節點失敗，就將這個節點從記憶體中儲存的可用服務提供者節點列表中移除。
  • 負載均衡
    • 隨機演算法
      • 均勻
    • 輪詢演算法
      • 權重
    • 最少活躍呼叫演算法
      • 效能理論上最優，選擇連結數最小的
    • 一致性hash演算法
      • 相同引數的請求總是發到同一服務節點
  • 服務路由
    • 路由規則
      • 就是通過一定的規則如條件表示式或者正則表示式來限定服務節點的選擇範圍
      • 原因
        • 業務存在灰度釋出的需求
        • 多機房就近訪問的需求
          • 一般可以通過 IP 段規則來控制訪問，在選擇服務節點時，優先選擇同一 IP 段的節點
      • 路由規則配置
        • 靜態配置
          • 消費者本地存放呼叫的路由規則
        • 動態配置
          • 路由規則存在於註冊中心，服務消費者請求註冊中心來更新配置
  • 服務容錯
    • FailOver
      • 失敗自動切換
      • 冪等
    • FailBack
      • 失敗通知，根據返回訊息決定策略
    • FailCache
      • 失敗快取 隔一段時間發起請求
      • 冪等
    • FailFast
      • 快速失敗 非核心業務
        #10Dubbo框架裡的微服務元件#
• Dubbo
  • 服務的釋出與引用
  • 服務的註冊與發現
  • 服務呼叫
  • 服務監控
  • 服務治理
    #11服務釋出和引用的實踐#
• XML 配置方式的服務釋出和引用流程
  • 服務提供者定義介面
  • 服務提供者釋出介面
  • 服務消費者引用介面
• 坑
  • 服務釋出預定義配置
  • 服務引用定義配置
  • 服務配置升級
    #12如何將註冊中心落地？#
• 註冊中心如何儲存服務資訊
  • 服務資訊 Cluster
    • 節點資訊
    • 請求失敗重試次數
    • 結果是否壓縮
  • 分組 Node
    • 機房
    • 核心與非核心
    • 測試環境與線上環境
  • 服務名 Service
• 註冊中心是如何工作的
  • 服務提供者註冊流程
    • 首先檢視要註冊的節點是否在白名單內？如果不在就丟擲異常，在的話繼續下一步。
    • 其次要檢視註冊的 Cluster（服務的介面名）是否存在？如果不存在就丟擲異常，存在的話繼續
      下一步。
    • 然後要檢查 Service（服務的分組）是否存在？如果不存在則丟擲異常，存在的話繼續下一步。
    • 最後將節點資訊新增到對應的 Service 和 Cluster 下面的儲存中
  • 服務提供者反註冊流程
    • 檢視服務的分組是否存在
    • 檢視服務的節點是否存在
    • 刪除儲存在service和cluster中的節點資訊
    • 更新Cluster的sign值
  • 服務消費者查詢流程
    • 本機記憶體中查詢
    • 本地快照中查詢
  • 服務消費者訂閱變更流程
    • 本地保留Cluster的Sign
    • 隔斷時間呼叫getSign()對比 不一致拉取最新的並更新
• 註冊與發現的幾個問題

  • 多註冊中心

    • 服務消費者要具備在啟動時，能夠從多個註冊中心訂閱服務
    • 服務提供者在啟動的時候，要能夠同時向多個註冊中心註冊服務

  • 並行訂閱服務

  • 批量反註冊服務

    • 殭屍節點

  • 服務變更資訊增量更新

    • 增量更新方式 註冊中心只返回變化的那部分節點資訊，尤其在只有少數節點資訊變更時
      #13開源服務註冊中心如何選型？#
• 主流解決方案
  • 應用內註冊與發現
    • SDK
    • Eureka
      • Eureka Server：註冊中心的服務端，實現了服務資訊註冊、儲存以及查詢等功能
      • 服務端的 Eureka Client：整合在服務端的註冊中心 SDK，服務提供者通過呼叫 SDK，實現服務
        註冊、反註冊等功能
      • 客戶端的 Eureka Client：整合在客戶端的註冊中心 SDK，服務消費者通過呼叫 SDK，實現服務
        訂閱、服務更新等功能
  • 應用外註冊與發現
    • Consul
      • Consul:註冊中心的服務端，實現服務註冊資訊的儲存，並提供註冊和發現服務
      • Registrator:一個開源的第三方服務管理器專案，它通過監聽服務部署的 Docker 例項是否存
        活，來負責服務提供者的註冊和銷燬
      • Consul Template:定時從註冊中心服務端獲取最新的服務提供者節點列表並重新整理 LB 配置（比
        如 Nginx 的 upstream），這樣服務消費者就通過訪問 Nginx 就可以獲取最新的服務提供者資訊
• 考慮因素
  • 高可用性
    • 叢集部署
    • 多IDC部署
  • 資料一致性
    • CAP理論
      • CP
        • Zookeeper
      • AP
        • Eureka
        • 服務註冊中心對可用性的要求高於一致性 只要保證最終的一致性就好
          #14開源RPC框架如何選型#
• 分類
  • 特定語言平臺繫結
    • Dubbo java
      • 4大角色
        • 服務消費者
        • 服務提供者
        • 註冊中心
        • 監控系統
      • Dubbo SDK
      • 呼叫框架
        • 通訊框架
          • Netty
        • 通訊協議
          • 私有Dubbo協議，還支援 RMI 協議、Hession 協議、HTTP 協議、Thrift 協議等
        • 序列化與反序列化
          • Dubbo、Hession、JSON、Kryo、FST
    • Motan java
      • 功能模組
        • register
        • protocol
        • serialize
        • transport
        • cluster
    • Tars c++
    • spring cloud java
  • 平臺語言無關
    • gRPC
      • 通訊協議採用HTTP2
      • IDL使用ProtoBuf
      • 多語言支援
    • Thrift
      #15如何搭建一個可靠的監控系統#
• 實現方案
  • 集中式日誌解決方案
    • ELK Elasticsearch、Logstash、Kibana 三個開源軟體產品首字母的縮寫
      • Logstash 資料收集與傳輸
      • ElasticSearch 資料處理
      • Kibana 資料展示
      • Beats (傳送到LogStash)
        • 資料來源
          • Packetbeat： 網路資料流量
          • Topbeat： 收集系統程序 cpu 記憶體使用情況
          • Filebeat： 收集檔案資料
          • Winlogbeat： 收集Windows 日誌 資料
  • TICK 時序資料庫解決方案
    • Graphite
      • Carbon
      • Whisper
      • Graphite-Web
    • TICK
      • Telegraf、InfluxDB、Chronograf、Kapacitor 四個軟體首字母的縮寫
    • Prometheus
      #16如何搭建一套適合你的服務追蹤系統？#
• 實現
  • 埋點資料收集
  • 實時資料傳輸
  • 鏈路資料展示
• 實現方案
  • OpenZipKin
    • Collector
    • Storage
    • API
    • UI
  • Pinpoint
    • Pinpoint Agent
    • Pinpoint Collector
    • HBase Storage
    • Pinpoint Web UI
• 選型對比
  • 埋點探針支援平臺的廣泛性
  • 系統整合的難易程度
  • 呼叫鏈路的精準度
    #17如何識別服務節點是否存活#
• Zookeeper管理註冊節點
  • 註冊中心摘除機制
  • 網路頻繁抖動會可能會摘除節點
• 解決方案
  • 心跳開關保護機制
    • 設定開關
  • 服務節點摘除保護機制
    • 設定閾值比例 不能摘除超過閾值比例的節點 20%
  • 靜態註冊中心
    • 心跳機制設定在服務消費者端 儲存某個服務的可用節點
      #18如何使用負載均衡演算法？#
• 引入原因
  • 考慮呼叫的均勻性
  • 考慮呼叫的效能
• 常見演算法
  • 隨機演算法
  • 輪詢演算法
  • 加權輪詢演算法
  • 最少活躍連線演算法
  • 一致性hash演算法
  • 自適應最優選擇演算法
    • 比重
    • 時長 1min
      #19如何使用服務路由#
• 服務路由
  • 服務消費者在發起服務呼叫時，必須根據特定的規則來選擇服務節點，從而滿足某些特定的需求
• 應用場景
  • 分組呼叫
  • 灰度釋出(金絲雀部署)
  • 流量切換
  • 讀寫分離
• 服務路由的規則
  • 條件路由
  • 指令碼路由
• 服務路由的獲取方式
  • 本地配置
    • 儲存服務消費者本地
  • 配置中心管理
  • 動態下發
    • 服務治理 資料中心出問題 切換消費者訪問IDC
      #20服務端出現故障時該如何應對？#
• 故障分類
  • 叢集故障
    • 限流
      • QPS
      • 工作執行緒數
    • 降級
      • 動態開關
        • 新增的業務
        • 依賴的服務或者資源
      • 一級 二級 三級 依次變大
  • 單IDC故障
    • 流量切換
      • 基於DNS解析的流量切換
      • 基於RPC分組的流量切換
  • 單機故障
    • 最頻繁
    • 自動重啟 採集 介面耗時閾值
    • 重啟比例 不超過10%
      #21 服務呼叫失敗時有哪些處理手段？#
• 呼叫失敗處理手段
  • 超時
  • 重試
  • 雙發
    • 備份請求
  • 熔斷
    • Hystrix斷路器
      • 關閉
      • 開啟
      • 半開啟
    • 滑動視窗
      #22 如何管理服務配置？#
• 如何管理
  • 本地配置
    • 把配置當作程式碼同等看待，隨著應用程式程式碼一起釋出
    • 把配置都抽離到單獨的配置檔案當中，使配置與程式碼分離
  • 配置中心
    • 儲存結構
      • Group {K V}
    • 配置註冊功能
      • 對外提供介面
    • 配置反註冊功能
      • 對外提供介面
    • 配置檢視功能
    • 配置變更訂閱功能
• 應用場景
  • 資源服務化
  • 業務動態降級
  • 分組流量切換
• 開源配置中心與選型
  • Spring cloud config
    • git
    • 手動拉取
  • DisConf
  • Apollo
    • 基於spring boot
      #23 如何搭建微服務治理平臺？#
• 基本功能
  • 與服務打交道的統一入口
  • 服務管理
    • 服務上下線
    • 節點新增/刪除
    • 服務查詢
    • 服務節點查詢
  • 服務治理
    • 限流
    • 降級
    • 切流量(IDC)
  • 服務監控
    • 整體監控
    • 某一具體服務監控
  • 問題定位
    • 服務監控發現
    • 追蹤具體某一次請求定位
  • 日誌查詢
    • ELK
  • 服務運維
    • 釋出部署
    • 擴縮容
• 如何搭建微服務治理平臺
  • Web Portal層
    • 前端展示
    • 服務管理介面
    • 服務治理介面
    • 服務監控介面
    • 服務運維介面
  • Api層
  • 資料儲存DB層
    • 使用者許可權
    • 操作記錄
    • 元資料
      #24 微服務架構該如何落地？#
• 如何落地
  • 組建合適的技術團隊
  • 從一個案例入手
  • 做好技術取捨
  • 採用DevOps
  • 統一微服務治理平臺
    #25 微服務為什麼要容器化#
• 微服務為什麼要容器化
  • 帶來的問題
  • 解決本地 測試 生產的環境隔離
  • Docker容器
    • 封裝軟體執行環境
    • 本質是linux作業系統的程序
    • Docker映象
      • 不僅打包應用程式還打包其所有依賴的環境，甚至可以包含整個作業系統
      • 解決環境不一致的問題
    • 提高測試運維的工作量
• 實踐
  • 映象分層
    #26 微服務容器化運維：映象倉庫和資源排程#
• 微服務容器化的運維
  • 面向容器的新型運維平臺 容器運維平臺
  • 組成
    • 映象倉庫
      • 儲存映象儲存與訪問
      • Docker映象倉庫地址 滿足個人或小團隊開發測試
      • 自己搭建
        • 許可權控制
          • 登陸訪問
          • 專案劃分
        • 映象同步
          • 一主多從 主從複製 樹型
          • P2P 蜻蜓
        • 高可用性
          • 部署在多個IDC
    • 資源排程
      • 如何對接各個不同的叢集，統一管理來自不同叢集的機器許可權管理、成本核算以及環境初始化等操作
      • 服務部署的叢集
        • 物理機叢集
          • 叢集-服務池-伺服器
        • 虛擬機器叢集
          • OpenStack
        • 公有云叢集
          • 快速靈活
    • 容器排程
    • 服務編排
      #27 微服務容器化運維：容器排程和服務編排#
• 容器排程
  • 排程系統
    • Docker Swarm
    • Google Kubernetes
  • 解決問題
    • 主機過濾
      • 存活過濾
      • 硬體過濾
    • 排程策略
      • 解決容器建立時選擇哪些主機最合適的問題，給主機打分
      • Swarm
        • spread,選擇資源使用最少的節點 出現故障 影響的主機少
        • binpack,選擇資源使用最多的節點 節省資源避免資源碎片化
      • 常見場景
        • 各主機的配置基本相同，並且使用也比較簡單，一臺主機上只建立一個容器。這樣的話，每次建立容器的時候，直接從還沒有建立過容器的主機當中隨機選擇一臺就可以了
        • 在某些線上、離線業務混布的場景下，為了達到主機資源使用率最高的目標，需要綜合考量容器中跑的任務的特點，比如線上業務主要使用 CPU 資源，而離線業務主要使用磁碟和 I/O資源，這兩種業務的容器大部分情況下適合混跑在一起
        • 還有一種業務場景，主機上的資源都是充足的，每個容器只要劃定了所用的資源限制，理論上跑在一起是沒有問題的，但是某些時候會出現對每個資源的搶佔，比如都是 CPU 密集型或者 I/O 密集型的業務就不適合容器混布在一臺主機上
• 容器編排
  • 服務依賴
    • Docker Compose yaml
  • 服務發現
    • 基於Nginx的服務發現
      • HTTP服務
    • 基於註冊中心的服務發現
      • RPC服務
  • 自動擴縮容
    • 根據容器的 CPU 負載情況來設定一個擴縮容的容器數量或者比例，比如可以設定容器的 CPU 使用率不超過 50%，一旦超過這個使用率就擴容一倍的機器
      #28 微服務容器化運維：微博容器運維平臺DCP#
• 整體架構
  • 基礎設施層
    • 存放容器映象的映象倉庫 核心基礎元件
    • 監控服務的監控中心
    • 容量評估系統以及容器建立後，
    • 服務發現元件
  • 主機層
    • 完成資源的排程
    • 主機建立
    • 成本管理
    • 配置初始化
  • 排程層
    • 在可用主機上建立容器
  • 編排層
    • 對服務進行整合以對外提供服務
    • 服務依賴
    • 服務發現
    • 自動擴縮容
      #29 微服務如何實現DevOps？#
• 什麼是 DevOps？
  • CI 持續整合
    • 開發完成程式碼開發後，能自動地進行程式碼檢查、單元測試、打包部署到測試環境，進行整合測試，跑自動化測試用例
  • CD 持續交付
    • 程式碼測試通過後，能自動部署到類生產環境中進行整合測試，測試通過後再進行小流量的灰度驗證，驗證通過後程式碼就達到線上釋出的要求了，就可以把程式碼自動部署到線上。
• 實踐方案
  • Jenkins
  • GitLab
    • gitlab-ci.yml
    • 持續整合
      • 程式碼檢查
      • 單元測試
      • 持續整合 Kubernetes
    • 持續交付
      • 目的 保證最新程式碼在生產環境正常執行
      • 如何從線上生產環境中摘除兩個節點
      • 如何觀察服務是否正常
    • 持續部署
      • 把在類生產環境下執行通過的程式碼自動的釋出到線上所有節點中去
        #30 如何做好微服務容量規劃#
• 複雜度
  • 服務數量眾多
  • 服務介面變現差異巨大
  • 服務部署的叢集規模大小不一
  • 服務之間存在依賴關係
• 容量規劃系統
  • 作用
    • 根據微服務部署叢集的最大容量和實際執行的負荷，來決定微服務是否擴縮容及擴縮機器數量
  • 關鍵點
    • 如何做好容量評估
      • 壓測
        • 選擇合適的壓測指標
          • 選擇系統類指標
          • 選擇服務類指標
            • 介面高於某個閾值的比例
        • 壓測獲取單機最大容量
          • 單機壓測
            • 日誌回放
            • TCP copy
          • 叢集壓測(更合理)
            • 不斷摘除線上叢集節點，增加單機的流量
            • 區間加權
        • 實時獲取叢集的執行負荷
    • 如何做好排程決策
      • 水位線
      • 擴容
        • by數量
        • by比例
      • 縮容
        • 隔時間 按比例縮
        • 採集5個點 3個點滿足 縮
          #31 微服務多機房部署實踐#
• 多機房負載均衡
  • 就近原則
  • 按需分配流量
• 多機房資料同步
  • 資料儲存
    • 快取層
    • 資料庫層
  • 主從機房架構
  • 獨立機房架構
    • WMB訊息同步元件
      • reship
        • 負責把本機的寫請求分發給一部分其他機房
      • collector
        • 負責從別的機房讀取寫請求，然後把請求給本機房的處理機
      • MCQ訊息佇列
      • RPC呼叫
• 多機房資料一致性
  • 訊息對賬機制
    • 唯一 requestId
      #32 微服務混合雲部署實踐#
• 跨雲服務如何實現負載均衡？
  • SLB和Nginx
• 跨雲服務如何實現資料同步？
  • 私有云與公有云直接的網路隔離
    • VPN網路或者專線
  • 資料庫能否上雲
    • 資料的隱私性
• 跨雲服務如何實現容器運維？
  • 跨雲的主機管理
    • DCP中採取主機 - 服務池 - 叢集”模式
  • 跨雲服務實現
  • 跨雲彈性擴容
    • DNS層
    • Nginx層
  • 跨雲服務編排
    • 依賴
      #33 下一代微服務架構Service Mesh#
• 服務網格
• Service Mesh
  • 是一種新型的用於處理服務與服務之間通訊的技術
  • 以輕量級的網路代理的方式與應用的程式碼部署在一起
• 原因
  • 跨語言呼叫的需要
  • 微服務容器化，雲原生應用服務治理的需要
• 兩個實現點
  • 輕量級的網路代理叫 SideCar，轉發服務之間的呼叫
  • 基於 SideCar 的服務治理也被叫作Control Plane，向 SideCar 傳送各種指令，以完成各種服務治理功能
• 實現原理
• SideCar
  - 服務消費者A–>Side CarA(正向代理)—>Side CarB(反向代理)—>服務提供者B
  • 關鍵點
    • 服務消費者發出的請求如何通過正向代理轉發以及服務提供者收到的請求如何通過反向代理轉發
  • 實現
    • 基於 iptables 的網路攔截
    • 採用協議轉換的方式
• Control Plane
  • 服務發現
  • 負載均衡
  • 請求路由
  • 故障處理
  • 安全認證
  • 監控上報
    #34 Istio：Service Mesh的代表產品#
• 整體架構
  • Proxy
    • 應用間的呼叫通過proxy轉發
    • 採用Envoy
    • 特徵
      • 效能損耗低
      • 可擴充套件性高
      • 動態可配置
  • Control Plane
    • 與proxy通訊
    • 基本元件
      • Pilot
        • 流量控制
        • Rules API
        • Envoy api
        • 抽象模型層
        • 平臺適配層
        • 如何實現流量控制
          • 服務發現與負載均衡
          • 請求路由
          • 超市重試
          • 故障注入
      • Mixer
        • 策略控制yaml
          • 服務呼叫進行速率限制
          • 服務呼叫進行訪問控制
        • 日誌收集
        • 兩級快取結構
          • Proxy 端的本地快取
          • Mixer 的本地快取
      • Citadel
        • 保證服務之間訪問的安全
          • Citadel 裡儲存了金鑰和證書
          • 通過 Pilot 把授權策略和安全命名資訊分發給 Proxy
          • Proxy 與 Proxy 之間的呼叫使用雙向 TLS 認證來保證服務呼叫的安全
          • 由 Mixer 來管理授權和審計
            #35 微博Service Mesh實踐之路(上)#
• 問題
  • 中間鏈路損耗大
  • 全鏈路擴容難
  • 混合雲部署難
• Yar協議
  #36 微博Service Mesh實踐之路(下)#
• Weibo Mesh技術細節
  • Motan-go Agent
    • SideCar
    • Filter Chain
    • High Available
    • Load Banlance
      • 負載均衡 整合Random演算法
    • EndPoint
      • 封裝請求
    • Serialize
      • 序列化模式
    • Server模組
      • 實現不同型別Server
  • 統一服務治理中心
    • 服務註冊與發現
    • 監控上報
    • 動態流量切換與降級
    • 自動擴縮容
  • 收益
    • 跨語言服務呼叫
    • 統一服務治理能力
    • 業務無感知的持續功能更新能力