MicroService From Design to Deployment 讀書分享

今天給大家帶來的是一個讀書分享，這是一本關於微服務的書，書名是《MicroService From Design to Deployment》。

作者介紹

首先介紹一下書的作者，Chris Richardson 和 Floyd Smith。Chris Richardson更爲著名一些，所以這裏重點介紹一下。

Chris Richardson，是世界著名的軟件大師。與 Martin Fowler（敏捷開發方法論，《Microservices》）、Sam Newman（《微服務設計》）、Adrian Cockcroft（科克羅夫特，前Netflix雲架構團隊的負責人，首席雲架構師；目前在AWS任VP） 等並稱爲世界十大軟件架構師。

作者的博客
https://www.nginx.com/people/chris-richardson/

翻譯
http://blog.daocloud.io/microservices-1/

經典技術著作《POJOS IN ACTION》一書的作者

“Plain Old Java Object”“簡單java對象”。POJO的內在含義是指那些沒有從任何類繼承、也沒有實現任何接口，更沒有被其它框架侵入的java對象。主要是Java的開發者被EJB的繁雜搞怕了，大家經過反思，又迴歸“純潔老式”的JavaBean，即有無參構造函數，每個字段都有getter和setter的java類。可以轉化爲PO、DTO、VO；比如POJO在傳輸過程中就是DTO。讀音：【POU JOU】

EJB (Enterprise Java Beans) 是基於分佈式事務處理的企業級應用程序的組件。Sun公司發佈的文檔中對EJB的定義是：EJB是用於開發和部署多層結構的、分佈式的、面向對象的Java應用系統的跨平臺的構件體系結構。

對標API極其複雜的EJB（專用於分佈式系統、分層系統），受到Hibernate框架（用於提供數據持久化和對象-關係映射）及Spring框架（用於封裝業務邏輯）的影響。

理解DDD。

cloudfoundry.com 最初的創始人

Cloud Foundry是業界第一個開源PaaS雲平臺，誕生於2011年。最初由VMWare開發，開源的Cloud Foundry由Cloud Foundry基金會開發並支持，基金會包括Pivotal[ˈpɪvətl]、Dell EMC、IBM、VMWare以及其它許多公司。商業版本的Cloud Foundry，如 IBM Bluemix和Pivotal Cloud Foundry（簡稱PCF），是基於開源的Cloud Foundry 項目開發的。

成書背景

• 2011年，CloudFoundry創立，成爲第一個開源PaaS雲平臺
• 2013年，docker問世
• 2013年，Cockcroft 在 Netflix 完成了一個壯舉，把所有IT基礎設施都轉移到了亞馬遜的AWS雲端。此後，獨樂樂不如衆樂樂，Netflix公開了這套轉型上雲端的經驗，甚至打包自己開發的工具和架構設計模板，開源推出了NetflixOSS平臺。做了一系列的封裝，就變成了Spring Cloud。
  《雲端教父辛酸講述：匹敵阿里雲的Netflixr如何成爲雲端巨頭的》一點號 縱酒狂歌
• 2013年，進入PaaS雲時代
• 2014年，K8S發佈
• 2015年，作者的文章以博客的形式，在Nginx官網上發佈
• 2016年，成書
• 2019年，Netflix 架構師 Ruslan Meshenberg（後被蘋果挖走） 在 Goto 大會上介紹了 Netflix 的微服務架構，一天發佈1000次。對DevOps的理解：“誰構建，誰運維”，這一理念旨在鼓勵系統開發團隊同時負責系統的運維與支持工作，從而真正將 DevOps 引入實踐。

選擇1-4章

framework的作用

當解決一個複雜而且龐大的問題的時候，往往將其分解爲一個個更小、相對簡單、易於理解的子問題，然後繼續劃分成更小的子問題，直到每個子問題都有成熟的方案備選，然後根據需要和約束選擇選擇方案。

粗略來看，微服務的framework如下：

重點是3個問題：系統外和系統內部如何通訊，系統內部微服務之間如何通訊、外界如何感知微服務以及微服務之間如何感知對方。

書的第一章是微服務的介紹，2-4章講的就是這三個問題的原理和備選方案。所以這裏選擇1-4章進行介紹。

1. 微服務介紹

單體應用

如圖所示，這是一個打車軟件的單體應用：

這張圖 是典型的六邊形架構【1】（hexagonal-architecture[hekˈsæɡənl]）， 將域模型（應用）和外部設備區分開來。分爲三層：域模型、Port和Adapter。

當外界事件到達一個端口時，某個特定技術的適配器把它轉換爲可用的過程調用或者消息傳遞給應用。應用完全不知道輸入設備的特徵。當應用有東西需要發送出去時，它會通過一個端口，發送給某個適配器，由適配器來生成接受端技術(人或自動化的)所適合的信號。應用在其所有邊界上都可以與適配器進行語義上的良性互動，而不用知道適配器另一端上東西的特徵。這樣當討論域模型的時候，不需要關心技術，只需要考慮業務邏輯；同時方便開發、測試和部署。

關於六邊形更多的細節，可以參考Ian Cooper的文章。《Exploring the Hexagonal Architecture》

簡單介紹下途中的幾個Adapter：

• twilio：撥打和接聽網絡電話（推流？讀音參考twitter）
• Sendgrid：郵件平臺
• Stripe：支付
• MySql：MariaDB兼容MySql

單體服務的問題

• 會變的複雜，很難理解
• 啓動慢
• 伸縮困難，可靠性降低
• 部署困難
• 船大掉頭難
• 不同模塊對資源的需要不同

微服務

整張圖，可以關注兩點：

1. 一個大的單體應用被拆成了多個微服務，每個微服務負責一部分相對獨立的功能。
2. 整個系統的通訊分爲兩類：服務間的通訊，術語是東西向通訊；系統外部和系統的通訊，術語是南北向通訊。

伸縮的三個維度

上圖是 Scale Cube 的 3D 模型，來自《The Art of Scalability》 一書。作者馬丁 L. 阿伯特和邁克爾 T. 費舍爾分別是 eBay 和 PayPal 的前 CTO。

微服務架構範式對應 Y 軸，X 軸由負載均衡器後端運行的多個應用副本組成，Z 軸（數據分割）將需求路由到相關服務。

在運行時，可以看應用是如何從X維度進行伸縮。旅途管理服務由多個服務實例組成，每個服務實例是一個 Docker 容器。爲了實現高可用，容器是在多個雲虛擬機上運行的。服務實例的前方是一個負載均衡器（如 NGINX），用於跨實例分發請求。負載均衡器也可以處理其他問題，如緩存、訪問控制、API 度量和監控。在這個例子裏面，該維服務是使用 Docker 部署到 AWS EC2 上的。

微服務架構範式對應用和數據庫的關係影響巨大。每個服務都有自身的數據庫計劃，而不與其它服務共享同一個數據庫。

優勢與不足

優勢

• 通過分解巨大單體應用爲多個服務方法解決了複雜性問題。
• 獨立開發
• 獨立部署
• 獨立伸縮，比如，你可以在 EC2 Compute Optimized instances 上部署 CPU 敏感的服務，而在 EC2 memory-optimized instances 上部署內存數據庫（Redis，Memcache，Berkeley DB）。

不足

• there are no silver bullets
• 固有的複雜性。包括進程間通訊機制、局部失效問題。如果是單體應用，處理模塊間的通訊是語言級的，或者可以通過事務回滾解決。
• 分佈式的數據庫架構，帶來的複雜性。

CAP：

Consistency：一致性，寫操作後的讀操作可以讀取到最新的數據狀態，當數據分佈在多個節點時，從任意節點讀取到的數據都是最新的狀態。
Availability：可用性，指任何事務操作都可以得到相應結果，且不會出現響應超時或響應錯誤。
PartitionTolerance：通常分佈式系統的各個節點部署在不同的子網，這就是網絡分區，不可避免的會出現由於網絡問題而導致節點之間通信失敗，此時仍可對外提供服務，這叫分區容忍性。

在類似微服務的分佈式系統語境中，通常情況下，P是默認的，但是需要考慮CA之間的矛盾。具體來說，如果要實現C則必須保證數據一致性，在數據同步的時候爲防止向從數據庫查詢的不一致則需要從數據庫鎖定，待完成同步之後解鎖，如果同步失敗從數據庫要返回錯誤信息或超時信息；然而，如果要實現A則必須保證數據可用性，不管任何時候都可以向從數據庫進行查詢數據，並且不能夠返回錯誤信息或者超時信息。

• CA組合
  CA組合就是保證一致性和可用性，放棄分區容忍性，即不進行分區，不考慮由於網絡不通或節點掛掉的問題。那麼系統將不是一個標準的分佈式系統，我們最常用的關係型數據庫就滿足了CA。

• CP組合
  CP組合就是保證一致性和分區容忍性，放棄可用性。Zookerper就是追求強一致性，放棄了可用性，還有跨行轉賬，一次轉賬請求要等待雙方銀行系統都完成整個事務才能完成。

• AP組合
  AP組合就是保證可用性和分區容忍性，放棄一致性。這是分佈式系統設計時的選擇。

Cassandra（阿里）、Dynamo（AWS）等，默認優先選擇AP，弱化C；HBase、MongoDB、ZooKeeper 等，默認優先選擇CP，弱化A。

BASE 理論

eBay 架構師Dan Pritchett（普里切特） 提出了BASE 理論，用於解決大規模分佈式系統下的數據一致性問題。BASE 理論告訴我們：可以通過放棄系統在每個時刻的強一致性來換取系統的可擴展性。

BASE 理論核心思想：

• 基本可用（BasicallyAvailable）：指分佈式系統在出現故障時，允許損失部分的可用性來保證核心可用。
• 軟狀態（SoftState）：指允許分佈式系統存在中間狀態，該中間狀態不會影響到系統的整體可用性。
• 最終一致性（EventualConsistency）：指分佈式系統中的所有副本數據經過一定時間後，最終能夠達到一致的狀態。

在A和C進行權衡妥協。

一致性模型

數據的一致性模型可以分成以下 3 類：

1. 強一致性：數據更新成功後，任意時刻所有副本中的數據都是一致的，一般採用同步的方式實現。
2. 弱一致性：數據更新成功後，系統不承諾立即可以讀到最新寫入的值，也不承諾具體多久之後可以讀到。
3. 最終一致性：弱一致性的一種形式，數據更新成功後，系統不承諾立即可以返回最新寫入的值，但是保證最終會返回上一次更新操作的值。

分佈式系統數據的強一致性、弱一致性和最終一致性可以通過Quorum NRW算法分析。

分佈式事務的四種解決方案

1. 兩階段提交（強一致性）
   存在一個Coordinator，第一階段是準備階段，Coordinator詢問參與者事務是否執行成功，參與者發回事務執行結果；第二階段，如果事務在每個參與者上都執行成功，事務協調者發送通知讓參與者提交事務；否則，協調者發送通知讓參與者回滾事務。需要注意的是，在準備階段，參與者執行了事務，但是還未提交。只有在提交階段接收到協調者發來的通知後，才進行提交或者回滾。
   2PC的核心原理是通過提交分階段和記日誌的方式，記錄下事務提交所處的階段狀態，在組件宕機重啓後，可通過日誌恢復事務提交的階段狀態，並在這個狀態節點重試。
   

2. 補償事務 TCC（最終一致性）
   其核心思想是：針對每個操作，都要註冊一個與其對應的確認和補償（撤銷）操作。它分爲三個階段：
   a）Try 階段主要是對業務系統做檢測及資源預留（例如，給數據加鎖）
   b）Confirm 階段主要是對業務系統做確認提交，Try階段執行成功並開始執行 Confirm階段時，默認 Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功。
   c）如果b）執行成功，則執行成功；如果失敗，進入Cancel階段。Cancel 階段主要是在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放。
   跟2PC比起來，實現以及流程相對簡單了一些，但數據的一致性比2PC也要差一些
   實現關鍵要素：服務調用鏈必須被記錄下來；每個服務提供者都需要提供一組業務邏輯相反的操作，互爲補償，同時回滾操作要保證冪等；必須按失敗原因執行不同的回滾策略。

3. 本地消息表（異步確保最終一致性）
   在分佈式事務操作的一方完成寫業務數據的操作之後向本地消息表（在同一個數據庫裏）發送一個消息，本地事務能保證這個消息一定會被寫入本地消息表中。
   之後將本地消息表中的消息轉發到 Kafka 等消息隊列中，如果轉發成功則將消息從本地消息表中刪除，否則繼續重新轉發。在分佈式事務操作的另一方從消息隊列中讀取一個消息，並執行消息中的操作。
   一種非常經典的實現，避免了分佈式事務，實現了最終一致性。eBay 的架構師Dan Pritchett，曾在一篇解釋BASE 原理的論文《Base：An Acid Alternative》中提到一個eBay 分佈式系統一致性問題的解決方案。它的核心思想是將需要分佈式處理的任務通過消息或者日誌的方式來異步執行，消息或日誌可以存到本地文件、數據庫或消息隊列，再通過業務規則進行失敗重試，它要求各服務的接口是冪等的。

4. MQ 事務消息（最終一致性）
   有一些第三方的MQ是支持事務消息的，比如RocketMQ，他們支持事務消息的方式也是類似於採用的二階段提交，但是市面上一些主流的MQ都是不支持事務消息的，比如 RabbitMQ 和 Kafka 都不支持。
   以阿里的 RocketMQ 中間件爲例，其思路大致爲：
   第一階段Prepared消息，會拿到消息的地址。 第二階段執行本地事務，第三階段通過第一階段拿到的地址去訪問消息，並修改狀態。
   也就是說在業務方法內要想消息隊列提交兩次請求，一次發送消息和一次確認消息。如果確認消息發送失敗了RocketMQ會定期掃描消息集羣中的事務消息，這時候發現了Prepared消息，它會向消息發送者確認，所以生產方需要實現一個check接口，RocketMQ會根據發送端設置的策略來決定是回滾還是繼續發送確認消息。這樣就保證了消息發送與本地事務同時成功或同時失敗。
   

5. 緩存數據最終一致性（最終一致性）
   在我們的業務系統中，緩存（Redis 或者Memcached）通常被用在數據庫前面，作爲數據讀取的緩衝，使得I/O 操作不至於直接落在數據庫上。
   要解決緩存和數據庫數據不一致的問題我們有以下兩種解決方案：
   a）爲緩存數據設置過期時間。當緩存中數據過期後，業務系統會從數據庫中獲取數據，並將新值放入緩存。這個過期時間就是系統可以達到最終一致的容忍時間。
   b）更新數據庫數據後同時清除緩存數據。數據庫數據更新後，同步刪除緩存中數據，使得下次對商品詳情的獲取直接從數據庫中獲取，並同步到緩存。

對購物轉賬等電商和金融業務，中間件層的2PC最大問題在於業務不可見，一旦出現不可抗力或意想不到的一致性破壞，如數據節點永久性宕機，業務難以根據2PC的日誌進行補償。金融場景下，數據一致性是命根，業務需要對數據有百分之百的掌控力，一般使用TCC這類分佈式事務模型，或基於消息隊列的柔性事務框架，這兩種方案都在業務層實現，業務開發者具有足夠掌控力，可以結合SOA框架來架構，包括Dubbo、Spring Cloud等。

API Gateway

定義客戶端如何和應用交互，即所謂的南北向通訊。還是以之前的應用爲例，

如果是單體應用，移動客戶端通過嚮應用程序發起一次 REST 調用（GET api.company.com/productdetails/）來獲取這些數據。負載均衡器將請求路由給 N 個相同的應用程序實例中的其中之一。然後，應用程序會查詢各種數據庫表，並將響應返回給客戶端。

如果是微服務，就需要考慮移動客戶端如何訪問這些服務。

顯然直接訪問不是好主意，每個微服務都有自己獨特的架構和訪問方式：

• 首先，這種方法還使得客戶端代碼非常複雜；
• 其次，RPC和MQ並不是瀏覽器友好、防火牆友好，防火牆之外，應該是HTTP或者WebSocket【1】；
• 最後，會使得微服務難以重構。

API Gateway的優點：

1. 簡單的接口。
2. 對客戶端可裁剪。例如：

• 對於基於HTML5/JavaScript的UI，可以通過服務器端的Web應用生成HTML
• 對於原生的Android和iPhone應用，可以通過REST API和客戶端通訊
• 對於第三方的應用，可以提供REST接口

3. 此外，API Gateway還可以提供認證、監控、計費、負載均衡，緩存，靜態響應【2】，request shaping 和管理等功能【3】。

API 網關也有一些不足。它增加了一個我們必須開發、部署和維護的高可用組件。還有一個風險是，API 網關變成了開發瓶頸。爲了暴露每個微服務的端點，開發人員必須更新 API 網關。API網關的更新過程要儘可能地簡單，這很重要；否則，爲了更新網關，開發人員將不得不排隊等待。不過，雖然有這些不足，但對於大多數現實世界的應用程序而言，使用 API 網關是合理的。

API GateWay 的相關技術

有很多種類型的API GateWay，瞭解和選擇的時候，有很多維度，考慮的東西很多，性能、可用性、可擴展性、需求的匹配度、是否開源、是否自主可控、公有云和私有云。這裏僅從性能的角度展開討論。

對於大多數應用程序而言，API 網關的性能都非常重要。因此，將 API 網關構建在一個支持異步、非阻塞 I/O 的平臺上是合理的。有多種不同的技術可以實現一個可擴展的 API 網關。在 JVM 上，可以使用一種基於 NIO 的框架，比如 Netty、RxJava（NetFlix）中的一種。一個非常流行的非 JVM 選項是 Node.js。

Nginx-plus提供了動態重配置API，通過Lua或Perl進行動態更新，或者由Chef, Puppet, ZooKeeper, 或者DNS的更新來驅動。

API GateWay 主要的解決方案

私有云

• Kong：基於Nginx+Lua進行二次開發
• NetFlix Zuul：Spring Cloud的一個推薦組件，基於Servlet。
• Orange：國人當自強

公有云

• Amazon API Gateway
• 阿里雲API網關
• 騰訊雲API網關

自開發

• 基於Nginx+Lua+OpenResty，Nginx 是俄羅斯人發明的， Lua 是巴西幾個教授發明的，中國人章亦春把 LuaJIT VM 嵌入到 Nginx 中，實現了 OpenResty 這個高性能服務端解決方案。
• 基於Netty，I/O 非阻塞
• 基於Node.js，Node.js天生非阻塞
• 基於Servlet

微服務API Gateway並不是必須的

Service Mesh（網格） 和 Dubbo

Inter-Process Communication

在單體應用程序中，組件可通過語言級方法或者函數相互調用。相比之下，基於微服務的應用程序是一個運行在多臺機器上的分佈式系統。通常，每個服務實例是一個進程。

因此，服務必須使用進程間通信（IPC）機制進行交互。
https://blog.csdn.net/g6U8W7p06dCO99fQ3/article/details/118833581

交互方式

1對多
1對1

同步，異步

處理局部故障

分佈式系統普遍存在局部失敗的問題。由於客戶端和服務端是獨立的進程，服務端可能無法及時響應客戶端請求。服務端可能會因爲故障或者維護而暫時不可用。服務端也可能會由於過載，導致對請求的響應極其緩慢。

假設推薦服務無法響應，客戶端可能會由於無限期等待響應而阻塞。這不僅會導致很差的用戶體驗，並且在很多應用中還會佔用之前的資源，比如線程；最終，如下圖所示，運行時耗盡線程資源，無法響應。

爲了預防這種問題，設計服務時候必須要考慮部分失敗的問題。

解決方案

Netfilix 提供了一個比較好的解決方案，具體的應對措施包括：

• 網絡超時：在等待響應時，不設置無限期阻塞，而是採用超時策略。使用超時策略可以確保資源不被無限期佔用。
• 限制請求的次數：可以爲客戶端對某特定服務的請求設置一個訪問上限。如果請求已達上限，就要立刻終止請求服務。備選方案包括線程池和semaphore（信號量，非阻塞）信號量代替線程，用於不進行網絡調用時的依賴項執行(例如那些只執行內存緩存查找的線程)，因爲獨立線程的開銷對於這些類型的操作來說太高了。
• 斷路器模式（Circuit Breaker Pattern）：記錄成功和失敗請求的數量。如果失效率超過一個閾值，觸發斷路器使得後續的請求立刻失敗。如果大量的請求失敗，就可能是這個服務不可用，再發請求也無意義。

下圖是一個斷路器的簡單實例，當timeout發生一定次數後，斷路器被觸發：

在一個失效期後，客戶端可以再試，如果成功，關閉此斷路器。

• 提供回滾：當一個請求失敗後可以進行回滾邏輯。例如，返回緩存數據或者一個系統默認值。Netflix Hystrix 是一個實現相關模式的開源庫。如果使用 JVM，推薦使用Hystrix。而如果使用非 JVM 環境，你可以使用類似功能的庫。

這些容錯方法各有優缺點，但是當它們結合在一起時，在用戶請求和底層依賴項之間提供了一個全面的保護屏障。

當發生故障時，我們如何響應用戶請求

• 緩存:如果實時依賴項不可用，則從本地或遠程緩存檢索數據，即使數據最終已過期
• 最終一致性:隊列寫入(如在SQS中)，在依賴項再次可用時繼續
• 存根數據:當無法檢索個性化選項時，恢復到默認值
• 空響應(“Fail Silent”)：返回null或空列表，ui可以忽略他們

以上內容來自：
1.《Fault Tolerance in a High Volume, Distributed System》Fault Tolerance in a High Volume, Distributed System
2.《博文精譯-高容量分佈式系統的容錯》drjava_2019 csdn

主要技術

異步消息

由於異步通信，客戶端不會因爲等待而阻塞，相反會認爲響應不會被立即收到。解耦，異步、削峯（秒殺或者團購時，對數據庫的請求數有限制），

通過向發佈/訂閱渠道寫入一條創建行程的消息，行程管理服務會通知調度服務有新的行程請求。調度服務發現可用的司機後會向發佈/訂閱渠道寫入一條推薦司機的消息，並通知其它服務。

其實我們在雙11的時候，當我們凌晨大量的秒殺和搶購商品，然後去結算的時候，就會發現，界面會提醒我們，讓我們稍等，以及一些友好的圖片文字提醒。而不是像前幾年的時代，動不動就頁面卡死，報錯等來呈現給用戶。

協議

AMQP，即Advanced Message Queuing Protocol，高級消息隊列協議，是應用層協議的一個開放標準，爲面向消息的中間件設計。消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。 AMQP的主要特徵是面向消息、隊列、路由（包括點對點和發佈/訂閱）、可靠性、安全。

其中較爲成熟的MQ產品有IBM WebSphere MQ、RabbitMQ 、ZeroMQ 、ActiveMQ（基於JMS的一個開源實現，JMS 是一個接口標準或者說是一個API消息服務的規範即JAVA Message Service，java消息服務）、Redis（當做一個輕量級的隊列服務來使用）、Kafka（只支持主要的MQ功能，像一些消息查詢，消息回溯等功能沒有提供，畢竟是爲大數據準備的，在大數據領域應用廣，能處理的數據量大）、RocketMQ（是阿里出品，如果阿里放棄維護rocketmq，中小型公司一般抽不出人來進行rocketmq的定製化開發，因此不推薦）。

其他基於TCP/IP自定義的協議 有些特殊框架（如：redis、kafka、zeroMq等）根據自身需要未嚴格遵循MQ規範，而是基於TCP\IP自行封裝了一套協議，通過網絡socket接口進行傳輸，實現了MQ的功能。

RabbitMQ

基於erlang開發，所以併發能力很強，性能極其好，延時很低;管理界面較豐富；支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。主從架構。在很多公司得到應用；有較多的文檔；各種協議支持較好；中小型企業首選。

• RabbitMQ 實現RPC的機制是（可靠性）：

  
  

如圖所示，從AMQP協議層面上來說，消息從生產者到消費者的過程分爲四個階段：

1. 消息先從生產者Producer出發到達交換器Exchange（以RouteKey的形式）；
2. 交換器Exchange根據路由規則（RouteKey）將消息轉發對應的隊列Queue之上。交換器有三種模式：直連，廣播和主題（支持“#”和“*”的通配符）；
3. 消息在隊列Queue上進行存儲；
4. 消費者Consumer訂閱隊列Queue並進行消費。

從可靠性來說，沒個階段都有每個階段的策略：

• 消息先從生產者Producer出發到達交換器Exchange
  兩種模式：
  a. TRANSACTION模式：阻塞，性能低，嚴重浪費服務器資源。
  b. CONFIRM模式：異步確認。類似TCP的處理，接收方返回一個Ack報文，裏面攜帶seq號碼，通知發送方報文已經收到。可以設置multiple參數，表示到這個序號之前的所有消息都已經得到了處理。這個就是“重複請求”（ARQ，Automatic Repeat Request），構成了很多通訊協議的基礎，例如TCP。

• 交換器Exchange根據路由規則將消息轉發對應的隊列Queue之上
  三種模式：
  a. 丟棄
  b. 添加ReturnListener監聽器：生產者客戶端通過ReturnListener監聽到了這個事件，採取相應的行動，重新投遞或者其它方案。
  c. 備胎交換器：這樣可以將未被路由的消息存儲在RabbitMQ中，再在需要的時候去處理這些消息。
  

• 消息在隊列Queue上進行存儲
  兩種模式：
  a. 持久化
  b. 高可用

• 消費者Consumer訂閱隊列Queue並進行消費
  兩種模式：
  a. 丟棄
  b. 消息確認機制（message acknowledgement）：消費者在訂閱隊列時，RabbitMQ會等待消費者顯式地回覆確認信號後才從內存（或者磁盤）中移去消息。

以上內容來自
《RABBITMQ 消息可靠性投遞（實際項目改造）》 CSDN 朱小廝

• 消息重複

兩種可能性：

1. 消息消費成功，事務已經提交，ack時，機器宕機，導致消息沒有確認，又需要重新發送；
2. 消息消費失敗，由於重試機制，自動又將消息發送出去。

解決辦法：

1. 消費者的業務消費接口應該設計爲冪等性；
2. 發送的每一個消息都有業務的唯一標識，處理過就不用處理，例如雪花算法。

• 消息堆積

消費者將消息批量取出，離線慢慢處理，最終一致性的解決方案。

Apache Kafka

使用Zookeeper。

Scala開發，分佈式架構，可用性非常高。只支持主要的MQ功能，像一些消息查詢，消息回溯等功能沒有提供，畢竟是爲大數據準備的，在大數據領域應用廣。

大型軟件公司，具備足夠的資金搭建分佈式環境，也具備足夠大的數據量，會選擇kafka，根據業務場景選擇，如果有日誌採集功能，肯定是首選kafka了。

• 高可用性

  
  

一個典型的Kafka體系架構包括若干Producer（可以是服務器日誌，業務數據，頁面前端產生的page view等等），若干broker（Kafka支持水平擴展，一般broker數量越多，集羣吞吐率越高），若干Consumer (Group)，以及一個Zookeeper集羣。Kafka通過Zookeeper管理集羣配置，選舉leader，以及在consumer group發生變化時進行rebalance。Producer使用push(推)模式將消息發佈到broker，Consumer使用pull(拉)模式從broker訂閱並消費消息。

https://www.cnblogs.com/qingyunzong/p/9004509.html
https://zhuanlan.zhihu.com/p/56440807

同步的請求/響應 IPC

當使用基於同步、基於請求/響應的 IPC 機制時，客戶端向服務器發送請求，該服務處理該請求並返回響應，與使用消息傳遞不同，客戶端假定響應能及時到達。有許多協議可供選擇。有兩種流行協議分別是 REST 和 Thrift。

REST

REST這個詞，是Roy Fielding在他2000年的博士論文中提出的。Fielding是HTTP協議（1.0版和1.1版）的主要設計者、Apache服務器軟件的作者之一、Apache基金會的第一任主席。

REST，即Representational [ˌreprɪzenˈteɪʃənl] State Transfer的縮寫，可以翻譯爲"表現層狀態轉化"。如果一個架構符合REST原則，就稱它爲RESTful架構。這裏，省略了一個主語：Resource。"表現層"其實指的是"資源"（Resources）的"表現層"。

• 資源：就是網絡上的一個實體，或者說是網絡上的一個具體信息。它可以是應用程序對象、數據庫記錄、算法，總之就是一個具體的實在。你可以用一個URI（統一資源定位符）指向它，每種資源對應一個特定的URI。要獲取這個資源，訪問它的URI就可以，因此URI就成了每一個資源的地址或獨一無二的識別符。
• 表現層："資源"是一種信息實體，它可以有多種外在表現形式。我們把"資源"具體呈現出來的形式，叫做它的"表現層"（Representation）。比如，文本可以用txt格式表現，也可以用HTML格式、XML格式、JSON格式表現，甚至可以採用二進制格式；圖片可以用JPG格式表現，也可以用PNG格式表現。
• 狀態轉化（State Transfer）。訪問一個網站，就代表了客戶端和服務器的一個互動過程。在這個過程中，勢必涉及到數據和狀態的變化。互聯網通信協議HTTP協議，是一個無狀態協議。這意味着，所有的狀態都保存在服務器端。因此，如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發生"狀態轉化"（State Transfer）。而這種轉化是建立在表現層之上的，所以就是"表現層狀態轉化"。客戶端用到的手段，只能是HTTP協議。具體來說，就是HTTP協議裏面，四個表示操作方式的動詞：GET、POST、PUT、DELETE。它們分別對應四種基本操作：GET用來獲取資源，POST用來新建資源（也可以用於更新資源），PUT用來更新資源，DELETE用來刪除資源。

REST 指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程序或設計就是 RESTful。

Web 應用程序最重要的 REST 原則是，客戶端和服務器之間的交互在請求之間是無狀態的。從客戶端到服務器的每個請求都必須包含理解請求所必需的信息。如果服務器在請求之間的任何時間點重啓，客戶端不會得到通知。此外，無狀態請求可以由任何可用服務器回答，這十分適合雲計算之類的環境。客戶端可以緩存數據以改進性能。

乘客的智能手機通過向 Trip Management 服務的 /trips 資源發出一個 POST 請求來請求旅程。該服務通過向 Passenger Management 服務發送一個獲取乘客信息的 GET 請求來處理該請求。在驗證乘客被授權創建旅程後，Trip Management 服務將創建旅程，並向智能手機返回 201 響應。

RPC

RPC（Remote Procedure Call），即遠程過程調用，它是一種通過網絡從遠程計算機程序上請求服務而不需要了解底層網絡技術的思想。

三種比較流行的框架：

• gRPC：是 Google 公佈的開源軟件，基於 HTTP 2.0 協議，並支持常見的衆多編程語言。底層使用到了 Netty 框架的支持（基於事件驅動）。
• Thrift：是 Facebook 的開源 RPC 框架，主要是一個跨語言的服務開發框架。
  用戶只要在其之上進行二次開發就行，應用對於底層的 RPC 通訊等都是透明的。不過這個對於用戶來說需要學習特定領域語言這個特性，還是有一定成本的。
• Dubbo：是阿里集團開源的一個極爲出名的 RPC 框架，在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是極其鮮明的特色。

服務發現

爲什麼要使用服務發現?

服務實例的網絡位置都是動態分配的。由於擴展、失敗和升級，服務實例會經常動態改變，因此，客戶端代碼需要使用較爲複雜的服務發現機制。

發現模式

服務發現有兩大模式：客戶端發現模式和服務端發現模式。

客戶端發現模式

使用客戶端發現模式時，客戶端決定相應服務實例的網絡位置，並且對請求實現負載均衡。客戶端查詢服務註冊表，後者是一個可用服務實例的數據庫；然後使用負載均衡算法從中選擇一個實例，併發出請求。

下圖顯示了這種模式的架構：

Netflix OSS 是客戶端發現模式的絕佳範例。Netflix Eureka 是一個服務註冊表，爲服務實例註冊管理和查詢可用實例提供了 REST API 接口。Netflix Ribbon 是 IPC 客戶端，與 Eureka 一起實現對請求的負載均衡。

國內阿里開源的Dubbo也是採用這種模式。

客戶端發現模式優缺點兼有。這一模式相對直接，除了服務註冊外，其它部分無需變動。此外，由於客戶端知曉可用的服務實例，能針對特定應用實現智能負載均衡，比如使用哈希一致性。這種模式的一大缺點就是客戶端與服務註冊綁定，要針對服務端用到的每個編程語言和框架，實現客戶端的服務發現邏輯。

服務端發現模式

另外一種服務發現的模式是服務端發現模式，下圖展現了這種模式的架構：

這是最簡單和傳統的負載均衡做法，在服務消費者和生產者之間，代理作爲獨立一層集中部署，由獨立團隊(一般是運維或框架)負責治理和運維。常用的集中式代理有硬件負載均衡器(如F5)，或者軟件負載均衡器(如Nginx)，F5(4層負載)+Nginx(7層負載)這種軟硬結合兩層代理也是業內常見做法，兼顧配置的靈活性(Nginx比F5易於配置)。

國外知名電商網站eBay，雖然體量巨大，但其內部的服務發現機制仍然是基於這種傳統的集中代理模式，國內公司如攜程，也是採用這種模式。

內容來自：《微服務之-ServiceMesh》HelloWide 簡書

客戶端通過負載均衡器向某個服務提出請求，負載均衡器查詢服務註冊表，並將請求轉發到可用的服務實例。如同客戶端發現，服務實例在服務註冊表中註冊或註銷。

主要實現方式：

• AWS Elastic Load Balancer（ELB）是服務端發現路由的例子，ELB 通常均衡來自互聯網的外部流量，也可用來負載均衡 VPC（Virtual private cloud）的內部流量。客戶端使用 DNS 通過 ELB 發出請求（HTTP 或 TCP），ELB 在已註冊的 EC2 實例或 ECS（Amazon Elastic Container Service）容器之間負載均衡。這裏並沒有單獨的服務註冊表，相反，EC2 實例和 ECS 容器註冊在 ELB。
• Nginx+Consul：HTTP 服務器與類似 NGINX PLUS 和 NGINX 這樣的負載均衡起也能用作服務端的發現均衡器。例如使用 Consul Template 來動態配置 NGINX 反向代理。Consul Template 定期從 Consul Template 註冊表中的配置數據中生成 nginx.conf 文件，用於配置反向代理，然後運行命令，告訴 NGINX 重新加載配置文件。
• Kubernetes 這樣的部署環境會在每個集羣上運行一個代理（kube-proxy），將代理用作服務端發現的負載均衡器。客戶端使用主機 IP 地址和分配的端口通過代理將請求路由出去，向服務發送請求。代理將請求透明地轉發到集羣中可用的服務實例。

服務註冊表

服務註冊表是服務發現的核心部分，是包含服務實例的網絡地址的數據庫。服務註冊表需要高可用而且隨時更新。客戶端能夠緩存從服務註冊表中獲取的網絡地址，然而，這些信息最終會過時，客戶端也就無法發現服務實例。因此，服務註冊表會包含若干服務端，使用複製協議保持一致性。

主要實現：

• Netflix Eureka：爲註冊和請求服務實例提供了 REST API。服務實例使用 POST 請求來註冊網絡地址，每三十秒使用 PUT 請求來刷新註冊信息。註冊信息也能通過 HTTP DELETE 請求或者實例超時來被移除。以此類推，客戶端能夠使用 HTTP GET 請求來檢索已註冊的服務實例。
  Netflix 通過在每個 AWS EC2 域運行一個或者多個 Eureka 服務實現高可用性。每個 Eureka 服務器都運行在擁有彈性 IP 地址的 EC2 實例上。DNS TEXT 記錄被用來保存 Eureka 集羣配置，後者包括可用域和 Eureka 服務器的網絡地址列表。Eureka 服務在啓動時會查詢 DNS 去獲取 Eureka 集羣配置，確定同伴位置，以及給自己分配一個未被使用的彈性 IP 地址。
  Eureka 客戶端，包括服務和服務客戶端，查詢 DNS 去發現 Eureka 服務的網絡地址。客戶端首選同一AZ內的 Eureka 服務。然而，如果沒有可用服務，客戶端會使用其它AZ中的 Eureka 服務。
• etcd：高可用、分佈式、一致性的鍵值存儲，用於共享配置和服務發現。Kubernetes 和 Cloud Foundry 是兩個使用 etcd 的著名項目。
• consul – 發現和配置的服務，提供 API 實現客戶端註冊和發現服務。Consul 通過健康檢查來判斷服務的可用性。
• Apache ZooKeeper – 被分佈式應用廣泛使用的高性能協調服務。Apache ZooKeeper 最初是 Hadoop 的子項目，現在已成爲頂級項目。
• 此外，如前所強調，像 Kubernetes、Marathon 和 AWS 並沒有明確的服務註冊，相反，服務註冊已經內置在基礎設施中。

服務註冊的方式

如前所述，服務實例必須在註冊表中註冊和註銷。註冊和註銷有兩種不同的方法。方法一是服務實例自己註冊，也叫自注冊模式（self-registration pattern）；另一種是採用管理服務實例註冊的其它系統組件，即第三方註冊模式。

自注冊方式

當使用自注冊模式時，服務實例負責在服務註冊表中註冊和註銷。另外，如果需要的話，一個服務實例也要發送心跳來保證註冊信息不會過時。下圖描述了這種架構：

• Netflix OSS Eureka 客戶端是非常好的案例，它負責處理服務實例的註冊和註銷。Spring Cloud 能夠執行包括服務發現在內的各種模式，使得利用 Eureka 自動註冊服務實例更簡單，

第三方註冊模式

使用第三方註冊模式，服務實例則不需要向服務註冊表註冊；相反，被稱爲服務註冊器的另一個系統模塊會處理。服務註冊器會通過查詢部署環境或訂閱事件的方式來跟蹤運行實例的更改。一旦偵測到有新的可用服務實例，會向註冊表註冊此服務。服務管理器也負責註銷終止的服務實例。下面是這種模式的架構圖。

• Registrator 是一個開源的服務註冊項目，它能夠自動註冊和註銷被部署爲 Docker 容器的服務實例。Registrator 支持包括 etcd 和 Consul 在內的多種服務註冊表。
• NetflixOSS Prana 是另一個服務註冊器，主要面向非 JVM 語言開發的服務，是一款與服務實例一起運行的並行應用。Prana 使用 Netflix Eureka 來註冊和註銷服務實例。
• 服務註冊器是部署環境的內置組件。由 Autoscaling Group 創建的 EC2 實例能夠自動向 ELB 註冊。Kubernetes 服務自動註冊並能夠被發現

微服務主要框架

Spring Cloud

內容來自《Spring Cloud 入門總結》 知乎 老劉

簡介

Spring Cloud 就是微服務系統架構的一站式解決方案，在構建微服務的過程中需要做如服務發現註冊 、配置中心 、消息總線 、負載均衡 、斷路器 、數據監控 等操作，而 Spring Cloud 爲我們提供了一套簡易的全家桶式編程模型，使我們能在 Spring Boot 的基礎上輕鬆地實現微服務項目的構建。

社區支持強大，更新非常快，所以開發效率高。

我們需要特別感謝Netflix ，這家很早就成功實踐微服務的公司，幾年前把自家幾乎整個微服務框架棧貢獻給了社區，Spring Cloud主要是對Netflix開源組件的進一步封裝。還有Pivotal和Netflix是其強大的後盾與技術輸出。其中Netflix開源的整套微服務架構套件是Spring Cloud的核心。

版本

Spring Cloud 的版本號並不是我們通常見的數字版本號，而是一些很奇怪的單詞。這些單詞均爲英國倫敦地鐵站的站名。同時根據字母表的順序來對應版本時間順序，比如：最早 的 Release 版本 Angel，第二個 Release 版本 Brixton（英國地名），然後是 Camden、 Dalston、Edgware、Finchley、Greenwich、Hoxton。

服務發現-Eureka

Eureka是基於REST的服務，主要在AWS雲中用於定位服務。我們稱此服務爲Eureka服務器。Eureka還帶有一個基於Java的客戶端組件Eureka Client，Eureka Client查詢一個註冊中心，使與服務的交互變得更加容易。

Eureka Client通過心跳機制，每隔30秒(默認情況下)發送一次心跳來續約，如果 Eureka Server在90秒沒有收到 Eureka Client 的續約，它會將實例從其註冊表中刪除。

大家可能覺得美國人起名都沒什麼歷史文化積澱，比如Apple（水果）、IBM（International Business Machines Corporation 萬國商業機器公司）、HP（創始人的名字開頭字母）、Facebook（臉書）。。。而中國人起的名字都特別有文化：鴻蒙、天問、九章。。。Eureka這個詞其實還是挺有歷史感的，因爲它曾經出自阿基米德之口。阿基米德在浴缸裏想到如何爲國王鑑別王冠的含金量後，吐出的就是這個詞，Eureka！意思是找到了！

Eureka的設計者認爲對於服務發現而言，可用性比數據一致性更加重要，Eureka 設計則遵循AP原則。

負載均衡之 Ribbon

Ribbon 是 Netflix 公司的一個開源的負載均衡項目，是一個IPC內負載均衡器，運行在消費者端。

Hystrix之熔斷和降級

在分佈式環境中，不可避免地會有許多服務依賴項中的某些失敗。Hystrix是一個庫，可通過添加等待時間容限和容錯邏輯來幫助您控制這些分佈式服務之間的交互。Hystrix通過隔離服務之間的訪問點，停止服務之間的級聯故障並提供後備選項來實現此目的，所有這些都可以提高系統的整體彈性。

• 熔斷：就是服務雪崩的一種有效解決方案。當指定時間窗內的請求失敗率達到設定閾值時，系統將通過斷路器直接將此請求鏈路斷開。

• 降級：是爲了更好的用戶體驗，當一個方法調用異常時，通過執行另一種代碼邏輯來給用戶友好的回覆。比如有一個熱點新聞出現了，我們會推薦給用戶查看詳情，然後用戶會通過id去查詢新聞的詳情，但是因爲這條新聞太火了，大量用戶同時訪問可能會導致系統崩潰，那麼我們就進行服務降級，一些請求會做一些降級處理比如當前人數太多請稍後查看等等。

微服務網關——Zuul

ZUUL 是從設備和 web 站點到 Netflix 流應用後端的所有請求的前門。作爲邊界服務應用，ZUUL 是爲了實現動態路由、監視、彈性和安全性而構建的。它還具有根據情況將請求路由到多個 Amazon Auto Scaling Groups（亞馬遜自動縮放組，亞馬遜的一種雲計算方式） 的能力

但是升級較慢，有人已經轉到Spring Cloud Gateway

Spring Cloud配置管理——Config

當微服務系統開始慢慢地龐大起來，那麼多 Consumer 、Provider 、Eureka Server、Zuul 系統都會持有自己的配置，這個時候我們在項目運行的時候可能需要更改某些應用的配置，Config能對配置文件統一地進行管理，又能在項目運行時動態修改配置文件。

Dubbo

Dubbo是阿里開發的RPC框架及服務治理框架. 捐獻給了Apache。Apache Dubbo 是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動註冊和發現。

或許很多人會說Spring Cloud和Dubbo的對比有點不公平，Dubbo只是實現了服務治理，而Spring Cloud下面有17個子項目（可能還會新增）分別覆蓋了微服務架構下的方方面面，Dubbo僅僅關注服務治理（東西向通訊），一定程度來說，Dubbo只是Spring Cloud Netflix中的一個子集。

服務自動註冊和發現

遠程方法調用

dubbo 底層就是 spring，Netty（適合小數據量、大併發的NIO），Zookeeper（Dubbo 原生支持的Redis 方案需要服務器時間同步，且性能消耗過大，Zookeeper 保證的是CP ）。服務發佈的時候 dubbo 依賴的協議，可以配置 dubbo（適合小數據量、大併發的NIO）、RMI、webservice、Thrift、Hessain、http等協議。

Dubbo 3.0重大革新
據瞭解，新的 Dubbo 內核與 Dubbo 2.0 完全不同，但它兼容 2.0。Dubbo 3.0 將以 Streaming 爲內核，而不再是 2.0 時代的 RPC，但是 RPC 會在 3.0 中變成遠程 Streaming 對接的一種可選形態。而 Streaming 通道與 gRPC 類似，支持 HTTP/2，同時 REST 接口也會受到一等公民支持，但是梁飛也表示此次在通訊上的改動並不大，重點是在服務治理和編程模型上。

說到編程模型的革新，梁飛透露，此次 Dubbo 3.0 能夠開工，主要也是因爲新特性將去掉一切阻塞，以“一切同步”爲第一目標，在對 IO 密集業務的處理上，它能夠提高機器利用率，使得一半機器的成本被節省下來。他還表示，其實 Dubbo 3.0 技術選型重大變更的驅動因素，也就是降低成本，因爲在將系統服務化後，全業務線的機器都在等待返回數據，負載壓不上去，機器浪費嚴重。

這個去阻塞化的模式，其實就是使用了“反應式編程”模式（Reactive Programming），梁飛介紹，在 Dubbo 3.0 中，reactive 將成爲核心，會做到客戶端、服務端、緩存和數據庫，全程無阻塞。在數據庫上，JDBC 驅動將進行更改，同時，爲了性能，還會配合使用阿里畢玄對 JVM 協程的改造。更爲重要的是，這個重大變更，不僅體現在 Dubbo 上，它也將影響到阿里 10 年來積累的中間件。

負載均衡

dubbo-cluster 集羣模塊，將多個服務提供方僞裝爲一個提供方，包括：負載均衡、容錯、路由等，集羣的地址列表可以是靜態配置的，也可以是由註冊中心下發。

ServiceMesh

該部分內容來自

• 《Pattern: Service Mesh》Aug 3, 2017，Phil Calçado
• 《什麼是 Service Mesh》，Kenshin，知乎

Buoyant的CEO William Morgan，也就是Service Mesh這個詞的發明人，對Service Mesh的定義:
服務網格是一個基礎設施層，用於處理服務間通信。雲原生應用有着複雜的服務拓撲，服務網格保證請求在這些拓撲中可靠地穿梭。在實際應用當中，服務網格通常是由一系列輕量級的網絡代理組成的，它們與應用程序部署在一起，但對應用程序透明。

Service Mesh 是微服務時代的 TCP/IP 協議。分佈式系統特有的通信語義又出現了，如熔斷策略、負載均衡、服務發現、認證和授權、quota限制、trace和監控等等，於是服務根據業務需求來實現一部分所需的通信語義。

爲了避免每個服務都需要自己實現一套分佈式系統通信的語義功能，隨着技術的發展，一些面向微服務架構的開發框架出現了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等等，這些框架實現了分佈式系統通信需要的各種通用語義功能：如負載均衡和服務發現等，因此一定程度上屏蔽了這些通信細節，使得開發人員使用較少的框架代碼就能開發出健壯的分佈式系統。

也被形象稱爲邊車(Sidecar)模式，如下圖，早期有一些摩托車，除了主駕駛位，還帶一個邊車位，可以額外坐一個人。業務代碼進程(相當於主駕駛)共享一個代理(相當於邊車)，代理除了負責服務發現和負載均衡，還負責動態路由、容錯限流、監控度量和安全日誌等功能，這些功能是具體業務無關的，屬於跨橫切面關注點(Cross-Cutting Concerns)範疇。

• Service Mesh 一代

  
  

• Service Mesh 二代

  
  

目前Service Mesh還處於演進的過程中，Istio 作爲目前最流行的 Service Mesh 技術之一，前景值得關注。

一些大廠(Airbnb，華爲，新浪微博，螞蟻金服等)在試水。

拓展

CloudFoundry的沒落

打包機制上的缺陷：

Cloud Foundry最核心的組件就是應用的打包和分發機制，也是開發者打交道最多的功能。Cloud Foundry爲每一種主流的語言都定義了一套打包的方式，這些方式之間毫無章法。但就是這個打包功能，成了Cloud Foundry的軟肋，一直爲用戶所詬病。開發者不得不爲每一種語言，每一種框架，甚至是每個版本應用維護一個打好的包，還有可能出現本機運行成功，打了個包上傳上去之後就無法運行的情況。情況最嚴重的時候，開發者在調試雲平臺系統上花的時間都已經比開發一個新軟件的時間要長了。

Docker解決了這個痛點，祕訣就是鏡像。不同於Cloud Foundry那種執行文件+啓動腳本的打包結果，鏡像提供給用戶的是一套完整的運行環境，每一個鏡像都可以指定操作系統版本，內部可以構建程序執行的文件結構，並且一份鏡像可以完全共享在多處使用。

CloudFoundry提出來了一套兼容Docker格式的技術，但並不是Docker，並且對傳統有狀態的應用程序的處理技術不是很清晰。

CloudFoundry則趨於自成體系的專有軟件。

IaaS，PaaS，SaaS市場

IaaS的利潤率在5%到20%之間，而PaaS和SaaS的利潤率要高出不少。

Docker 之“死”

• Swarm的沒落
• K8S從1.20開始棄用Docker支持，替代品：Containerd，cri-o。
• docker自身的問題《How Docker broke in half》
  路線不明確，一直糾結於商業化和社區的發展模式。之前有過Google和Docker的談判，但是最終談判破裂，docker沒能成爲K8S生態系統的一部分。其次，過早的圖未窮而匕首現。商業化並不成功，Docker desktop開始收費，大家擔心這是一個屠龍者變成惡龍的故事。
• K8S的強大，網絡、存儲都可以做，編排的更好。

新的領域：WebAssembly

部分內容參考：
【1】知乎 網易數帆
【2】微服務模式：https://microservices.io/patterns/microservices.html
【3】API Gateway BFF：https://microservices.io/patterns/apigateway.html
【4】博客中文版：http://blog.daocloud.io/microservices-1/
【5】《CAP 定理的含義》阮一峯的網絡日誌
【6】《Introducing the Microservices Reference Architecture from NGINX》https://www.nginx.com/blog/introducing-the-nginx-microservices-reference-architecture/
【7】《RPC和Dubbo簡介》簡書 目睹了整個事件的索先生
【8】《Dubbo架構設計及原理詳解》 cnblog BarryWang

推薦讀物
【1】雲原生應用架構實踐
【2】《軟件開發教父，Martin Fowler》知乎 老中醫包治一針靈
【3】Netflix reactive：https://netflixtechblog.com/reactive-programming-in-the-netflix-api-with-rxjava-7811c3a1496a
【4】Netflex OSSC：https://netflix.github.io/
【5】淺析DDD(領域驅動設計) 簡書 Pursue
【6】《領域驅動設計:軟件核心複雜性應對之道:tackling complexity in the heart of software》EricEvans

註釋
【1】WebSocket 協議在2008年誕生，2011年成爲國際標準。所有瀏覽器都已經支持了。它的最大特點就是，服務器可以主動向客戶端推送信息，客戶端也可以主動向服務器發送信息，是真正的雙向平等對話，屬於服務器推送技術的一種。
【2】靜態響應

【3】這裏有個問題，request shaping是不是改成traffic shaping更好一些。