松散耦合架構(gòu)是一種軟件應(yīng)用程序開發(fā)模型，其中多個(gè)組件相互連接但彼此不嚴(yán)重依賴。盡管每個(gè)服務(wù)都是為執(zhí)行單個(gè)任務(wù)而創(chuàng)建的獨(dú)立實(shí)體，但這些組件共同創(chuàng)建了一個(gè)通用網(wǎng)絡(luò)或系統(tǒng)。

松散耦合架構(gòu)的主要目的是創(chuàng)建一個(gè)不會(huì)因單個(gè)組件故障而失敗的系統(tǒng)。面向服務(wù)的架構(gòu) (SOA) 通常包含松散耦合的架構(gòu)。

松散耦合架構(gòu)示例

考慮一個(gè)實(shí)例，其中您在程序中創(chuàng)建了兩個(gè)類：A 和 B。當(dāng) A 類的方法調(diào)用 B 類的方法或使用 B 類中定義的變量實(shí)例時(shí)，這兩個(gè)類是緊密耦合的。但是，當(dāng) A 類依賴于 B 類的接口而不是 B 類中定義的方法時(shí)，這兩個(gè)類是松散耦合的。

上面是一個(gè)使用松散耦合系統(tǒng)的訂餐應(yīng)用程序示例。該應(yīng)用程序包含不同的服務(wù)，例如訂單服務(wù)、餐廳服務(wù)、送貨服務(wù)和客戶服務(wù)。當(dāng)客戶訂購(gòu)食品時(shí)，訂單服務(wù)負(fù)責(zé)處理它。餐廳服務(wù)接收此數(shù)據(jù)并準(zhǔn)備食物，而送貨服務(wù)處理送貨部分?？蛻舴?wù)在需要時(shí)為客戶提供幫助。在這種情況下，每個(gè)單獨(dú)的服務(wù)都不會(huì)嚴(yán)重依賴任何其他服務(wù)。所有服務(wù)都通過 API 進(jìn)行通信，以便發(fā)送和接收所需的信息。因此，當(dāng)一個(gè)服務(wù)崩潰時(shí)，可以在不影響應(yīng)用程序其他組件的情況下立即替換它。同樣，訂單服務(wù)可以在高峰時(shí)段或季節(jié)自動(dòng)縮放。

松耦合架構(gòu)與緊耦合架構(gòu)

松散耦合與緊耦合架構(gòu)是需要深思的一個(gè)重要問題。在軟件開發(fā)領(lǐng)域，耦合是指一個(gè)對(duì)象對(duì)另一個(gè)對(duì)象的依賴。一個(gè)對(duì)象對(duì)另一個(gè)對(duì)象的了解程度或一個(gè)對(duì)象對(duì)另一個(gè)對(duì)象的依賴程度決定了系統(tǒng)是松耦合還是緊耦合。當(dāng)依賴級(jí)別較低時(shí)，我們說它是松散耦合的?；旧?，這意味著一個(gè)對(duì)象知道其他對(duì)象通過 API 公開的內(nèi)容。類似地，當(dāng)對(duì)一個(gè)系統(tǒng)的更改不會(huì)強(qiáng)制更改另一個(gè)系統(tǒng)時(shí)，兩個(gè)系統(tǒng)是松散耦合的。

松散耦合系統(tǒng)中的每項(xiàng)服務(wù)都是為單一目的或職責(zé)而設(shè)計(jì)的，并且可以獨(dú)立部署、管理、擴(kuò)展和刪除。每個(gè)服務(wù)都包含一個(gè)用于通信的接口（REST API）。鑒于每項(xiàng)服務(wù)都可以使用不同的編程語(yǔ)言、平臺(tái)、技術(shù)和框架，因此很容易在不影響系統(tǒng)的情況下更改單個(gè)服務(wù)、執(zhí)行測(cè)試、擴(kuò)展服務(wù)和刪除它們。松散耦合的體系結(jié)構(gòu)可容納廣泛的 API 和與接口分離的可互操作資源模式。

另一方面，緊耦合架構(gòu)中的對(duì)象嚴(yán)重依賴于系統(tǒng)的其他組件。每個(gè)對(duì)象都必須與其他對(duì)象或組件協(xié)作和協(xié)調(diào)才能完成功能。在這種情況下，一個(gè)類的邏輯被另一個(gè)類調(diào)用。這意味著一個(gè)對(duì)象或類需要另一個(gè)對(duì)象或類來完成一項(xiàng)任務(wù)。因此，每個(gè)類承擔(dān)多重責(zé)任，對(duì)一個(gè)類所做的更改也會(huì)迫使一個(gè)或多個(gè)其他類發(fā)生更改。

微服務(wù)在松耦合架構(gòu)中的重要性

微服務(wù)是一種架構(gòu)設(shè)計(jì)，有助于將應(yīng)用程序開發(fā)為小型獨(dú)立服務(wù)，這些服務(wù)運(yùn)行自己的進(jìn)程并使用輕量級(jí)協(xié)議和消息傳遞系統(tǒng)進(jìn)行通信，使它們與平臺(tái)和語(yǔ)言無關(guān)。每個(gè)服務(wù)都是獨(dú)立的、可測(cè)試的、高度可維護(hù)的、可獨(dú)立部署的，并實(shí)現(xiàn)了一種業(yè)務(wù)能力。最重要的是，每個(gè)服務(wù)都由一個(gè)小團(tuán)隊(duì)維護(hù)、部署、創(chuàng)建和擁有。微服務(wù)是面向服務(wù)的架構(gòu)的一個(gè)顯著變體，它利用了松散耦合的架構(gòu)方法。事實(shí)上，松耦合是微服務(wù)架構(gòu)的關(guān)鍵組成部分。

微服務(wù)架構(gòu)對(duì)于創(chuàng)建松耦合系統(tǒng)非常重要，因?yàn)轳詈显谲浖到y(tǒng)設(shè)計(jì)中是不可避免的。例如，在電子商務(wù)門戶中，訂單服務(wù)應(yīng)使用 API 與客戶服務(wù)或送貨服務(wù)進(jìn)行通信。也就是說，微服務(wù)允許您將這種耦合保持在最低限度。

微服務(wù)由一組協(xié)作服務(wù)組成，這些服務(wù)使用不同的耦合方法協(xié)同工作。

• 運(yùn)行時(shí)耦合：一項(xiàng)??服務(wù)的可用性影響另一項(xiàng)服務(wù)的可用性的程度。
• 設(shè)計(jì)時(shí)耦合：一個(gè)服務(wù)的變化觸發(fā)另一個(gè)服務(wù)變化的程度。
• 基礎(chǔ)設(shè)施耦合：一個(gè)服務(wù)的資源消耗對(duì)另一個(gè)服務(wù)的資源消耗的影響程度。

每種耦合方法都會(huì)帶來其自身的挑戰(zhàn)。例如，運(yùn)行時(shí)耦合會(huì)在發(fā)生更改時(shí)降低可用性。因此，您將在微服務(wù)架構(gòu)中遇到長(zhǎng)長(zhǎng)的調(diào)用隊(duì)列。

當(dāng)您實(shí)現(xiàn)設(shè)計(jì)時(shí)耦合時(shí)，API 中的一個(gè)小更改需要更改與該 API 交互的所有服務(wù)。因此，涉及這些服務(wù)的所有團(tuán)隊(duì)都必須協(xié)作并討論更改。因此，保持設(shè)計(jì)時(shí)耦合盡可能松散非常重要，尤其是當(dāng)涉及不同的協(xié)作團(tuán)隊(duì)時(shí)。

微服務(wù)使在設(shè)計(jì)時(shí)耦合模型中實(shí)現(xiàn)松散耦合變得容易，同時(shí)使您能夠使用精益開發(fā)和 DevOps CI/CD 最佳實(shí)踐有效地應(yīng)對(duì)耦合挑戰(zhàn)。

哪些 AWS 服務(wù)可用于松耦合架構(gòu)？

Amazon Simple Queuing Service (SQS) 和 Simple Notification Service (SNS) 是強(qiáng)大的機(jī)制，可以幫助您構(gòu)建高度可擴(kuò)展和松散耦合的架構(gòu)，并在平臺(tái)、網(wǎng)絡(luò)和操作級(jí)別進(jìn)行耦合。

• Amazon Simple Queuing Service (SQS)：當(dāng)客戶下訂單時(shí)，接收該訂單的應(yīng)用程序會(huì)將其作為消息發(fā)送到 SQS。消息排隊(duì)并由 AWS Lambda 等函數(shù)使用。處理完消息后，它會(huì)自動(dòng)刪除。
• Amazon Simple Notification Service (SNS)：作為“發(fā)布-訂閱”模型工作，其中應(yīng)用程序?qū)⒂唵蜗l(fā)送到 SNS 主題，然后將其復(fù)制到各個(gè)端點(diǎn)以并行運(yùn)行流程。
• AWS Lambda：無服務(wù)器計(jì)算引擎。
• AWS Fargate：用于無服務(wù)器計(jì)算的容器即服務(wù)。
• AWS AutoScaling：自動(dòng)縮放服務(wù)。
• Amazon S3：存儲(chǔ)服務(wù)。
• Amazon API Gateway：API 管理服務(wù)。
• AWS CloudWatch：用于管理 SQS 中的消息。

松耦合架構(gòu)場(chǎng)景

與運(yùn)行數(shù)千個(gè)相互依賴以執(zhí)行計(jì)算的并行進(jìn)程或內(nèi)核的緊密耦合架構(gòu)不同，松散耦合架構(gòu)在單個(gè)節(jié)點(diǎn)上運(yùn)行大量較小的作業(yè)，并在節(jié)點(diǎn)內(nèi)進(jìn)行并行化。由于進(jìn)程彼此之間的依賴性不高，因此丟失一個(gè)節(jié)點(diǎn)不會(huì)影響整體功能。該作業(yè)要么稍后處理，要么被刪除。

選擇松散耦合架構(gòu)時(shí)，考慮以下幾個(gè)方面很重要。

• 計(jì)算：底層 EC2 實(shí)例類型應(yīng)根據(jù)應(yīng)用程序的內(nèi)存與計(jì)算比率來確定。
• 網(wǎng)絡(luò)：帶寬和延遲問題在松散耦合的場(chǎng)景中不是問題，因?yàn)椴⑿羞\(yùn)行的進(jìn)程不需要太多交互。
• 存儲(chǔ)：每個(gè)松散耦合的應(yīng)用程序都有不同的存儲(chǔ)要求。因此，請(qǐng)考慮數(shù)據(jù)集大小和數(shù)據(jù)傳輸要求。
• 部署：由于松散耦合的應(yīng)用程序在安裝在不同可用性區(qū)域的核心上運(yùn)行，因此可以使用 AWS ParallelCluster 或 AWS Batch 高效地部署它們。

具有松散耦合架構(gòu)的 AWS 無服務(wù)器場(chǎng)景

無服務(wù)器計(jì)算是一種云原生軟件開發(fā)方法，可幫助組織輕松無縫地構(gòu)建和運(yùn)行應(yīng)用程序，而無需配置和管理服務(wù)器的負(fù)擔(dān)。服務(wù)器仍在使用，但由云供應(yīng)商管理。這里要注意的是，收費(fèi)不是基于服務(wù)器數(shù)量或帶寬，而是基于使用情況。它使組織能夠以現(xiàn)收現(xiàn)付的方式購(gòu)買后端服務(wù)器，并且只需為使用的服務(wù)付費(fèi)。

無服務(wù)器計(jì)算有兩種模式：

1. 功能即服務(wù)：允許您基于事件運(yùn)行代碼而無需復(fù)雜的基礎(chǔ)設(shè)施管理的服務(wù)。應(yīng)用程序以無狀態(tài)模式運(yùn)行，其中服務(wù)器和客戶端松散耦合，因此是獨(dú)立的、靈活的、可擴(kuò)展的和容錯(cuò)的。

關(guān)于計(jì)算引擎，AWS Lambda 是 AWS 流行的無服務(wù)器 FaaS 工具。對(duì)于基于容器的工作負(fù)載，AWS Fargate可用。對(duì)于事件觸發(fā)，我們建議使用Amazon SQS、AWS SNS和Eventbridge。

2. 后端即服務(wù)：運(yùn)行服務(wù)器端邏輯的任務(wù)外包給云供應(yīng)商。AWS BaaS 工具包括用于日志記錄的 Amazon Elasticsearch Service、用于分析的 AWS Kinesis 和用于 IAM 的 AWS Cognito。

Serverless 的調(diào)用方式分為三種：

1. 同步調(diào)用：當(dāng)客戶端請(qǐng)求需要立即響應(yīng)時(shí)使用。
2. 異步調(diào)用：當(dāng)您不希望客戶端等待響應(yīng)，而是在過程完成后通過通知提醒客戶端時(shí)使用。
3. Steaming Invocation：用于以相同的速度上游、處理和下游數(shù)據(jù)。

對(duì)于無服務(wù)器計(jì)算，采用異步方法的松散耦合架構(gòu)是一個(gè)不錯(cuò)的選擇。也就是說，不要忘記確保它是快速故障和正確扇出的。

結(jié)論

軟件技術(shù)瞬息萬變，迫使組織不斷適應(yīng)更新的技術(shù)和趨勢(shì)。當(dāng)談到松耦合與緊耦合架構(gòu)時(shí)，信息流和服務(wù)之間的協(xié)調(diào)在緊耦合架構(gòu)中更好。但是，它們限制了您在旅途中更改應(yīng)用程序時(shí)的靈活性。一個(gè)松散耦合的架構(gòu)是當(dāng)下的需要。它不僅允許您即時(shí)交換或擴(kuò)展組件，而且還可以幫助您添加新功能而不影響現(xiàn)有系統(tǒng)的可用性和性能。借助微服務(wù)、精益開發(fā)和 DevOps 實(shí)踐，松散耦合的架構(gòu)使您能夠在競(jìng)爭(zhēng)中保持領(lǐng)先，甚至領(lǐng)先。