散耦合的架構是一種軟體應用程式開發模式,其中多個組件相互連接,但並不嚴重依賴對方。這些組件共同創建了一個總的網路或系統,儘管每個服務都是為執行單一任務而創建的獨立實體。鬆散耦合架構的主要目的是創建一個不會因為單個組件的失敗而失敗的系統。面向服務的架構(SOA)通常由鬆散耦合的架構組成。 鬆散耦合架構 ...
散耦合的架構是一種軟體應用程式開發模式,其中多個組件相互連接,但並不嚴重依賴對方。這些組件共同創建了一個總的網路或系統,儘管每個服務都是為執行單一任務而創建的獨立實體。鬆散耦合架構的主要目的是創建一個不會因為單個組件的失敗而失敗的系統。面向服務的架構(SOA)通常由鬆散耦合的架構組成。
鬆散耦合架構的例子
考慮一個實例,你在一個程式中創建了兩個類,A和B。當A類的方法調用B類的方法或使用B類中定義的變數實例時,兩個類是緊密耦合的。然而,當A類依賴於B類的介面而不是B類中定義的方法時,兩個類是鬆散耦合的。
以上是一個使用鬆散耦合系統的訂餐應用程式的例子。該應用程式包含不同的服務,如訂單服務、餐廳服務、送貨服務和客戶服務。當客戶訂購食品時,訂單服務負責處理。餐廳服務接收這些數據並準備好食物,而送餐服務則處理送餐部分。客戶服務在需要時為客戶提供協助。在這種情況下,每個單獨的服務並不嚴重依賴其他任何服務。所有服務都通過API進行通信,以便發送和接收所需的信息。因此,當一個服務崩潰時,它可以立即被替換,而不會幹擾到應用程式的其他組件。同樣,訂單服務可以在高峰期或季節中自動擴展。
鬆散耦合的架構與緊密耦合的架構
鬆散耦合與緊密耦合的架構是一個需要思考的重要問題。在軟體開發領域,耦合是指一個對象對另一個對象的依賴性。一個對象對另一個對象的瞭解程度或一個對象對另一個對象的依賴程度決定了系統是鬆散耦合還是緊密耦合。當依賴程度很低時,我們說它是鬆散耦合的。基本上,這意味著一個對象知道其他對象通過API暴露出來的東西。同樣地,當一個系統的變化不會迫使另一個系統發生變化時,兩個系統就是鬆散耦合的。
鬆散耦合系統中的每個服務都被設計成具有單一的目的或責任,可以獨立部署、管理、擴展和移除。每個服務都包含一個用於通信的介面(REST API)。由於每個服務可以使用不同的編程語言、平臺、技術和框架,所以很容易對單個服務進行修改、執行測試、擴展服務和刪除服務而不影響系統。鬆散耦合的架構容納了廣泛的API和與介面解耦的可互操作的資源模式。
另一方面,緊耦合架構中的對象嚴重依賴於系統的其他組件。每個對象必須與其他對象或組件協作和協調,以完成一個功能。在這種情況下,一個類的邏輯被另一個類所調用。這意味著一個對象或類需要另一個對象或類來完成一項任務。因此,每個類都承擔著多種責任,對一個類的改變也迫使一個或多個其他類發生改變。
微服務在鬆散耦合的架構中的重要性
微服務是一種架構設計,有利於將應用程式開發成小型獨立的服務,這些服務運行自己的流程,並使用輕量級協議和消息系統進行通信,使其與平臺無關,與語言無關。每個服務都是獨立的、可測試的、高度可維護的、可獨立部署的,並且實現了一種業務能力。最重要的是,每個服務都由一個小團隊來維護、部署、創建和擁有。微服務是面向服務的架構的一個明顯的變體,它利用了鬆散耦合的架構方法。事實上,鬆散耦合是微服務架構的關鍵組成部分。
微服務架構對於創建一個鬆散耦合的系統是非常重要的,因為耦合在軟體系統設計中是不可避免的。例如,在一個電子商務門戶中,訂單服務應該使用API與客戶服務或交付服務進行通信。也就是說,微服務允許你儘可能地保持這種耦合性。
微服務由一組協作的服務組成,它們使用不同的耦合方法一起工作。
運行時耦合。一個服務的可用性影響另一個服務的可用性的程度。
設計時耦合。一個服務的變化會引發另一個服務的變化的程度。
基礎設施耦合。一個服務的資源消耗影響另一個服務的資源消耗的程度。
每種耦合方法都帶來了自己的挑戰。例如,運行時耦合會在變化發生時降低可用性。因此,在微服務架構中,你會遇到一個很長的調用隊列。
當你實施設計時耦合時,API的一個小變化需要改變所有與該API交互的服務。因此,所有與這些服務有關的團隊都必須合作並討論這個變化。因此,保持設計時耦合儘可能的鬆散是很重要的,特別是當不同的協作團隊參與進來的時候。
微服務使設計時耦合模型很容易實現鬆散耦合,同時使你能夠使用精益開發和DevOps CI/CD最佳實踐有效地處理耦合挑戰。
哪些AWS服務可用於鬆散耦合的架構?
亞馬遜簡單排隊服務(SQS)和簡單通知服務(SNS)是強大的機制,可以幫助你建立高度可擴展和鬆散耦合的架構,在平臺、網路和操作層面上進行耦合:
亞馬遜簡單排隊服務(SQS)。當客戶下訂單時,接收該訂單的應用程式將其作為消息發送到SQS。該消息被排隊,並由AWS Lambda等函數消費。一旦消息被處理,它就會被自動刪除。
亞馬遜簡單通知服務(SNS)。以 "發佈-訂閱 "的模式工作,其中應用程式將訂單消息發送到SNS主題,然後在不同的端點上複製,以便並行運行進程。
AWS Lambda。無伺服器計算引擎。
AWS Fargate。用於無伺服器計算的容器即服務。
AWS AutoScaling。自動縮放服務。
亞馬遜S3。存儲服務。
亞馬遜API網關。API管理服務。
AWS CloudWatch。用於管理SQS中的消息。
鬆散耦合的架構場景
與緊耦合架構不同的是,松耦合架構在單個節點上大量運行較小的作業,併在節點內進行並行化,而緊耦合架構運行的是成千上萬個相互依賴的並行進程或內核,以進行計算。由於進程之間的依賴性不高,失去一個節點並不影響整體功能。作業要麼稍後處理,要麼被刪除。
在選擇鬆散耦合的架構時,必須考慮以下幾個方面:
計算--底層的EC2實例類型應該根據應用程式的記憶體與計算比率來確定。
網路--在鬆散耦合的情況下,帶寬和延遲問題不是一個問題,因為並行運行的進程不需要太多的互動。
存儲--每個鬆散耦合的應用程式都有不同的存儲要求。因此,要考慮數據集大小和數據傳輸要求。
部署--鑒於鬆散耦合的應用程式在安裝在不同可用區的核心上運行,它們可以使用AWS Parallel Cluster或AWS Batch進行有效部署。
具有鬆散耦合架構的AWS無伺服器方案
無伺服器計算是一種雲原生軟體開發方法,可以幫助企業輕鬆、無縫地構建和運行應用程式,而沒有配置和管理伺服器的負擔。伺服器仍然被使用,但由雲計算供應商管理。這裡的問題是,收費不是基於伺服器的數量或帶寬,而是基於使用率。它使企業能夠以現收現付的方式購買後端伺服器,只為使用的服務付費。
無伺服器計算有兩種模式。
1. 功能即服務。一種允許你根據事件運行代碼的服務,沒有複雜的基礎設施管理。應用程式以無狀態模式運行,其中伺服器和客戶端是鬆散耦合的,因此是獨立、靈活、可擴展和容錯的。
關於計算引擎,AWS Lambda是AWS的一個流行的無伺服器FaaS工具。對於基於容器的工作負載,可以使用AWS Fargate。對於事件觸發,我們推薦使用Amazon SQS、AWS SNS和Eventbridge。
2. 後臺即服務。運行伺服器端邏輯的任務被外包給一個雲供應商。AWS BaaS工具包括用於記錄的Amazon Elasticsearch Service、用於分析的AWS Kinesis和用於IAM的AWS Cognito。
有三種類型的無伺服器調用方法:
同步調用--當客戶端請求需要立即響應時使用。
非同步調用--當你不希望客戶端等待響應,而是在流程完成後通過通知提醒客戶端時使用。
流式調用--用於以相同的速度進行上游、處理和下游的數據。
談到無伺服器計算,帶有非同步方法的松耦合架構是一個不錯的選擇。也就是說,不要忘了確保它是故障快速的,並能正確地扇出。
結論
軟體技術迅速變化,迫使組織不斷適應新的技術和趨勢。當涉及到鬆散耦合與緊密耦合的架構時,信息流和服務之間的協調在緊密耦合的架構中會更好。然而,在對你的應用程式進行修改時,它們會限制你的靈活性。鬆散耦合的架構是當下的需要。它不僅允許你即時交換或擴展組件,而且還能幫助你在不影響現有系統的可用性和性能的情況下增加新的功能。通過微服務、精益開發和DevOps實踐,鬆散耦合的架構讓你在競爭中保持優勢,甚至領先。
今天先到這兒,希望對雲原生,技術領導力, 企業管理,系統架構設計與評估,團隊管理, 項目管理, 產品管管,團隊建設 有參考作用 , 您可能感興趣的文章:
領導人怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下消息隊列架構
互聯網高效研發團隊管理演進之一
消息系統架構設計演進
互聯網電商搜索架構演化之一
企業信息化與軟體工程的迷思
企業項目化管理介紹
軟體項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共用
高效能的團隊建設
項目管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
互聯網資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變
如有想瞭解更多軟體設計與架構, 系統IT,企業信息化, 團隊管理 資訊,請關註我的微信訂閱號:
作者:Petter Liu
出處:http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利。
該文章也同時發佈在我的獨立博客中-Petter Liu Blog。