Cloud native是一種用於構建可以利用雲的所有功能的應用程序的方法。
是的，你說對了。這是一種方法。不是一個框架。不需要一堆步驟。因此，有上百萬種方法可以使雲原生化並實現雲計算“ Moksha”。
雲本機的一項關鍵原則是微服務。微服務是很小的模塊（有時不是那麼小），它們可以彼此獨立地工作。它們可能依賴於其他微服務，甚至依賴於數據庫等數據持久層。但是關鍵是要使用鬆散耦合。微服務通過“通信”進行協調。
這意味著每個微服務都位於不同的存儲庫中，並被獨立部署。對於那裡的DevOps員工，您有一個獨立的連續交付管道，專用於每個微服務。
我們如何讓微服務交流？
除了為微服務確定“ 前向兼容 ” API 的困難之外，讓它們說話並不像看起來那麼簡單。您需要考慮多個參數。這些是吞吐量，延遲和可伸縮性。
現在，有很多方法可以對不同的通信模式進行分類。同步（阻塞）和異步（非阻塞）被經常使用，但是我覺得這些主要是編程語言的特徵。我還將不考慮半雙工模式與全雙工模式，因為這些天在大多數雲體系結構中很容易使用其中一種（或什至兩種都使用）。
因此，讓我們開始吧。
它是什麼：在這裡，我們使我們的微服務直接相互通信。您可以使用HTTP進行傳統的請求響應，也可以使用websocket（或HTTP2）進行流式傳輸。
兩個或多個微服務之間絕對沒有中間節點（路由器和負載平衡器除外）。您可以直接連接到任何服務，只要知道它們的服務地址和它們使用的API。
聽起來很基本吧？差不多是。有一些很棒的協議，例如GRPC，可以使生活更加輕鬆。
優點：
- 低延遲：此方法具有最低的延遲。這裡沒有中間人。它很快。限制的施加主要是由於不良的API實現。但是同樣，GRPC之類的工具可確保您在API層獲得最佳性能。
- 易於實現：無代理設計易於可視化和實現。這使生活更加輕鬆，世界變得更加幸福。
- 易於調試：此方法非常易於調試，尤其是在我將要討論的下一個方法中。在分佈式系統中，調試或跟蹤錯誤所在的位置非常重要。一天多次發佈新更新時，這一點變得尤為重要。
- 高吞吐量：在這種機制中，實際上是在工作而不是路由上花費了更多的CPU週期。現在可能還不那麼明顯，但是經紀人的設計會使這一點更加清楚。大多數數據庫API實際上使用無代理設計也就不足為奇了。
缺點：
- 服務發現：在這種設計中，服務發現至關重要。服務發現機制需要具有足夠的響應能力和可伸縮性，以反映集群的最新狀態。
- 連接噩夢：想象一下所有微服務是否需要相互連接。那將有很多聯繫。這些連接大多數都是相當空閒的。結果，因此浪費了很多資源。
- 緊密耦合：本質上，無經紀人設計緊密耦合。假設您有一個微服務來處理在線支付。現在，您希望另一個微服務可以為您提供每分鐘發生的付款數量的實時更新。這將要求您在多個微服務中進行修改，這是不希望的。
在許多情況下，無經紀人的設計就是行不通的。您通常需要簡單地發佈一次消息，並讓多個訂閱者使用它。這是經紀人設計出現的地方。
消息傳遞總線（代理）設計
簡介：在此體系結構中，所有通信都通過一組代理進行路由。代理是運行某些高級路由算法的服務器程序。
每個微服務都連接到代理。微服務可以通過相同的連接發送和接收消息。發送消息的服務稱為發佈者，接收者稱為訂閱者。消息被髮布到特定的“主題”。訂戶接收那些有關其已訂閱主題的消息。
優點：
- 負載平衡：大多數消息代理都支持開箱即用的負載平衡。這使整個體系結構變得更加簡單和高度可擴展。一些代理（例如RabbitMQ）具有內置的重試功能，以及更多的重試功能，可以使通信通道更加可靠。
- 服務發現：使用消息傳遞後端時不需要服務發現。所有微服務均充當客戶端。消息代理是唯一需要發現的服務。
- 扇入和扇出：消息傳遞後端使分發工作負載和彙總結果更加容易。最好的部分是添加工作程序微服務可以透明地完成，而不必更新其他微服務。
- 基於流的設計：這種方法也催生了流的概念。每個主題本質上都是消息流。任何用戶都可以根據需要使用這些流。使用流對系統設計進行建模的可能性是無限的。
缺點：
- 擴展代理：儘管優勢十分驚人，但擴展代理本身對於高度分佈式的系統而言是一項挑戰。這只是與微服務一起維護的另一部分。
- 較高的延遲：消息總線中的躍點數會增加總體延遲。對於類似RPC的用例，尤其如此。在關鍵任務應用中，這可能不是可行的解決方案。
- 更高的資源利用率：代理需要CPU，內存和存儲資源才能運行。否則，可以將這些資源用於運行其他微服務。對於小型集群而言，與代理設計相關的開銷可能太大。
僅瞭解各種體系結構的優缺點是不夠的。重要的是要知道何時使用什麼。
您必須始終默認使用無代理設計。如果您需要流的靈活性或需要利用消息總線的pub-sub語義，請進行切換。如果您是從頭開始，那麼從無經紀人的設計開始，然後在需求增加時切換就可以了。
不必只選擇一個。您可以同時使用。對於我們的工具，我們正在使用代理設計來實現RPC調用。與我們的數據庫層的通信是無代理的，以提供較低的延遲。
如果您選擇基於微服務的體系結構，那麼我總是建議您進行事件驅動。 事件驅動的體系結構 可以看作是具有高級代理的核心 ，該代理具有內置的大量功能（如任務調度）。
包起來
對工作使用正確的方法很重要。選擇溝通方式是一項基本決定，需要格外小心。
兩者都有多個選項。堅持一個完善的框架幾乎比從頭開始做更有意義。有很多選擇。對於消息代理，您具有RabbitMQ，Nats，Kafka等，並且每個代理都是針對特定消息語義而構建的。
另一個很棒的方法是將後端作為服務使用，例如Space Cloud。Space Cloud將使整個後端自動化，因此您可以專注於業務邏輯而不是雲架構。
閱讀更多 愛碼農 的文章
