推薦書籍

Netty進階之路

1. 分布式服務框架原理與實踐
2. 億級流量網站架構核心技術
3. 讀性能優(yōu)化
4. 阿里diamond配置設計架構
5. 緩存設計
6. 選舉機制
7. 基于對等節(jié)點提供服務
8. 一致性算法：ZAB意述、Raft跌造、Paxos
9. 了解鷹眼的系統(tǒng)架構
10. 命令行設計模式锅尘、聲明式設計模式
11. Istio官方文檔中文版本蹦疑、Service MEsh中文社區(qū)

第一章 云原生

1.1 互聯(lián)網架構變遷

1.1.1 互聯(lián)網架構核心問題

• 海量用戶

• 產品迅速迭代

• 7×24不間斷服務

• 流量突增

• 業(yè)務組合復雜

1.1.2 從集中式架構到分布式架構

1. CAP原理

2. 自動化運維

3. 解放交付的DevOps

1.1.3 從分布式架構到云原生架構

1. 新紀元的分水嶺-容器技術

• 鏡像+分發(fā)

2. 新紀元的編排與調度系統(tǒng)

• Kubernetes,Mesos,Swarm等為云原生應用提供強有力的編排與調度能力，它們是云平臺上的分布式操作系統(tǒng)

• Borg系統(tǒng)的理念

• Kubernetes面向云原生Paas平臺掘托，Mesos面向大數(shù)據(jù)+編排調度耍铜，Swarm是面向容器的

3. 架構設計的變革-微服務

配置管理错沃，服務發(fā)現(xiàn)，負載均衡钮糖，彈性擴縮松容梅掠，分布式調用追蹤，日志中心，自愈能力

1.2 什么是云原生Cloud Native

1.2.1 概述

1. 云原生應用即專門為在云平臺和運行而設計的應用

2. 云原生是一種設計模式瓤檐，它要求云原生應用具備可用性和伸縮性赂韵，以及自動化部署和管理能力，可隨處運行挠蛉，并且能夠通過持續(xù)集成祭示、持續(xù)交付工具提升研發(fā)，測試以及發(fā)布的效率

3. 云原生體系谴古，兩組詞語形容應用：無狀態(tài)质涛，有狀態(tài)

1.2.2 云原生與十二要素

1. 基準代碼Codebase

• git svn

2. 依賴 Dependencies

• 顯示聲明第三方依賴

3. 配置Config

• 將配置存儲至環(huán)境變量

4. 后端服務 Backing Services

• 將后端服務作為松耦合的資源

• 后端服務是指應用程序所依賴的通過網絡調用的遠程服務

5. 構建，發(fā)布掰担，運行

6. 進程Process

• 將應用作為無狀態(tài)的進程運行

7. 端口綁定 Port Binding

• 通過端口綁定對外發(fā)布服務

8. 并發(fā) Concurrency

• 能夠通過水平伸縮應用程序進程來實現(xiàn)并發(fā)

9. 已處理 Disposability

• 可以快速啟動和優(yōu)雅關閉應用

10. 開發(fā)環(huán)境與線上環(huán)境等價 Dev/Prod等價

• 要保持開發(fā)環(huán)境與線上環(huán)境等價

• 推薦使用Jenkins等持續(xù)集成工具來縮短生產代碼與代碼庫中的代碼不一致時間汇陆，并且采用自動化部署的方式避免操作差異

11. 日志logs

• 使用事件流處理日志

• 進程的輸出事件流由運行環(huán)境截獲，運行環(huán)境會將所有輸出事件流整合在一起带饱，然后發(fā)送給一個或者多個的最終處理程序毡代，用于查看或者長期存檔

12. 管理進程 Admin processes

• 將后臺管理任務當做一次性進程運行

1.2.3 十二要素進階

1. 優(yōu)先考慮API設計

2. 通過遙測感知系統(tǒng)狀態(tài)

3. 認證和授權

1.2.4 云原生與CNCF

1. 應用定義與開發(fā)層

• 數(shù)據(jù)庫與數(shù)據(jù)分析

• 流式處理

• 軟件配置管理

• 應用定義

• 持續(xù)集成/持續(xù)交付

2. 編排與治理層

• 調度與編排

• 分布式協(xié)調與服務發(fā)現(xiàn)

• 服務管理：遠程通信，反向代理勺疼，服務治理

3. 運行時層

• 云原生存儲

• 容器

• 云原生網絡

4. 供應保障層

• 宿主機管理工具

• 基礎設施自動化工具

• 容器倉庫

• 鏡像安全

5. 云設施層

6. 觀察分析

7. 平臺

第2章 遠程通信

2.1 通信方式

2.1.1 通信協(xié)議

1. 傳輸層協(xié)議

2. 應用層協(xié)議

• http：http2.0的多路復用教寂；https://http2.akamai.com/demo

-長連接與短連接

2.1.2 I/O模型

1. 阻塞與非阻塞

判斷阻塞I/O與非阻塞I/O時應該關注程序是否在等待調用結果

2. 同步與異步

2.1.3 java中的I/O

2.2 序列化

2.2.1 文本序列化

2.2.2 二進制java序列化

2.2.3 二進制異構語言序列化

• protobuf框架

2.3 遠程調用

2.3.1 核心概念

2.3.2 java遠程方法調用

1. 核心機制

2. 開發(fā)流程

3. 局限性

2.3.3 異構語言rpx框架gRPC

第3章 配置

3.1 本地配置

local 配置文件

3.2 配置集中化

可以參考阿里的diamond配置服務的架構設計

3.3 配置中心和注冊中心

1. zookeeper、etcd同時支持注冊中心和配置中心
2. 配置中心三個要素：快速傳播执庐、變更稀疏酪耕、環(huán)境相關

• 快速傳播：在分布式場景下，各個服務節(jié)點需要得到一致的數(shù)據(jù)轨淌，一旦發(fā)生改變要求集群中的所有節(jié)點同時感知變更迂烁。
• 變更稀疏
• 環(huán)境相關：開發(fā)環(huán)境、測試環(huán)境等

3.4 讀性能

1. 集中式緩存：每次客戶端進行訪問都可以獲取最新的數(shù)據(jù)递鹉，缺點是并未緩解配置中心的訪問壓力
2. 本地緩存：缺點是存在多分盟步，數(shù)據(jù)的一致性和更新的及時性受到一定的影響

3.5 變更實時性

1. 多副本的情況下采用兩種常見方式：監(jiān)聽、定時同步
2. 定時同步：定時job梳虽、設置緩存失效時間

3.6 可用性

1. 服務冗余：服務冗余是可用性的基本策略
2. 數(shù)據(jù)冗余可以采用基于主節(jié)點提供服務和基于對等節(jié)點提供服務兩種

• 基于對等節(jié)點提供服務：集群中的每個節(jié)點都是對等的址芯，都可以提供服務和處理請求數(shù)據(jù)。在訪問量非常大的情況下窜觉，有效分流客戶端的訪問請求
• 基于對等節(jié)點提供服務實現(xiàn)方案
  1. 緩存：冗余的是數(shù)據(jù)谷炸，不是服務；可以成為離線模式

3.7 數(shù)據(jù)一致性

第4章 服務治理

4.1 服務發(fā)現(xiàn)

4.1.1 服務發(fā)現(xiàn)概述

1. 服務發(fā)現(xiàn)模塊需要有服務注冊禀挫、服務查找旬陡、服務健康檢查以及服務變更通知等關鍵功能。
2. 服務信息注冊语婴、心跳檢查描孟、服務消費方拉取最新信息驶睦。
3. 具備高可用性的注冊中心除了具備多節(jié)點部署的能力，還需要在分布式場景下具備自我治愈和調整的能力匿醒。

4.1.2 ZooKeeper

1. zookeeper是基于CP的系統(tǒng)
2. Zab：ZooKeeper Atomic Brodcast场航，原子廣播協(xié)議
3. Paxos算法：基于消息傳遞的高度容錯的一致性算法
4. Zab協(xié)議規(guī)定，消息傳遞需要遵循可靠遞交廉羔、完全有序和因果有序這三條規(guī)則
5. 集群角色：leader溉痢、follower、observer
6. 會話：TCP長鏈接
7. znode節(jié)點：持久節(jié)點憋他、臨時節(jié)點
8. znode節(jié)點：支持順序屬性

4.1.3 Eureka

4.2 負載均衡

4.2.1 服務端負載均衡

1. 四層負載均衡：基于ip孩饼、port的負載均衡
2. 七層負載均衡：能夠充分理解應用層協(xié)議的意義，使轉發(fā)更靈活

4.2.2 客戶端負載均衡

1. Ribbon

4.3 限流

4.3.1 限流算法

1. 計數(shù)器限流：主要用于限制服務器端資源而并非客戶端請求
2. 漏桶算法：主要用于控制其他系統(tǒng)的回調洪峰
3. 令牌桶算法：

4.3.2 限流實現(xiàn)方案

1. 客戶端限流:Guava中有實現(xiàn)方案
2. 服務端限流：Spring Cloud Zuul
3. 接入端限流：

4.3.3 限流維度和粒度

4.4 熔斷

4.4.1 概述

4.4.2 熔斷器模式

4.4.3 Hystrix

第5章 觀察分布式服務

5.1 層次劃分

1. 基礎設施層竹挡、工具層镀娶、應用環(huán)境層

5.2 核心概念

1. 日志、指標揪罕、追蹤

5.3 分布式追蹤

5.3.1 概述

5.3.2 常見解決方案

1. Apache Zipkin
2. OpenTracing

5.4 應用性能管理與可觀察性平臺

1. 分布式追蹤
2. 非侵入式的語言探針
3. 輕量化
4. 低延遲分析

5.5 Apache SkyWalking

5.5.1 項目定位

5.5.2 SkyWalking 5 核心架構

1. 探針層
2. 分析層
3. 可視化層

5.5.3 SkyWalking 5 公開案例

5.5.4 SkyWalking 6 可觀察性分析平臺

第6章 侵入式服務治理方案

6.1 Dubbo

6.1.1 Dubbo 概述

6.1.2 核心流程

image.png

6.1.3 注冊中心

image.png

6.1.4 負載均衡

6.1.5 遠程通信

6.1.6 限流

6.1.7 治理中心

1. dubbo-admin

6.1.8 監(jiān)控中心

1. dubbo-admin

6.1.9 DubboX的擴展

6.2 Spring Cloud

6.2.1 概述

6.2.2 開發(fā)腳手架Spring Boot

6.2.3 服務發(fā)現(xiàn)

6.2.4 負載均衡

6.2.5 熔斷

6.2.6 遠程通信

第7章 云原生生態(tài)的基石Kubernetes

7.1 Kubernetes

1. Kubernetes架構圖

   
   
   1.
2. etcd:協(xié)同存儲梯码、負責保存整個集群的狀態(tài)，通常部署奇數(shù)個節(jié)點以保證高可用
3. API：提供資源操作的唯一入口好啰，并提供認證忍些、授權、訪問控制坎怪、API注冊和發(fā)現(xiàn)等
4. controller manager：負責維護集群的狀態(tài)，執(zhí)行故障檢測廓握、自動擴展搅窿、滾動更新等操作
5. Scheduler：負責資源調度，按照預定的調度策略將pod調度到相應的機器身上隙券。
6. Kubelet：作為工作節(jié)點負責維護容器的生命周期男应，同時也負責對容器存儲接口、容器網絡接口進行管理
7. 容器運行時（Docker）：負責鏡像管理
8. Proxy：負責提供集群內部的服務發(fā)現(xiàn)和負載均衡
9. 其他組件：CoreDNS娱仔、Ingress Controller沐飘、Prometheus、DashBoard牲迫、Federation

7.2 分層設計理念以及架構模型

1. 分層架構設計

   
   
   分層架構
2. Nucleus：Kubernetes核心耐朴、負責對外提供API構建高層應用，對內提供插件式應用執(zhí)行環(huán)境
3. Application Layer：負責部署盹憎、路由筛峭，可部署的應用包括無狀態(tài)應用、有狀態(tài)應用陪每，批處理任務影晓、集群應用等镰吵，路由的類型主要有服務發(fā)現(xiàn)、DNS解析
4. Governance layer：負責自動化以及策略管理
5. 接口層：主要包括kubectl命令行工具挂签、客戶端sdk等用于客戶端操作的庫疤祭，以及集群聯(lián)邦等使用工具
6. 云原生生態(tài)系統(tǒng)：接口層之上的負責容器集群管理調度的生態(tài)系統(tǒng)
7. Kebernetes內部：包括CRI（容器運行時接口）、CNI（容器網絡接口）饵婆、CSI（容器存儲接口）勺馆、鏡像倉庫、云供應商啦辐、身份供應商

7.3 設計哲學

1. 聲明式設計模式vs命令行設計模式

7.4 Kubernetes中的原語

7.4.1 Kubernetes 中的對象

1. 對象是Kubernetes的持久化條目
2. 對象描述了以下信息：運行的容器化應用以及node位置谓传、與應用表現(xiàn)相關的策略（重啟、升級芹关、容錯等策略）
3. 常見隊形：資源對象续挟、存儲對象、策略對象侥衬、身份對象

7.4.2 對象的期望狀態(tài)與實際狀態(tài)

1. Kubernetes對象中包括兩個嵌套字段：spec（期望狀態(tài)）和status（實際狀態(tài)）

7.4.3 描述kubernetes對象

1. Pod是kubernetes中基本調度單位

7.4.4 服務發(fā)現(xiàn)與負載均衡

1. service：直接使用Service提供集群內部的負載均衡诗祸，并且借助云供應商提供的負載均衡器將集群服務暴露給外部
2. Ingress：依然使用Service提供集群內部的負載均衡，但是要自定義負載均衡器讓外部客戶端訪問集群服務
3. Custom Load Balancer：采用自定義負載均衡器替換Kube-Proxy

7.4.5 安全性與權限管理

1. 隔離類型：網絡隔離轴总、資源隔離直颅、身份隔離（kebernetes的資源隔離層次圖在P189）

7.4.6 Sidecar設計模式

1. 某些情況下，需要啟動一個旁側容器來復制非功能需求怀樟，比如攔截流量進行審計功偿，將應用程序的功能劃分為單獨的進程，這種方式被稱為Sidecar模式

7.5 應用Kubernetes

7.6 Kubernetes 與云原生態(tài)

7.6.1 下一代云計算標準

7.6.2 當前存在問題

7.6.3 未來趨勢

第8章 跨語言服務治理方案Service Mesh

8.1 Service Mesh概述

8.1.1 Service Mesh的由來

8.1.2 Service Mesh的定義

1. 服務網格是一個基礎設施層往堡，用于處理服務間通信⌒岛桑現(xiàn)在云原生應用有著復雜的服務拓撲結果，服務網格負責在這些拓撲結構中實現(xiàn)請求的可靠傳遞虑灰。在實踐中吨瞎，服務網格通常被實現(xiàn)為一組輕量級網絡代理，他們與應用部署在一起穆咐，對于應用程序是透明的

8.1.3 Service Mesh 詳解

1. 單個服務調用
2. 多個服務調用
3. 大量服務調用
4. Service Mesh服務網格定義：抽象颤诀、功能、部署对湃、透明

8.2 Service Mesh 演進歷程

8.2.1 遠古時代的案例（P201）

8.2.2 微服務時代的現(xiàn)狀（P201）

8.2.3 侵入式框架的痛點：門檻高像屋、功能不全杯矩、無法跨語言叫确、升級困難

8.2.4 解決問題的思路

8.2.5 Proxy模式的探索

8.2.6 Sidecar模式的出現(xiàn)

8.2.7 第一代Serivce Mesh

8.2.8 第二代Service Mesh

8.3 Service Mesh的市場競爭

8.3.1 Service Mesh的萌芽期

8.3.2 急轉直下的Linkerd

8.3.3 波瀾不驚的Envoy

8.3.4 背負使用的Istio

8.3.5 背水一戰(zhàn)的Buoyant

8.3.6 其他參與者

8.3.7 Service Mesh的國內發(fā)展情況

8.4 Istio

8.4.1 Istio概述

1. Istio功能：連接熙卡、控制、保護斤儿、觀測
2. Istio的設計目標

• 最大化透明度
• 增量
• 可移植性
• 策略一致性

8.4.2 架構和核心組件

1. 從邏輯上來講剧包，Istio分為數(shù)據(jù)平面和控制平面
2. 數(shù)據(jù)平面：是以Sidecar方式部署的智能代理恐锦，Istio默認的集成是Envoy。數(shù)據(jù)平面用來控制微服務之間的網絡通信以及和Mxier的通信
3. 控制平面：負責管理以及控制數(shù)據(jù)平面疆液，控制數(shù)據(jù)平面行為一铅，如代理路由流量、實施策略堕油、收集遙測數(shù)據(jù)潘飘、加密認證等〉羧保控制平面包含Pilot卜录、Mixer、Citadel三個主要組件眶明。

4. Istio的整體架構

   
   
   Istio的整體架構
5. Envoy：提供服務發(fā)現(xiàn)艰毒、負載均衡、健康檢查搜囱、熔斷丑瞧、高級路由、基于百分比的流量切換蜀肘、加密和認證绊汹、故障注入
6. Mixer：負責提供策略控制和遙測收集的組件

• check：前置條件檢查
• Qutoa：能夠在多維度上分配和釋放資源
• Report:遙測報告

7. Pilot：向Envoy sidecar發(fā)送服務發(fā)現(xiàn)信息和各種流量管理以及路由規(guī)則