1. 微服務(wù)拆分的10條戒律

        共 4193字,需瀏覽 9分鐘

         ·

        2021-04-02 16:00

        須彌零一

        微服務(wù)拆分10條戒律

        當(dāng)下微服務(wù)是真的火?。≌媸歉杏X(jué)現(xiàn)在在IT圈混的說(shuō)自己不懂微服務(wù)都OUT了。放眼當(dāng)前的大環(huán)境,大到各種大大小小的廠商產(chǎn)品介紹,小到漫天亂飛的招聘信息,微服務(wù)這個(gè)詞總能在你的眼前飄來(lái)飄去。
        說(shuō)真的,微服務(wù)這個(gè)詞真是讓人又愛(ài)又恨。愛(ài)的是凡是打上了微服務(wù)架構(gòu)的標(biāo)簽,不管內(nèi)部構(gòu)架如何,產(chǎn)品立馬讓人覺(jué)得高大上了,逼格更高了(潛臺(tái)詞:能賣個(gè)好價(jià)錢)。然而讓人恨的是,讓我們架構(gòu)師自己捫心自問(wèn),我們的產(chǎn)品當(dāng)前做微服務(wù)架構(gòu)是最優(yōu)的產(chǎn)品架構(gòu)嗎?這其中的答案可能每位架構(gòu)師都有自己的答案,或者也各自有各自的無(wú)奈。
        好了,這個(gè)問(wèn)題就此打住。既然我們的產(chǎn)品導(dǎo)向是要做微服務(wù)架構(gòu)。那么,基于我們的產(chǎn)品應(yīng)該如何來(lái)拆分呢?下面就和大家討論交流一下。

        什么是微服務(wù)

        微服務(wù)(英語(yǔ):Microservices)是一種軟件架構(gòu)風(fēng)格,它是以專注于單一責(zé)任與功能的小型功能區(qū)塊 (Small Building Blocks) 為基礎(chǔ),利用模塊化的方式組合出復(fù)雜的大型應(yīng)用程序,各功能區(qū)塊使用與語(yǔ)言無(wú)關(guān) (Language-Independent/Language agnostic)的API集相互通信。微服務(wù)是一種以業(yè)務(wù)功能為主的服務(wù)設(shè)計(jì)概念,每一個(gè)服務(wù)都具有自主運(yùn)行的業(yè)務(wù)功能,對(duì)外開(kāi)放不受語(yǔ)言限制的 API (最常用的是 HTTP),應(yīng)用程序則是由一個(gè)或多個(gè)微服務(wù)組成。

        微服務(wù)是對(duì)比于單體應(yīng)用來(lái)講的。單體應(yīng)用表示一個(gè)應(yīng)用程序內(nèi)包含了所有需要的業(yè)務(wù)功能,并且使用比如C/S架構(gòu)(Client/Server)或是多層次架構(gòu)(N-tier)實(shí)現(xiàn)。雖然它也是能以分布式應(yīng)用程序來(lái)實(shí)現(xiàn),但是在單體式應(yīng)用內(nèi),每一個(gè)業(yè)務(wù)功能是不可分割的。若要對(duì)單體式應(yīng)用進(jìn)行擴(kuò)展則必須將整個(gè)應(yīng)用程序都放到新的運(yùn)算資源(如:虛擬機(jī))內(nèi),但事實(shí)上應(yīng)用程序中最耗費(fèi)資源、最需要運(yùn)算資源的僅有某個(gè)業(yè)務(wù)部分(例如跑分析報(bào)表或是數(shù)學(xué)算法分析),但因?yàn)閱误w式應(yīng)用無(wú)法分割該部分,因此無(wú)形中會(huì)有大量的資源浪費(fèi)的現(xiàn)象。

        微服務(wù)運(yùn)用了以業(yè)務(wù)功能為關(guān)注點(diǎn)的設(shè)計(jì)理念,應(yīng)用程序在設(shè)計(jì)時(shí)就能先以業(yè)務(wù)功能或流程設(shè)計(jì)先行分割,將各個(gè)業(yè)務(wù)功能都獨(dú)立實(shí)現(xiàn)成一個(gè)能自主運(yùn)行的個(gè)體服務(wù),然后再利用相同的協(xié)議將所有應(yīng)用程序需要的服務(wù)都組合起來(lái),形成一個(gè)應(yīng)用程序。若需要針對(duì)特定業(yè)務(wù)功能進(jìn)行擴(kuò)展時(shí),只要對(duì)該業(yè)務(wù)功能的服務(wù)進(jìn)行擴(kuò)展就好,不需要整個(gè)應(yīng)用程序都擴(kuò)展。同時(shí),由于微服務(wù)是以業(yè)務(wù)功能導(dǎo)向的實(shí)現(xiàn),因此一個(gè)微服務(wù)不會(huì)受到其他應(yīng)用程序的干擾,微服務(wù)的管理員可以視運(yùn)算資源的需要來(lái)配置微服務(wù)到不同的運(yùn)算資源內(nèi),或是部署新的運(yùn)算資源并將它配置進(jìn)去。
        總結(jié)一下,簡(jiǎn)單的來(lái)說(shuō)微服務(wù)就是以業(yè)務(wù)為導(dǎo)向,將原有的單體應(yīng)用拆分成多個(gè)服務(wù)單元。每個(gè)單元之間互不影響其內(nèi)部狀態(tài),并通過(guò)共同認(rèn)可的協(xié)議進(jìn)行通信的架構(gòu)設(shè)計(jì)。下面我們來(lái)討論一下如何將一個(gè)單體服務(wù)拆分成多個(gè)業(yè)務(wù)單元。

        微服務(wù)拆分的10條戒律

        1.用有限的上下文和普適語(yǔ)言來(lái)審視您的業(yè)務(wù)領(lǐng)域:

        在進(jìn)行分解之前,首先要做的是縮小產(chǎn)品所有者與開(kāi)發(fā)人員之間的理解差異。一般產(chǎn)品所有者可能不了解技術(shù)術(shù)語(yǔ),技術(shù)團(tuán)隊(duì)可能不了解術(shù)語(yǔ)在業(yè)務(wù)和業(yè)務(wù)解釋方面的重要性。他們就像一個(gè)葡萄牙人用葡萄牙語(yǔ)和一位說(shuō)英語(yǔ)的美國(guó)人交談:兩人之間沒(méi)有人能理解對(duì)話的內(nèi)容。因此,為了消除這些認(rèn)知上的差距,我們需要采取以下步驟:

        1.與產(chǎn)品所有者進(jìn)行討論:“業(yè)務(wù)目標(biāo)是什么?”、“特定功能中的參與者是誰(shuí)?”、“他們?cè)诙x功能時(shí)使用了哪些術(shù)語(yǔ)?”。在這些每個(gè)步驟上,都要提出更多問(wèn)題,直到您弄清楚沖突的術(shù)語(yǔ)是什么為止,例如“訂單上下文客戶”與“基礎(chǔ)結(jié)構(gòu)支持上下文客戶”是不同的。2.一旦理解了沖突的術(shù)語(yǔ)并結(jié)合了相關(guān)功能,請(qǐng)制定一個(gè)上下文,以便在每個(gè)上下文中的每個(gè)域名的實(shí)體名稱都是清晰的。3.為每種情況定義一種通用語(yǔ)言,以便業(yè)務(wù)團(tuán)隊(duì)和技術(shù)團(tuán)隊(duì)在交流時(shí)可以使用一種通用語(yǔ)言進(jìn)行溝通交流。4.從一個(gè)粗粒度的有界上下文開(kāi)始。如果以后有令人信服的理由進(jìn)行劃分,則劃分有界上下文。如果有商業(yè)原因,我建議不要這樣做。

        2.確定核心領(lǐng)域并應(yīng)用創(chuàng)新的點(diǎn)子:

        核心域是為您的業(yè)務(wù)帶來(lái)收益的領(lǐng)域。就在線購(gòu)物而言,購(gòu)物車模塊是核心領(lǐng)域,它為從企業(yè)到消費(fèi)者的買賣(B2C)平臺(tái)提供了核心功能。了解您的核心模塊,并思考如何改進(jìn)這些競(jìng)爭(zhēng)對(duì)手沒(méi)有的模塊。任何自動(dòng)化或創(chuàng)新都會(huì)增加優(yōu)勢(shì)并增加您的收入,因此請(qǐng)注意:應(yīng)該在核心領(lǐng)域進(jìn)行研發(fā)和投資,以保持競(jìng)爭(zhēng)優(yōu)勢(shì)。

        3.對(duì)通用域進(jìn)行成本優(yōu)化:

        通用域就是該領(lǐng)域中每個(gè)企業(yè)所共有的領(lǐng)域。對(duì)于這些領(lǐng)域,市場(chǎng)上不同的第三方廠商已經(jīng)提供了不同的、相對(duì)成熟的商業(yè)化解決方案。比如您產(chǎn)品中的通知模塊或廣告活動(dòng)模塊。所以最好的策略是不要花任何錢在內(nèi)部項(xiàng)目上創(chuàng)建該模塊來(lái)重新發(fā)明輪子,除非您有一些令人信服的理由。一般情況下以便宜的價(jià)格采用第三方解決方案是比較好的選擇。

        4.考慮支持領(lǐng)域:

        核心域需要支持域的幫助來(lái)豐富自身,并且在某些情況下,支持域也是可以帶來(lái)收益的,并且將來(lái)有可能孵化(轉(zhuǎn)變)成為核心域。因此,重要的是要思考并做出合適的決定:在支持領(lǐng)域進(jìn)行投資,以便它可以產(chǎn)生收入。比如,在購(gòu)物車域中,庫(kù)存管理是支持領(lǐng)域,但投資研發(fā)-識(shí)別客戶訂單最近庫(kù)存位置的算法,對(duì)降低運(yùn)輸成本也很重要。

        5.引入反腐層(Anti-Corruption Layer):

        反腐層(Anti-corruption layer,簡(jiǎn)稱 ACL)介于新應(yīng)用和舊應(yīng)用之間,用于確保新應(yīng)用的設(shè)計(jì)不受老應(yīng)用的限制。是一種在不同應(yīng)用間轉(zhuǎn)換的機(jī)制。

        創(chuàng)建一個(gè)反腐層,以根據(jù)客戶端自己的域模型為客戶端提供功能。該層幾乎不需要對(duì)其進(jìn)行任何修改就可以通過(guò)其現(xiàn)有的接口與另一個(gè)系統(tǒng)進(jìn)行通信。因此,反腐層隔離不僅是為了保護(hù)你的系統(tǒng)免受異常代碼的侵害,還在于解耦不同的域并確保它們?cè)趯?lái)保持解耦的狀態(tài)。
        反腐層是將一個(gè)域映射到另一個(gè)域,這樣使用第二個(gè)域的服務(wù)就不必被第一個(gè)域的概念“破壞”。
        實(shí)際上,我們經(jīng)常遇到基于大型機(jī)或任何其他語(yǔ)言構(gòu)建的舊系統(tǒng)。我們無(wú)法拆分該系統(tǒng),但是還需要使用舊應(yīng)用的數(shù)據(jù)。因此,在舊應(yīng)用和微服務(wù)通信之間創(chuàng)建反腐層會(huì)是一個(gè)好主意。
        另外,我們還需要考慮到通用領(lǐng)域。因?yàn)樗麄兪遣皇荛_(kāi)發(fā)團(tuán)隊(duì)控制的任何外部系統(tǒng)(第三方系統(tǒng)) ,因此也需要引入一個(gè)反腐層,該層將微服務(wù)與外部AP隔離開(kāi)來(lái),充當(dāng)微服務(wù)和第三方之間的翻譯者。并且還有一個(gè)用途是,它還可以幫助你在將來(lái)接入其他的任何第三方庫(kù)(服務(wù))。

        6.識(shí)別數(shù)據(jù)通信模式:

        一旦已經(jīng)基于功能拆分了微服務(wù),并且核心服務(wù)也封裝了它們自己的數(shù)據(jù)庫(kù)/持久層。那么接下來(lái)我們要考慮的問(wèn)題是,您的UI視圖/組件之間是如何進(jìn)行通信的。是異步?還是同步?例如,對(duì)于一些系統(tǒng),用戶可以執(zhí)行部分功能并創(chuàng)建中間狀態(tài),另一個(gè)系統(tǒng)對(duì)中間狀態(tài)采取措施并回調(diào)或通知用戶。

        7.引入事件驅(qū)動(dòng)架構(gòu)(EDA):

        在實(shí)時(shí)應(yīng)用程序中,您的業(yè)務(wù)案例可能具有復(fù)雜的工作流,并且根據(jù)數(shù)據(jù)的狀態(tài)(基于狀態(tài)變化)在工作流上具有許多分支。每個(gè)工作流程分支都可能采取不同的策略。因此,如果您考慮通過(guò)Rest API公開(kāi)所有內(nèi)容,那么你將會(huì)看到這些API創(chuàng)建出了一個(gè)非常復(fù)雜的通信網(wǎng)絡(luò)。
        因此,我們需要一個(gè)干凈整潔的架構(gòu),其中每個(gè)微服務(wù)都可以獨(dú)立運(yùn)行而不會(huì)產(chǎn)生耦合。這里事件驅(qū)動(dòng)的架構(gòu)將會(huì)起著至關(guān)重要的作用,每個(gè)事件都包裹著狀態(tài)的變化,并且微服務(wù)的設(shè)計(jì)遵循發(fā)布訂閱(pub/sub)模型。因此一個(gè)微服務(wù)會(huì)發(fā)布以事件的形式包裝的數(shù)據(jù),其他微服務(wù)會(huì)偵聽(tīng)該事件。由于事件是不可變的,因此它也保存了實(shí)體或聚合器的歷史記錄。

        8.使API簡(jiǎn)潔明了

        在微服務(wù)中發(fā)布API時(shí),請(qǐng)確保你的API不會(huì)將內(nèi)部狀態(tài)發(fā)布出去。發(fā)布API是一種使其他服務(wù)可以獲取足夠的信息以繼續(xù)其流程的方式,因此要慮封裝和網(wǎng)絡(luò)調(diào)用,不應(yīng)多次返回以獲取派生信息。還要考慮事件,應(yīng)該發(fā)布哪些事件以及哪些事件必須保留在內(nèi)部。也許你可以發(fā)布一個(gè)粗粒度事件,而不是發(fā)布一個(gè)個(gè)內(nèi)部的小事件。
        例如,你有地址更改事件和個(gè)人信息更改事件。最好是發(fā)布一個(gè)名為CustomerUpdateEvent的粗粒度事件,而不是提供兩個(gè)獨(dú)立的事件。

        9.將相關(guān)的微服務(wù)合并為更大的服務(wù):

        拆分之后,當(dāng)需要添加或更新功能時(shí),你會(huì)遇到一些微服務(wù)總是一起變化的情況。這時(shí)候,你應(yīng)該知道你已經(jīng)以錯(cuò)誤的方式拆分了它。它們一定不能被隔離到一個(gè)小型服務(wù)中,它們是同一邏輯單元的一部分。因此,將它們合并為一個(gè)服務(wù)是明智的,這將減少不必要的網(wǎng)絡(luò)通信開(kāi)銷,和降低模塊間的復(fù)雜度。

        10.引入無(wú)縫開(kāi)發(fā)支持工具:

        微服務(wù)不是免費(fèi)的午餐。如果你采用微服務(wù),那么首先要做好準(zhǔn)備,因?yàn)槲⒎?wù)是分布式的,因此要投資一些軟件工具,以此來(lái)擴(kuò)展彈性和提高可用性,并縮短產(chǎn)品投產(chǎn)時(shí)間,幫助盡早發(fā)現(xiàn)故障等。
        因此,請(qǐng)?jiān)贑I/CD流水線上投入一定的資金資源。采用云基礎(chǔ)架構(gòu),使用跟蹤工具,使用日志聚合器來(lái)搜索日志,使用混沌工程測(cè)試你的系統(tǒng),等等。

        最后

        以上就是10點(diǎn)我們要做微服務(wù)拆分時(shí)的一點(diǎn)想法和建議,至于對(duì)錯(cuò),本人也沒(méi)有一個(gè)肯定的答案。但是,盲目跟進(jìn)微服務(wù)架構(gòu),個(gè)人覺(jué)得其實(shí)不是一個(gè)很好的現(xiàn)象。
        一個(gè)產(chǎn)品誕生的起因本身就是為了解決一系列實(shí)際的業(yè)務(wù)問(wèn)題,結(jié)合業(yè)務(wù)實(shí)際來(lái)構(gòu)建一個(gè)合理的技術(shù)架構(gòu)才是一個(gè)最好的選擇。當(dāng)然,有些朋友可能會(huì)覺(jué)得微服務(wù)架構(gòu)有那么多單體架構(gòu)沒(méi)有的有點(diǎn),我可以提前布局以應(yīng)對(duì)業(yè)務(wù)量上去之后的系統(tǒng)瓶頸。但是,每個(gè)產(chǎn)品都有自己的生命周期,每個(gè)產(chǎn)品也都有自己的業(yè)務(wù)特點(diǎn)。另外更要命的是,誰(shuí)也無(wú)法預(yù)測(cè)未來(lái),需求也是在不斷的快速變化,有時(shí)候提前布局到的東西可能永遠(yuǎn)也用不上,這就白白浪費(fèi)了前期的投入,反而得不償失。您覺(jué)得呢?當(dāng)然,如果有其他外力因素不能左右那就另說(shuō)了。

        歡迎留言討論。

        ---- END ----

        譯文連接:

            https://dzone.com/articles/10-commandments-on-microservice-decomposition



        歡迎關(guān)注我的公眾號(hào)“須彌零一”,原創(chuàng)技術(shù)文章第一時(shí)間推送。


        瀏覽 29
        點(diǎn)贊
        評(píng)論
        收藏
        分享

        手機(jī)掃一掃分享

        分享
        舉報(bào)
        評(píng)論
        圖片
        表情
        推薦
        點(diǎn)贊
        評(píng)論
        收藏
        分享

        手機(jī)掃一掃分享

        分享
        舉報(bào)
          
          

            1. 国产一区二区三区色情影视 | 国产欧美日韩综合 | 欧美美女爱爱视频 | 插插插啊啊啊 | 双腿大开孕妇play高h多人 |