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