在GeeCON 2018大會(huì)上，Michael Pl?d在一場(chǎng)介紹微服務(wù)之間不同的通信策略的演講中解釋說，在從單體架構(gòu)遷移到微服務(wù)架構(gòu)時(shí)，暗含在單體架構(gòu)中的復(fù)雜性會(huì)明確顯露出來，通信挑戰(zhàn)將呈指數(shù)級(jí)增長。

\\

Pl?d是InnoQ首席顧問。他首先指出，根據(jù)他的經(jīng)驗(yàn)，團(tuán)隊(duì)經(jīng)常把微服務(wù)視為默認(rèn)架構(gòu)。他強(qiáng)調(diào)，分布式系統(tǒng)是高難度的系統(tǒng)；如果你不需要一個(gè)分布式系統(tǒng)，你就不必為了微服務(wù)而力爭(zhēng)實(shí)現(xiàn)那樣的架構(gòu)。在這種情況下，構(gòu)建良好的單體通常是更好的選擇。

\\

當(dāng)單體不滿足需求而使用微服務(wù)時(shí)，必須把它們集成，Pl?d指出，這不只是技術(shù)問題，還有其他方面的影響：

\\

• 團(tuán)隊(duì)之間需要通過溝通來解決集成問題，這可能會(huì)導(dǎo)致政治和治理問題。\\t
• 耦合：實(shí)現(xiàn)服務(wù)之間的松耦合非常重要，否則，你很容易最終得到一個(gè)分布式單體。\\t
• 質(zhì)量標(biāo)準(zhǔn)：在一致性、性能、可擴(kuò)展性、健壯性方面，找出真正需要的是什么，你應(yīng)該盡早評(píng)估你的應(yīng)用程序。\\t
• 技術(shù)：雖然REST很常用，但那不是唯一的通信選項(xiàng)。\

為了幫助團(tuán)隊(duì)通信及管理耦合，Pl?d指出，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）對(duì)在業(yè)務(wù)層面找出邊界非常有幫助——有界上下文。這些上下文彼此之間通常以不同的方式進(jìn)行交互，為了描述它們之間的關(guān)系，可以使用上下文映射。這些交互模式包括：

\\

• 打開主機(jī)服務(wù)：指定一個(gè)可供服務(wù)使用的協(xié)議，如REST；\\t
• 共享內(nèi)核：兩個(gè)服務(wù)可以共享部分代碼或定義交互的庫；\\t
• 消費(fèi)者/供應(yīng)商：一個(gè)服務(wù)是另一個(gè)服務(wù)的消費(fèi)者，因此，可能會(huì)影響它的實(shí)現(xiàn)；\\t
• 防腐層：消費(fèi)者服務(wù)創(chuàng)建一個(gè)適配器，最小化它與之交互的另一個(gè)服務(wù)所帶來的影響。\

看下通信的技術(shù)方面，Pl?d首先介紹了通信的一般分類——Orchestration和Choreography。使用Orchestration，微服務(wù)知道過程，會(huì)主動(dòng)調(diào)用其他服務(wù)來完成任務(wù)。使用Choreography，微服務(wù)會(huì)發(fā)布一個(gè)事件，其他服務(wù)會(huì)響應(yīng)事件，完成相應(yīng)的動(dòng)作。在Pl?d看來，這是一個(gè)重要的區(qū)別，他認(rèn)為，我們應(yīng)該就系統(tǒng)首選的工作方式做架構(gòu)決策。他還建議考慮宏架構(gòu)和微架構(gòu)，并指出，微服務(wù)并不是說團(tuán)隊(duì)可以隨意選擇他們喜歡的東西，因?yàn)槟菢幼龅脑?#xff0c;你最終會(huì)陷入完全的混亂。相反，他建議采用一種有規(guī)則的宏架構(gòu)，所有團(tuán)隊(duì)都必須遵守這些規(guī)則。在微架構(gòu)中，團(tuán)隊(duì)有更大的自由，可以選擇他們自己的實(shí)現(xiàn)風(fēng)格。

\\

讓我們看下通信的技術(shù)選項(xiàng)，Pl?d指出了四種類型：

\\

• RESTful資源\\t
• 消息傳遞\\t
• 領(lǐng)域事件\\t
• 訂閱\

雖然REST如今已經(jīng)廣為人知，但根據(jù)Pl?d的經(jīng)驗(yàn)，只有很少團(tuán)隊(duì)很好地實(shí)現(xiàn)了，尤其是在超媒體和多表示形式方面。他指出，實(shí)現(xiàn)一個(gè)RESTful資源調(diào)用非常簡單，但是，實(shí)現(xiàn)一個(gè)可以在微服務(wù)環(huán)境中正常運(yùn)行的健壯調(diào)用要困難許多。以下是需要知道的一些陷阱和挑戰(zhàn)：

\\

• 服務(wù)發(fā)現(xiàn)：一種服務(wù)用來發(fā)現(xiàn)它與之通信的服務(wù)的URL的方式。\\t
• 彈性：包括如何處理錯(cuò)誤和宕機(jī)。服務(wù)的優(yōu)雅退化非常重要，可以避免異常服務(wù)使整個(gè)應(yīng)用程序性能下降。\\t
• 負(fù)載均衡：可以處理不斷增長的負(fù)載。有許多不同的實(shí)現(xiàn)方法，使用哪種方法取決于應(yīng)用程序的運(yùn)行環(huán)境。\

下一個(gè)選項(xiàng)是消息傳遞，微服務(wù)發(fā)送和消費(fèi)消息，通常是通過一個(gè)消息代理。下面描述的這些有關(guān)REST的挑戰(zhàn)不是很切題：

\\

• 服務(wù)發(fā)現(xiàn)已經(jīng)沒意義，因?yàn)榉?wù)僅知道消息系統(tǒng)。\\t
• 彈性主要由消息系統(tǒng)處理。主要的風(fēng)險(xiǎn)是延遲因?yàn)殄e(cuò)誤或宕機(jī)增加。\\t
• 負(fù)載均衡是通過向上擴(kuò)展消息系統(tǒng)或增加消息消費(fèi)者數(shù)量來實(shí)現(xiàn)的。\

Pl?d的第三個(gè)選項(xiàng)是領(lǐng)域事件。它們表示過去在業(yè)務(wù)層面上已經(jīng)發(fā)生的事實(shí)。使用它們進(jìn)行通信會(huì)得到事件驅(qū)動(dòng)的微服務(wù)，現(xiàn)如今，這是一種非常流行的架構(gòu)風(fēng)格。當(dāng)使用事件通信時(shí)，對(duì)于事件中的有效載荷，他介紹了幾個(gè)可選方案：

\\

• 滿負(fù)載模式：事件中包含處理事件所需的所有數(shù)據(jù)，例如關(guān)于客戶的所有數(shù)據(jù)。這可以簡化消費(fèi)者的工作，但也意味著更緊密的耦合。\\t
• REST URL：只有一個(gè)指向代表事件的資源的URL。\\t
• 空模式：僅包含關(guān)于事件本身的數(shù)據(jù)。消費(fèi)者必須通過其他方式找到它需要的數(shù)據(jù)。\\t
• 混合模式：比如，有少量的數(shù)據(jù)和一個(gè)用于找到其他數(shù)據(jù)的URL。在大多數(shù)情況下，這都是Pl?d首選的方式。\

Pl?d最后的選項(xiàng)是使用Atom Feeds組合REST和事件。現(xiàn)在，服務(wù)會(huì)利用事件發(fā)布推送信息，消費(fèi)者訂閱并異步讀取。在大多數(shù)環(huán)境中，使用HTTP都非常容易通信，而且可以利用像ETags、最后修改時(shí)間、分頁和鏈接這樣的特性。另外一個(gè)好處是，服務(wù)發(fā)布推送信息，可以從消費(fèi)者完全解耦。推送消息的讀取完全是由消費(fèi)者按照它們認(rèn)為恰當(dāng)?shù)姆绞竭M(jìn)行的，而且，已消費(fèi)事件的跟蹤也是由消費(fèi)者完成的。

\\

為了提供推送消息，事件必須持久化，這就輪到事件源登場(chǎng)了。我們可以使用這些事件作為我們主要的持久化模型，這還使得我們可以使用CQRS來獲得視圖，這些視圖是經(jīng)過優(yōu)化的事件讀取模型。Pl?d特別指出，CQRS和事件源只是系統(tǒng)特定部分的解決方案，而不代表系統(tǒng)中隨處都在使用的架構(gòu)。

\\

要了解更多有關(guān)集成的信息，Pl?d強(qiáng)烈推薦由Gregor Hophe和Bobby Wolf所著的Enterprise Integration Patterns一書。

\\

查看英文原文：Strategies for Microservices Communication

\\ 《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的微服务通信策略的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。