重溫了一遍周志明老師的《鳳凰架構》，一方面是加深記憶一下里面的知識點，另外就是做個記錄總結，方便后面忘記了在看。

           全書一共有十六個章節，每個章節都相對獨立又和后文有些關系。個人總結主要是圍繞著微服務、架構演進以及容器編排等技術的發展來講述的。很詳細也很透徹，第一遍讀的時候因為很多概念不是很清楚，比較耗時。讀了后再回過頭來看時候，發現順利了不少。

         第一章服務架構演進，從原始分布式時代到單體架構歷史，SOA時代以及微服務時代，以及當前的云生無服務時代這些概念。主要是需要清楚里面的幾個概念：

         SOA:最早在1994年提出，當時不具備發展提交。直到2006年OSOA聯盟的倡議與支持下，成立了Open CSA 組織。里面提出了很多的概念、思想都在今天的微服務中找到對應的身影，譬如服務之前的松散耦合、注冊、發現、治理、隔離、編排等。

       微服務時代：微服務最早2005年提出，指的是專注于單一職責的、和語音無關的細粒度web服務。但是一直到2014年，和SOA劃清界限之后，才真正的崛起了。 現代的概念是：微服務是一種通過多個小型服務組合來構建單個應用的架構風格，這些服務圍繞業務能力而非特定的技術標準來構建，各個服務可以采用不同的編程語言、不同的數據存儲技術，運行在不同的進程之后。

      后微服務時代：主要是以docker為代表的容器化技術的崛起，以及kubernetes成為容器編排解決的首要選擇，標志著后微服務時代的開啟。以kuberneters在集群中對外提供服務，以虛擬化容器技術對外提供方案的容器編排技術的完善和發展，以及服務網格（Service mesh）等技術的引入，微服務的概念也逐漸越加成熟。

    無服務時代：主要是以云原生為主的元計算方面。也是作者預測以后云計算使用的一種主要的形式。

     另外需要說下Sidecar Proxy的邊車代理模式，這個是服務網格（Service mesh）里面用到的一種模式，下面很多章節都有介紹。

     Sidecar Proxy(邊車代理):在虛擬化場景中，邊車指的是通信代理服務器，以類似網絡安全里面中間人共計的方式進行流量劫持，在應用毫無感知的情況下，悄然接管應用所有對外通信。這個代理除了實現正常的服務間通信為（稱為數據平面通信），還接收來自控制器的指令（稱為控制平面通信），實現熔斷、認證、度量、監控以及負載均衡等各種附加功能。 我理解就是不需要像傳統方式那樣，比如說一個java語音的程序，但是需要再Python或者go平臺運行，傳統方式需要一個jar包或者http之類的方式去調用后運行，但是這個功能交由系統級別來實現了。

 

      第二章主要是介紹了遠程服務調用（RPC）以及REST風格的設計。這個章節介紹了RPC的歷史，概念有很多，畢竟RPC的歷史也有幾十年了。這個我理解需要了解的主要是知道現在一些主流的RPC吧，比如RMI(SUN/Oracle)、gRPC(Google)、Motan1/2（新浪）、Finagle(Twitter)、brpc(百度/Apache)、NetRemoting(微軟)、Arvo(Hadoop)、JSON-RPC2.0）（JSON-RPC）等一些常見的協議和框架。

     RESTFUL概念：restful和RPC的概念不盡相同，只是有些相似。本質上不是一類東西。 RPC是一種遠程服務調用協議，而restful沒有協議。雖然都是遠程調用，REST是面向資源的思想，REST只是一種風格，不是一種規范，沒有像RPC一樣的協議

    以作者舉例來說明： 

    去醫院預約

   　如果只是通過RPC調用，屬于0級
 　　如果定義了資源，比如能獲取指定日期的預約結果，即拿到所有醫生的信息 是一級
　　如果除了預約，還能取消、更換時間、以及結果能夠根據統一code碼進行判斷的，并且考慮授權之類的，比如vip才能預約的，則稱為二級
　　如果請求了一個，能返回所有的，則稱為三級

   restful 按照服務接口 rest的程序 從高到低，分為3級：

  0級： 完全不REST

  1級： 引入資源的概念

  2級：統一引入接口，映射到http協議的方法上

 3級： 超媒體控制，主要體現在返回信息里面包含所有的需要的信息，能做到服務端和客戶端的api解耦。

   另外就是restful的不足： rest和http 完全綁定，不適合高性能傳輸的常見、不利于事務、缺乏對資源批量處理等

 

  第三章 主要是事務處理，這個章節是一些互聯網公司經常面試的東西。

  ACID(原子性、隔離性、持久性、一致性):事務的基本概念

   原子性和持久性：默認是通過commit log來保證，但是commit log 有一個先天缺陷： 對數據的修改都必須發生在事務提交后，如果磁盤i/o足夠空間，都不允許事務提交前修改磁盤數據，導致對提升數據庫性能不利。 一種解決方案是： 增加Undo log的日志類型，記錄修改數據位置以及修改的值，以便在事務回滾或者崩潰crash恢復時候根據undo log 對寫入數據進行擦除。還有就是是 steal 和 force的一些概念

  隔離性：通過數據庫的讀鎖、寫鎖、范圍鎖 來解決，針對隔離級別里面序列化、可重復讀、讀已提交和讀未提交。另外在可重復讀和讀已提交 還有MVCC機制來進行優化的場景，通過增加版本號的概念來進行。

   全局事務： 為了解決分布式事務一致性問題，引入XA的處理事務架構。引入了全局的事務管理器，俗稱2階段提交和3階段提交。

   分布式事務：當前業界主流的。首先是CAP理論：即在分區容忍性下面，一致性（Consistency）和  可用性（Availability）只能保證一個。 針對分布式事務，有幾種常用的方案：

    隊列：通過隊列的方式，達到最終一致性

  TCC: tyr-confirm-console，一般用的比較多的場景就是解決秒殺保證庫位不會出現小于0的問題，超售的問題。缺點是 代碼侵入強

  SAGA事務：可以參考阿里開源的seata

 

 第四章主要是緩存、域名解析、路由以及CDN分發、負載均衡的一些知識

   主要是記一下CDN以及負載均衡的一些知識： 

   CDN 作用： 加速靜態資源分發、安全防御、 協議升級（使用SSL證書）、狀態緩存、修改資源、訪問控制、諸如功能

  負載均衡可以在數據鏈路做負載均衡、也可以在網絡層和應用層做負載均衡，負載均衡算法可以使用加權、輪訓、隨機、一致性hash、最少連接數等方式

  緩存的一些知識點：

   吞吐量：使用OPS（每秒操作數）來衡量，反應了對緩存進行并發度、寫操作的效率。

  命中率： 成功從緩存返回結果次數與總請求次數的比值。

   介紹了 Caffeine環形緩存（Ring buffer）的實現原理：以及緩存的淘汰策略：FIFO(優先淘汰)、LRU(優先淘汰最久未被訪問的數據)、LFU(優先淘汰最不經常使用的數據)。另外就是介紹了一下緩存的一些風險以及應對方式：

   緩存穿透： 查詢的數據在緩存以及數據庫都不存在。導致每次查詢都取庫表查詢，如果流量過大，就起不到緩存DB壓力的作用了。解決方案有兩種：如果是業務邏輯本身不能避免的，可以約定再一定時間內對返回為空的key值就行緩存，也就是把該key值放入緩存，只是值為空；如果是惡意的共計導致緩存穿透，可以設置一個布隆過濾器：在查詢緩存之前，先去布隆過濾器判斷下，如果沒有，緩存都不需要查詢。

  緩存擊穿：查詢的數據過期或者其他原因失效了，此時又有多個請求過來，導致每次查詢都取庫表查詢，這種被稱為緩存擊穿。解決方案一種是加鎖同步，另一種是如果是熱點數據，可以通過程序手動完成更新操作，比如定時、查詢后再次寫入緩存

  緩存雪崩：緩存擊穿是針對單個熱點失效，而緩存雪崩則是針對大量的熱點緩存數據失效。解決方案包括但不陷入：使用分布式緩存、緩存時間由固定周期改為隨機時間等

  緩存污染：只要是指緩存中的數據和真實數據源中的數據不一致的現象。解決方案一般是寫數據時候，先更新庫表，在更細緩存，讀數據時候，先讀緩存，沒有在讀庫表。

 

第五章主要是安全方面的，包括認證、授權、憑證、保密、傳輸這些。之前搞過shiro相關的，這部分沒有細看。跳過

第六章是分布式相關的，包括分布式共識

 Paxos算法- 主要是基于選主算法，包括常用的zk的選主機制。主要思想就是當主節點掛掉后，從節點進行自動選主，最終超過一般就算選主成功。

 Multi Paxos: 對Paxos算法的改進，主要是選主的改進。Raft、ZAB算法都類似，是Multi Paxos的等價派生

第七章主要是類庫到服務，圍繞服務發現、網關路由以及負載均衡來展開敘述。

       服務調用由全限定名、端口號、服務標識構成，由DNS負責解析全限定名到具體的ip地址，由負載均衡器負責到具體的路由。比較成熟的比如spring cloud的 eureka、HashiCorp的Consul以及阿里巴巴的nacos等。

    其中eureka是優先保證服務的高可用性，底層通過ribbon和Hystrix模塊來實現。 Consul 是優先保證可靠性，采用Raft算法來實現。nacos是采用自研的Distro協議實現的AP優先保證高可用，同時也支持高可靠，根據配置。

    網關在分布式環境主要是做路由器以及過濾器的，比如springcloud的zuul 2.0 ，網關是所有服務對外的總出口，所以網關也影響全局的性能。網關的性能與它的工作模式和自身實現算法都有關系，而工作模式是最關鍵的。常用的代理模式有DSR三角傳輸模式（請求經過負載均衡器，服務相應無需從負載均衡器原路返回，整個請求、轉發、相應的鏈路形成一個三角關系）、代理模式。默認的都是代碼模式，因為服務網關默認支持七層路由，默認無法直接進行流量轉發。而代理模式的性能則主要取決于如何代理網絡請求，也就是網絡的I/O模型。

  網絡IO模型劃分為 兩類、五中模型。兩類：同步I/O，異步I/O，五種是指同步IO中又劃分為 阻塞IO、非阻塞IO、多路復用IO、信號驅動IO以及異步IO模型。

  阻塞IO: 優點節省CPU資源，缺點是線程休眠所帶來的上下文切換，需要切換到內核態的重負載操作.

  非阻塞IO:非阻塞IO能避免線程休眠，可以節省上下文切換的消耗、，但是對于較長時間返回的請求，白白浪費了CPU資源

 多路復用IO:本質上是阻塞IO一種，但是好處是可以在同一條阻塞線程上處理多個不同端口號的監聽。多路復用是目前高并發網路的主流，還提供了selcet/epoll/kqueue等不同實現。(區別：select有最大文件描述符的限制1024，epoll優化了select和poll的性能瓶頸使用事件驅動模式，kqueue是BSD系統提供的多路復用)

負載均衡包括客戶端負載均衡、集中式負載均衡（服務端負載均衡）、代理負載均衡

集中式負載均衡：部署在服務器前端，負載用戶 請求分流到各個服務處理，在微服務里面 又稱為 服務端負載均衡

客戶端負載均衡：微服務中和服務實例一一對應的，具體實現比如spring cloud 的 LoadBalancer 和 Netflix Ribbon 

代理負載均衡：微服務時代 服務網格提出后一種新型的的負載均衡。

  

 

第八章 服務治理 ，主要是對服務容錯和流量控制的介紹 

   服務容錯策略： 斷路器模式、艙壁隔離模式、重試模式

  斷路器模式：通過代理接管服務調用的請求，通過監控并統計服務返回的超時、失敗、拒絕、成功等結果，出現故障或者達到閾值時候，狀態進行變更。達到避免雪崩的目的 

  艙壁隔離模式：為服務單獨設立線程池，或者使用信號量機制（Semaphore）的機制

重試模式：故障轉移和故障恢復策略對服務進行重試，當一個機器請求異常時候則請求其他的機器

流量統計，有幾個指標：

 TPS:每秒事務請求數，衡量系統吞吐量的標準

HPS:每秒請求數，每秒從客戶端向服務端請求的次數

QPS:每秒查詢數，一臺機器能相應的查詢數

限流主流的是使用HPS作為限流指標。

針對限流 有幾種常用的方案：滑動窗口、流量計數器、令牌桶和漏桶算法

滑動窗口：類似滑動窗口算法

令牌桶：每秒固定向系統添加令牌，當系統空閑時候則會達到最大值。有請求進來則從中領取一個令牌。令牌為0 則達到請求上限。

漏桶算法：一個請求元素作為對象的FIFO隊列，隊列滿時候 則拒絕請求

 

第九章關于認證、授權相關的 沒有詳細去看

 

第十章 可觀測性，主要是基于 監控相關的。

     首先是基于elk（elasticsearch/logstash/kibana）的日志收集的一些介紹，這些一般公司都有使用；之后介紹了一些鏈路追蹤的知識，比如基于traceId的鏈路追蹤，基于span的監控。一些常用的監控追蹤工具，比如zipkin/skywalking/pinpoint等，還有基于邊車代理Envoy的追蹤，這些追蹤的圖形化界面要不沒有，要不不是很好，一般是借助grafana進行展示。還有就是現在主流的prometheus監控面板，prometheus內置了一個強大的時序數據庫實現，時序數據庫提供了PromQL數據查詢語法，可以通過grafana 的模板進行展示。這個也是當前主流公司的一些選擇。

第十一章 是虛擬化容器相關的

     講了docker的歷史，以及kubernetes等概念。以及一些以應用為中心的系統。

      容器最初的摸底不是部署軟件，而是隔離計算機的各類資源，以便降低軟件開發，隔離文件 的是chroot，隔離訪問：linux的名稱空間（linux的名稱空間由內核直接提供全局資源封裝，最初只是為了隔離文件），隔離資源的cgroup（控制群組，與名稱空間一樣，直接由內核提供，用戶隔離或者分配限制某個進程組能夠使用的資源配額，包括處理器時間、內存大小、磁盤i/o速度等）。文件隔離、訪問隔離、資源隔離這些滿足了容器降生所需要的條件，剛開始linux提供的是 linx Container(后面檢測LXC)提供系統級的虛擬化功能，但是LXC是基于系統而不是基于應用的，而這也為接下來docker的產生提供了條件。

    docker以應用為中心來提供封裝，支持夸機器部署，自動構建、多版本支持，組件重用以及共享等功能，也為接下來容器編排提供了鋪墊。kubernetes是以集群為封裝，在kubernetes里面 ，資源和控制器是兩個核心設計理念。kubernetes里面認為一切皆是資源，比如pod、volumn，當這些資源狀態變化時候，需要由控制器進行追蹤，監控資源的使用。

    針對kubernetes以及docker的維護、部署和應用困難的問題，還需要一個載體去封裝整個應用。比如使用配置文件來配置配置文件，或者像linux一樣管理。場景封裝應用的方案，比如kustomizi/helm/chart/operator/CRD以及阿里開發應用模型等。

 

十二章 容器間網絡 

   主要是介紹虛擬化網絡通信、容器通信以及容器網絡相關的。

    首先是介紹了下網絡通信模型，七層模型以及四層模型，應用層、傳輸層、網絡層以及網絡訪問層。平時開發主要是在應用層開發，應用層一般也就是用戶空間，下面的幾層成為內核空間，用戶空間和內核空間通過socker進行網絡通信。在網絡協議層，linux防火墻的作者 圍繞網絡層（IP協議層）埋下了五個鉤子，使得數據包可以流到網絡層。因為應用層到下面的一些socket信息，可以拿到后，我們就可以對這些socket信息信息更改。比如更改目標的ip地址、封包、寬帶限速等等。

   虛擬網卡不需要遵照物理網絡的樣子來設計，我理解虛擬網卡只是在網絡協議層，拿到網絡協議層的socker信息后進行了更改，比如更改了host地址，這樣就能讓其指向我們想要發送的主機上面了。網絡間的通信，我理解也是類似。這部門設計一些網絡相關的知識，包括下面的VLAN模式、MACVLAN模式，不是很理解。

 十三章和十四章 是容器的存儲和資源的調用