關(guān)鍵時(shí)刻，第一時(shí)間送達(dá)！
本文選自由特贊CTO黃勇（CSDN獨(dú)家專訪黃勇：Java在未來的很長(zhǎng)一段時(shí)間仍是主流）所著的《架構(gòu)探險(xiǎn)：輕量級(jí)微服務(wù)架構(gòu)（下冊(cè)）》一書，更多關(guān)于此書的介紹和目錄，點(diǎn)擊閱讀原文查看。
一、微服務(wù)將變得輕量級(jí)
架構(gòu)需要由人去設(shè)計(jì)，這些人被稱為架構(gòu)師?；蛟S很多人并未授予架構(gòu)師的頭銜，但自己卻從事著架構(gòu)的工作。我們認(rèn)為，架構(gòu)這項(xiàng)工作永遠(yuǎn)都需要由人去完成，可能短期內(nèi)都無法由機(jī)器來取代。如果我們不理解什么是架構(gòu)，或者對(duì)架構(gòu)師的職責(zé)感到疑惑，那么很難讓架構(gòu)這項(xiàng)工作有效地落地。我們將在本節(jié)重新認(rèn)識(shí)架構(gòu)，并重新定義架構(gòu)師的職責(zé)。此外，架構(gòu)演進(jìn)是一個(gè)曲折的過程，但我們卻不難看出架構(gòu)的發(fā)展規(guī)律，甚至還能推測(cè)出架構(gòu)將來的發(fā)展趨勢(shì)。我們相信，微服務(wù)一定不是架構(gòu)的終點(diǎn)，它或許只是架構(gòu)從重量級(jí)轉(zhuǎn)型為輕量級(jí)的橋梁，我們正是設(shè)計(jì)并建造這座橋梁的工程師。
現(xiàn)在我們從架構(gòu)與架構(gòu)師的角度開始出發(fā)，開啟輕量級(jí)微服務(wù)的架構(gòu)探險(xiǎn)之旅。
1. 架構(gòu)與架構(gòu)師
可能絕大多數(shù)的程序員都想成為一名優(yōu)秀的架構(gòu)師，每天都能從事技術(shù)架構(gòu)的相關(guān)工作，編點(diǎn)框架代碼，畫點(diǎn)架構(gòu)圖，寫點(diǎn)PPT，帥氣地站在講臺(tái)上給程序員們進(jìn)行技術(shù)培訓(xùn)。大家普遍認(rèn)為，架構(gòu)師的代碼比別人寫得少，但是工資卻比別人拿得多，架構(gòu)師是技術(shù)團(tuán)隊(duì)中技術(shù)最牛的人，別人搞不定的技術(shù)問題，在架構(gòu)師眼中都是小菜一碟。
這樣的人真的是架構(gòu)師嗎？
我們認(rèn)為，他們不是架構(gòu)師，而是技術(shù)專家。其實(shí)架構(gòu)師與技術(shù)專家有著本質(zhì)的區(qū)別，從他們所關(guān)注的技術(shù)方向來看，架構(gòu)師更偏向技術(shù)廣度，而技術(shù)專家更偏向技術(shù)深度，如圖1-1所示。
圖1-1 架構(gòu)師與技術(shù)專家的區(qū)別
換句話說，架構(gòu)師需要有較強(qiáng)的綜合能力，他們需要接觸的技術(shù)領(lǐng)域較廣，但他們所掌握的技術(shù)專業(yè)能力卻沒有技術(shù)專家那么深。如果我們想成為一名架構(gòu)師，那么就不應(yīng)該把所有的精力都投入在某個(gè)技術(shù)領(lǐng)域上，而是要學(xué)會(huì)分散自己所關(guān)注的層面，做到在眾多技術(shù)領(lǐng)域上都要有一定的深度。
架構(gòu)師除了需要具備在技術(shù)上所需的“硬技能”，還需要不斷完善自己的“軟技能”，比如溝通、組織、學(xué)習(xí)等技能。有時(shí)候軟技能可能比硬技能更加重要，甚至軟技能還會(huì)影響自己的職業(yè)發(fā)展。如果沒有較好的軟技能，架構(gòu)師將無法將自己所設(shè)計(jì)的架構(gòu)順利地移交到程序員們手中，并指導(dǎo)他們將其真正落地。架構(gòu)師正是通過他們所具備的綜合能力來帶領(lǐng)技術(shù)團(tuán)隊(duì)，解決不斷出現(xiàn)的技術(shù)挑戰(zhàn)。
架構(gòu)師的職責(zé)是什么？
我們的回答是：制定規(guī)范 指導(dǎo)落地。
架構(gòu)師根據(jù)業(yè)務(wù)需求所制定的合理且可落地的技術(shù)規(guī)范，我們將這樣的規(guī)范稱為架構(gòu)。
將架構(gòu)工作做好猶如我們用兩條腿走路一樣，左腿邁出去表示“制定規(guī)范”，右腿跟上來表示“指導(dǎo)落地”，如圖1-2所示。
圖1-2 架構(gòu)師的職責(zé)
如果左腿邁出去，右腿沒跟上來，那不是架構(gòu)師，可能是需要拄拐的人。然而，我們身邊卻有一些這樣的不合格的架構(gòu)師，他們只懂得制定規(guī)范，卻忽略了指導(dǎo)落地。如果架構(gòu)無法落地，那么就無法稱為架構(gòu)了。
此外，還有一些架構(gòu)師認(rèn)為，架構(gòu)只是技術(shù)層面上的問題，自己設(shè)計(jì)的架構(gòu)應(yīng)該用到市面上最為流行的新技術(shù)，比如別人公司在用微服務(wù)，那么自己公司也要用起來。如果將架構(gòu)工作脫離于業(yè)務(wù)需求，我們認(rèn)為這不是做架構(gòu)，而是玩技術(shù)。脫離業(yè)務(wù)來設(shè)計(jì)架構(gòu)是對(duì)架構(gòu)的不尊重。微服務(wù)是一種應(yīng)用系統(tǒng)架構(gòu)，需要架構(gòu)師圍繞業(yè)務(wù)進(jìn)行設(shè)計(jì)。
但是，我們絕不要為了微服務(wù)而去微服務(wù)。
從事微服務(wù)架構(gòu)工作的架構(gòu)師，相比傳統(tǒng)架構(gòu)的架構(gòu)師而言，所要求的技能更加全面。他們不僅僅是系統(tǒng)架構(gòu)師，也是業(yè)務(wù)分析師，他們的責(zé)任重大且挑戰(zhàn)艱巨。
從大的方向來看，微服務(wù)架構(gòu)師需要具備以下基本職責(zé)。
（1）分析業(yè)務(wù)需求并切分微服務(wù)邊界。
（2）定義架構(gòu)規(guī)范與文檔標(biāo)準(zhǔn)。
（3）確保微服務(wù)架構(gòu)順利落地。
（4）改善微服務(wù)架構(gòu)并提高開發(fā)效率。
職責(zé)與挑戰(zhàn)往往是無法分離的，微服務(wù)架構(gòu)師必須面對(duì)并克服這些挑戰(zhàn)。
（1）架構(gòu)需要適應(yīng)不斷變化的業(yè)務(wù)需求。
（2）架構(gòu)具備穩(wěn)定性、擴(kuò)展性、安全性、容錯(cuò)性等。
（3）使技術(shù)團(tuán)隊(duì)深刻理解微服務(wù)思想。
（4）展現(xiàn)微服務(wù)架構(gòu)的價(jià)值。
我們認(rèn)為，傳統(tǒng)架構(gòu)師轉(zhuǎn)型為微服務(wù)架構(gòu)首先需要做到的是深刻理解業(yè)務(wù)，而不是表面上了解需求。業(yè)務(wù)和需求其實(shí)是兩碼事，業(yè)務(wù)的背后反映了客戶的剛需，而需求往往是產(chǎn)品經(jīng)理根據(jù)業(yè)務(wù)剛需所指定的解決方案。作為微服務(wù)架構(gòu)師，我們需要透過需求的表象去理解業(yè)務(wù)的本質(zhì)。其次需要做到的是不斷優(yōu)化架構(gòu)，讓架構(gòu)變得更加簡(jiǎn)單，更加輕量級(jí)。我們要將昨天最好的表現(xiàn)，當(dāng)成今天最低的要求，只有在技術(shù)上不斷要求自己，才能讓架構(gòu)變得更好。
2. 架構(gòu)演進(jìn)過程
話說天下大勢(shì)，分久必合，合久必分，對(duì)于架構(gòu)演進(jìn)過程而言，也符合這個(gè)規(guī)律。
最早的應(yīng)用程序?qū)嶋H上是沒有任何架構(gòu)的，因?yàn)槟菚r(shí)業(yè)務(wù)比較簡(jiǎn)單，沒有架構(gòu)也許是合理的，如圖1-3所示。
圖1-3 沒有架構(gòu)
但隨著業(yè)務(wù)不斷復(fù)雜起來，我們意識(shí)到架構(gòu)可以做到水平分層，比如表現(xiàn)層、邏輯層、數(shù)據(jù)層等，我們可在不同的層上實(shí)現(xiàn)每一層所關(guān)注的內(nèi)容，我們稱其為“關(guān)注點(diǎn)分離”。但此時(shí)的架構(gòu)更像是一塊“鐵板”，每一層的無法進(jìn)行分離，因此我們也將這樣的架構(gòu)稱為“單塊架構(gòu)”，如圖1-4所示。
從此架構(gòu)發(fā)生了更為復(fù)雜的變化，層次結(jié)構(gòu)越來越深，而且不再局限于水平方向上的分層，實(shí)際上越來越多的應(yīng)用程序圍繞著不同的業(yè)務(wù)需求來實(shí)現(xiàn)，此時(shí)出現(xiàn)了“垂直分層架構(gòu)”，每個(gè)垂直應(yīng)用中實(shí)際上都是一個(gè)獨(dú)立的子系統(tǒng)，它們共同組成了整個(gè)應(yīng)用系統(tǒng)。然而，這些子系統(tǒng)一般可以部署在不同的服務(wù)器上，這些服務(wù)器可以分布在不同的地域中，我們也稱其為“分布式架構(gòu)”，如圖1-5所示。
圖1-4 水平分層架構(gòu)（單塊架構(gòu)）
圖1-5 垂直分層架構(gòu)（分布式架構(gòu)）
業(yè)務(wù)并沒有停止發(fā)展的腳步，架構(gòu)的演變也是如此。分布式應(yīng)用之間的調(diào)用越來越多，整個(gè)系統(tǒng)的復(fù)雜度急劇上升，人們希望找到一種途徑來降低分布式應(yīng)用之間的耦合。此時(shí)出現(xiàn)了面向服務(wù)架構(gòu)（SOA），人們希望SOA能成為解決分布式應(yīng)用系統(tǒng)復(fù)雜性的“銀彈”，然而事實(shí)卻事與愿違。應(yīng)用的復(fù)雜性不僅沒有得到解決，反而還讓架構(gòu)變得更加復(fù)雜，同時(shí)也形成了大量的SOA商業(yè)產(chǎn)品，這些現(xiàn)象讓人們更加恐懼SOA，將它視為復(fù)雜和昂貴的代名詞，如圖1-6所示。
隨著互聯(lián)網(wǎng)行業(yè)不斷發(fā)展，用戶對(duì)產(chǎn)品的體驗(yàn)要求越來越高，前端的價(jià)值逐漸被凸顯出來，此時(shí)出現(xiàn)了“前后端分離”的趨勢(shì)，前端工程師專心在界面展現(xiàn)與數(shù)據(jù)渲染上，后端工程師關(guān)注在業(yè)務(wù)邏輯與數(shù)據(jù)結(jié)構(gòu)上，前后端只需通過REST API進(jìn)行交互，工作分工更加明確，開發(fā)效率更加高效，如圖1-7所示。
圖1-6 面向服務(wù)架構(gòu)（SOA）
圖1-7 前后端分離架構(gòu)
似乎很長(zhǎng)時(shí)間都未出現(xiàn)任何技術(shù)能與當(dāng)年的SOA相提并論，除了微服務(wù)架構(gòu)。微服務(wù)的概念在2014年首次被提出以來，近幾年一直是應(yīng)用架構(gòu)領(lǐng)域的核心話題。但人們往往還是容易想到當(dāng)年的SOA，認(rèn)為微服務(wù)與SOA有著相同的目的，只是實(shí)現(xiàn)細(xì)節(jié)不太一樣罷了，如圖1-8所示。
圖1-8 微服務(wù)架構(gòu)
微服務(wù)與SOA到底有何區(qū)別？
我們認(rèn)為，微服務(wù)是SOA的一種落地方案。
SOA是一種面向服務(wù)的架構(gòu)思想，微服務(wù)也同樣推崇這種思想。微服務(wù)是將一個(gè)大型的單塊架構(gòu)，拆分為多個(gè)細(xì)粒度服務(wù)的架構(gòu)。微服務(wù)更加考驗(yàn)我們的是，深入理解業(yè)務(wù)并合理地對(duì)服務(wù)邊界進(jìn)行切分。微服務(wù)的概念相比SOA更容易落地的原因不是概念上的創(chuàng)新，而是技術(shù)上的突破，尤其是容器與自動(dòng)化運(yùn)維技術(shù)的普及與應(yīng)用。
我們始終相信，微服務(wù)并不是架構(gòu)發(fā)展的終點(diǎn)，也許是新架構(gòu)時(shí)代的起點(diǎn)。
3. 微服務(wù)架構(gòu)發(fā)展趨勢(shì)
微服務(wù)架構(gòu)所涉及的范圍相當(dāng)廣泛，我們不妨從多個(gè)角度來推測(cè)微服務(wù)架構(gòu)的發(fā)展趨勢(shì)。
從微服務(wù)開發(fā)角度來看，我們認(rèn)為微服務(wù)的開發(fā)框架將變得更加多樣化。
開發(fā)人員可使用更加適合的開發(fā)框架來完成微服務(wù)業(yè)務(wù)實(shí)現(xiàn)，而不再拘泥于某一種編程語言，只需確保對(duì)外提供統(tǒng)一的API接口方式即可。甚至可將查詢與修改操作相分離，查詢操作可以用一種更加輕量級(jí)的編程語言來實(shí)現(xiàn)，而修改操作會(huì)涉及事務(wù)，一般需要借助開發(fā)框架的事務(wù)特性來保證。
我們堅(jiān)信，微服務(wù)必將堅(jiān)持走輕量級(jí)技術(shù)路線。
究竟什么是輕量級(jí)？
我們認(rèn)為，輕量級(jí)必須包含三個(gè)特征：易用、快速、穩(wěn)定。
我們希望微服務(wù)架構(gòu)中所涉及的技術(shù)都能夠快速上手，運(yùn)行時(shí)不占用過多的系統(tǒng)資源且性能突出，而且能夠長(zhǎng)期穩(wěn)定地運(yùn)行。
從微服務(wù)部署角度來看，我們認(rèn)為微服務(wù)的部署過程將變得更加自動(dòng)化。
部署微服務(wù)不再通過手工的方式去完成，因?yàn)檫@樣既低效又容易出錯(cuò)，我們更加傾向于使用軟件工具將其自動(dòng)完成。要實(shí)現(xiàn)自動(dòng)化部署這個(gè)目標(biāo)，我們往往無法一步到位，最合理的方式是“先讓它跑起來，再讓它跑得快”。也就是說，早期的自動(dòng)化部署方案也許不夠完備，或多或少會(huì)存在一些人工參與的情況，其實(shí)這些都再正常不過了，但我們需要不斷優(yōu)化，努力通過自動(dòng)化技術(shù)來取代重復(fù)性的人工操作。
最后想說的是，自動(dòng)化雖好，但不要為了自動(dòng)化而去自動(dòng)化，或許有些環(huán)節(jié)通過手工處理才是最有效的方式。
二、微服務(wù)架構(gòu)前期準(zhǔn)備
搭建微服務(wù)架構(gòu)絕不是一件輕松的事情，我們不僅要對(duì)微服務(wù)概念有著深刻的理解，還要研究大量的技術(shù)工具，并掌握它們的優(yōu)缺點(diǎn)，最終需要結(jié)合技術(shù)團(tuán)隊(duì)對(duì)技術(shù)的了解程度，選擇最為合適的技術(shù)選型。這些純技術(shù)的技術(shù)工具只是微服務(wù)的基礎(chǔ)設(shè)施，我們還需要在此基礎(chǔ)設(shè)施上圍繞真實(shí)的業(yè)務(wù)場(chǎng)景，對(duì)微服務(wù)邊界進(jìn)行合理地切分。我們將在本節(jié)介紹微服務(wù)的冰山模型，大家將從這座冰山中看到微服務(wù)架構(gòu)的全貌，隨后我們將深入冰山之下的世界，去探索微服務(wù)基礎(chǔ)設(shè)施的八大中心，最后我們還會(huì)介紹一些關(guān)于切分微服務(wù)邊界的原則和技巧。
我們現(xiàn)在就從微服務(wù)冰山模型開始吧，這座冰山似乎比我們想象中的要大很多。
1. 認(rèn)識(shí)微服務(wù)架構(gòu)冰山模型
有些人認(rèn)為，使用了Spring Boot開發(fā)框架就是擁有了微服務(wù)，其實(shí)這樣的認(rèn)識(shí)是不正確的。Spring Boot只是一款微服務(wù)的開發(fā)框架，而且僅能用于Java應(yīng)用程序中，毫無疑問，它只是微服務(wù)的冰山一角。此外，我們建議大家結(jié)合自身的業(yè)務(wù)場(chǎng)景，選擇更為合適的編程語言以及開發(fā)框架來實(shí)現(xiàn)微服務(wù)，而不要拘泥于一種編程語言。
還有一些人認(rèn)為，用上了Docker就進(jìn)入了微服務(wù)時(shí)代，其實(shí)這樣的認(rèn)識(shí)也是不正確的。Docker只是一種封裝微服務(wù)應(yīng)用程序的容器化技術(shù)，它改變了應(yīng)用程序的交付方式，也加速了微服務(wù)架構(gòu)的落地速度。可以肯定地說，如果沒有Docker容器技術(shù)，或許今天我們無法聽到微服務(wù)的概念。
如果將微服務(wù)架構(gòu)中所涉及的技術(shù)棧比喻為一座冰山的話，那么冰山之上最顯而易見的部分就是微服務(wù)的開發(fā)框架與容器技術(shù)了，Spring Boot與Docker都屬于冰山之上的技術(shù)。
冰山之下到底有哪些技術(shù)呢？
我們認(rèn)為冰山之下的技術(shù)是整個(gè)微服務(wù)架構(gòu)的基石，它們構(gòu)成了整個(gè)微服務(wù)架構(gòu)的基礎(chǔ)設(shè)施。比如我們?cè)谏蟽?cè)中學(xué)習(xí)的ZooKeeper服務(wù)注冊(cè)表、Node.js服務(wù)網(wǎng)關(guān)、Jenkins持續(xù)部署系統(tǒng)等，它們都屬于冰山之下的部分。
我們可通過一幅圖來描繪微服務(wù)架構(gòu)這座冰山，如圖1-9所示。
圖1-9 微服務(wù)架構(gòu)冰山模型
由于服務(wù)注冊(cè)表集中管理了微服務(wù)相關(guān)的服務(wù)配置，因此我們也將它稱為“注冊(cè)中心”；由于服務(wù)網(wǎng)關(guān)是前端應(yīng)用程序的唯一入口，因此我們也將其稱為“調(diào)用中心”；同樣，我們也將持續(xù)部署系統(tǒng)稱為“部署中心”。這些中心都匯集在微服務(wù)冰山模型之下，除此之外，還有其他功能的中心，這些中心共同構(gòu)成了微服務(wù)的基礎(chǔ)設(shè)施。
2. 冰山下的微服務(wù)基礎(chǔ)設(shè)施
冰山下的微服務(wù)基礎(chǔ)設(shè)施，實(shí)際包括了八大中心。
（1）注冊(cè)中心：用于注冊(cè)微服務(wù)相關(guān)配置信息的中心，我們選用ZooKeeper實(shí)現(xiàn)。
（2）調(diào)用中心：用于提供給前端調(diào)用的統(tǒng)一入口，我們選用Node.js實(shí)現(xiàn)。
（3）部署中心：用于編譯并打包微服務(wù)源碼并將其部署到Docker引擎中，我們選用Jenkins實(shí)現(xiàn)。
（4）日志中心：用于收集并管理微服務(wù)應(yīng)用程序中產(chǎn)生的日志，第2章中將詳細(xì)介紹。
（5）監(jiān)控中心：用于監(jiān)控微服務(wù)的實(shí)時(shí)運(yùn)行狀況，第3章中將詳細(xì)介紹。
（6）追蹤中心：用于最終微服務(wù)的調(diào)用軌跡，第3章中將詳細(xì)介紹。
（7）消息中心：用于解耦微服務(wù)之間的調(diào)用關(guān)系，第5章中將詳細(xì)介紹。
（8）配置中心：用于管理微服務(wù)應(yīng)用程序所需的配置參數(shù)，第7章中將詳細(xì)介紹。
也許大家看到以上八大中心后會(huì)產(chǎn)生一些疑惑：很多人說微服務(wù)是去中心化的，為何我們還要提供這些中心呢？
我們認(rèn)為，中心分為兩類：一類是含有業(yè)務(wù)意義的中心；另一類是不含業(yè)務(wù)意義的中心（只是技術(shù)層面的中心）。
在微服務(wù)架構(gòu)中我們應(yīng)該去除的是含有業(yè)務(wù)意義的中心，而不是去除技術(shù)層面上的廣義中心。比如，我們所設(shè)計(jì)的調(diào)用中心內(nèi)部是不可能帶有任何業(yè)務(wù)流程的，它只是一個(gè)純技術(shù)層面的框架。對(duì)于其他中心也是如此，絕對(duì)不含有任何的業(yè)務(wù)，否則我們就應(yīng)該將其去除。
3. 根據(jù)業(yè)務(wù)切分微服務(wù)邊界
凡是學(xué)習(xí)過微服務(wù)的人都知道，我們需要根據(jù)業(yè)務(wù)來切分微服務(wù)邊界。道理可能大家都懂，但或許仍然不知道應(yīng)該怎么去做。例如，切分微服務(wù)邊界有哪些關(guān)鍵性步驟，以及包含哪些重要性原則？
經(jīng)過大量的微服務(wù)實(shí)踐，我們總結(jié)了以下五個(gè)步驟，可幫助大家有效地切分微服務(wù)邊界。
第一步：梳理業(yè)務(wù)流程。
在切分微服務(wù)之前，我們要做的第一件事情就是梳理業(yè)務(wù)流程。不妨找業(yè)務(wù)專家咨詢，通過與他們溝通從而了解真實(shí)的業(yè)務(wù)流程，并將其繪制成流程圖。對(duì)于過于復(fù)雜的業(yè)務(wù)流程，我們也可單獨(dú)繪制流程圖，并增加相關(guān)的流程說明。當(dāng)然也能提供相應(yīng)的狀態(tài)圖，用于說明業(yè)務(wù)流程中所涉及狀態(tài)的變化過程。
花再多時(shí)間去分析業(yè)務(wù)流程都不過分，現(xiàn)在所花的每一分鐘都是相當(dāng)值得的。
第二步：抽取公共服務(wù)。
在業(yè)務(wù)流程中與業(yè)務(wù)不太相關(guān)的部分，我們可考慮將其剝離出來，并形成公共服務(wù)。例如，郵件發(fā)送、文件上傳、其他第三方接口等。每種公共服務(wù)都對(duì)應(yīng)一個(gè)微服務(wù)，每個(gè)微服務(wù)都有相關(guān)API，每個(gè)API都有自己的輸入與輸出。這些API一定要形成文檔，以便其他服務(wù)調(diào)用。
一般情況下，抽取的公共服務(wù)都不太會(huì)變化，我們一定要想辦法將不變的東西從可變的世界中抽取出來。
第三步：定義業(yè)務(wù)服務(wù)。
當(dāng)公共服務(wù)抽取完畢后，業(yè)務(wù)流程中剩下來的部分就是業(yè)務(wù)服務(wù)了。建議剛開始實(shí)施微服務(wù)時(shí)，不要將業(yè)務(wù)服務(wù)的邊界切得太細(xì)，可以考慮先“大切幾塊”，但需要確保每個(gè)服務(wù)之間盡量不要有依賴關(guān)系。換句話說，每個(gè)服務(wù)都是獨(dú)立的，雖然此時(shí)服務(wù)的塊頭可能比較大。
我們先確保這些大塊頭服務(wù)可以運(yùn)行在微服務(wù)基礎(chǔ)設(shè)施上，再不斷將它們進(jìn)行細(xì)化，拆解為更小的服務(wù)。
第四步：設(shè)計(jì)數(shù)據(jù)模型。
深入到每個(gè)業(yè)務(wù)服務(wù)中，我們首先要做的是定義它底層所涉及的數(shù)據(jù)模型，也稱為“領(lǐng)域模型”。此時(shí)會(huì)涉及數(shù)據(jù)庫(kù)表結(jié)構(gòu)設(shè)計(jì)，以及數(shù)據(jù)模型與關(guān)系設(shè)計(jì)。在數(shù)據(jù)層面上的設(shè)計(jì)是至關(guān)重要的，如果該部分設(shè)計(jì)得不到位，將增加后期實(shí)現(xiàn)微服務(wù)的成本。
數(shù)據(jù)模型的設(shè)計(jì)同樣也需要進(jìn)行文檔化，這些文檔將指導(dǎo)后端工程師順利地完成微服務(wù)實(shí)現(xiàn)。
第五步：定義服務(wù)接口。
底層的數(shù)據(jù)模型設(shè)計(jì)完畢后，我們將視角轉(zhuǎn)換到頂層的服務(wù)接口上。服務(wù)接口實(shí)際上就是一組API，這些API需做到職責(zé)單一，而且需要通過名稱就能識(shí)別出它的業(yè)務(wù)含義。建議確保每個(gè)API的命名是全局唯一的，也建議每個(gè)API都有各自的版本號(hào)，版本號(hào)可以用自增長(zhǎng)的方式來體現(xiàn)。
服務(wù)接口也需要進(jìn)行文檔化，這些文檔一般由后端工程師編寫，并提供給前端與測(cè)試工程師閱讀。
三、輕量級(jí)微服務(wù)架構(gòu)圖
作為一名微服務(wù)架構(gòu)師，我們不僅需要深入理解業(yè)務(wù)，并能準(zhǔn)確地劃分服務(wù)邊界，而且還需要深入理解微服務(wù)，并能合理地選擇技術(shù)選型。我們認(rèn)為，微服務(wù)架構(gòu)實(shí)際上分為兩大部分，其中一部分對(duì)應(yīng)部署階段，另一部分對(duì)應(yīng)運(yùn)行階段。這兩部分包含了大量的技術(shù)工具，我們需要結(jié)合多方面因素來考慮，選擇最為合適的技術(shù)選型來搭建微服務(wù)架構(gòu)，并確保它能保持輕量級(jí)。
本節(jié)將著眼于微服務(wù)的部署與運(yùn)行兩大階段，通過圖文方式來描述輕量級(jí)微服務(wù)架構(gòu)。
1. 輕量級(jí)微服務(wù)部署架構(gòu)
當(dāng)開發(fā)人員完成了微服務(wù)的細(xì)節(jié)實(shí)現(xiàn)后，首先要做的是確保自己所寫代碼的可用性，他們往往會(huì)借助單元測(cè)試工具來保證這一環(huán)節(jié)不出問題。當(dāng)他們將源碼提交并推送到代碼倉(cāng)庫(kù)后，此時(shí)部署中心將從代碼倉(cāng)庫(kù)中獲取源碼，并執(zhí)行編譯與打包操作。
不僅如此，部署中心還需從配置中心獲取對(duì)應(yīng)運(yùn)行環(huán)境的配置參數(shù)，并生成相應(yīng)的配置文件，并將這些配置文件與應(yīng)用程序一同復(fù)制到Docker鏡像中，最后還需將此鏡像上傳到鏡像倉(cāng)庫(kù)，以便后續(xù)可從鏡像倉(cāng)庫(kù)中下載指定的鏡像，從而運(yùn)行相應(yīng)的Docker容器。
此外，部署中心還可掃描源碼并自動(dòng)生成API文檔站點(diǎn)，以便其他技術(shù)人員可隨時(shí)從文檔站點(diǎn)中查看最新部署服務(wù)所包含的API文檔。當(dāng)然，我們還可以對(duì)所需完成的微服務(wù)僅提供簡(jiǎn)單的代碼實(shí)現(xiàn)，這樣就能將微服務(wù)文檔的輸出時(shí)間盡可能提前，以便其他技術(shù)人員能夠更早地了解到微服務(wù)的相關(guān)API信息，隨后再去完成更加細(xì)節(jié)的代碼實(shí)現(xiàn)，這是我們推薦的工作方法。
當(dāng)Docker鏡像上傳到鏡像倉(cāng)庫(kù)后，部署中心可在不同的運(yùn)行環(huán)境下根據(jù)特定的鏡像來啟動(dòng)相應(yīng)的Docker容器。為了便于描述，我們將該容器稱為“服務(wù)容器”，它包含了承載微服務(wù)的應(yīng)用程序及其配置文件。
當(dāng)服務(wù)容器啟動(dòng)后，會(huì)自動(dòng)將其配置信息寫入注冊(cè)中心，與此同時(shí)，部署中心也會(huì)連接到注冊(cè)中心，并設(shè)置服務(wù)的版本號(hào)，以便于在后續(xù)調(diào)用服務(wù)時(shí)可根據(jù)版本號(hào)來識(shí)別當(dāng)前可用的服務(wù)。
我們可將以上過程繪制為一幅架構(gòu)圖，如圖1-10所示。
圖1-10 輕量級(jí)微服務(wù)部署架構(gòu)
可見，在微服務(wù)部署階段中，部署中心是其中的主角，它支配其他組件，使服務(wù)可以成功部署，我們需要確保它的穩(wěn)定性。
2. 輕量級(jí)微服務(wù)運(yùn)行架構(gòu)
當(dāng)用戶通過瀏覽器或移動(dòng)端訪問應(yīng)用系統(tǒng)時(shí)，請(qǐng)求首先將進(jìn)入服務(wù)網(wǎng)關(guān)，因?yàn)樗撬姓?qǐng)求調(diào)用的中心，我們也將其稱為“調(diào)用中心”。它雖然是不帶任何業(yè)務(wù)的中心，但我們需要確保它所做的事情足夠少，讓它不會(huì)成為整個(gè)應(yīng)用系統(tǒng)的調(diào)用瓶頸。
隨后調(diào)用中心將連接注冊(cè)中心，并通過服務(wù)名稱從注冊(cè)中心中獲取服務(wù)所在的IP地址與端口號(hào)（即服務(wù)地址），該過程稱為“服務(wù)發(fā)現(xiàn)”，進(jìn)而調(diào)用中心可根據(jù)服務(wù)地址以反向代理的方式來調(diào)用具體的服務(wù)容器，該過程稱為“服務(wù)調(diào)用”。
在服務(wù)容器中可能會(huì)觸發(fā)一些事件，這些事件將以消息的方式寫入消息中心，以便其他服務(wù)可監(jiān)聽消息中心并從中獲取相應(yīng)的消息。該方案可解決服務(wù)之間的耦合問題，同時(shí)能將同步調(diào)用轉(zhuǎn)為異步調(diào)用，提高整個(gè)應(yīng)用系統(tǒng)的吞吐率。
在服務(wù)容器運(yùn)行時(shí)會(huì)產(chǎn)生大量的日志，我們可將這些日志統(tǒng)一寫入日志中心，并能在日志中心所提供的控制臺(tái)上查詢具體的日志信息。此外，日志中心也能幫助我們快速地定位并分析系統(tǒng)出現(xiàn)的異常狀況。
為了觀察服務(wù)容器是否運(yùn)行正常，我們可借助監(jiān)控中心所輸出的圖形化數(shù)據(jù)來判斷。監(jiān)控中心將不斷地收集服務(wù)容器中的運(yùn)行狀態(tài)，包括CPU、內(nèi)存、硬盤、網(wǎng)絡(luò)，以及應(yīng)用程序的JVM內(nèi)存使用情況。
由于微服務(wù)很難切得干凈，服務(wù)之間難免會(huì)出現(xiàn)少量的調(diào)用關(guān)系，我們可將每次調(diào)用所產(chǎn)生的相關(guān)信息寫入追蹤中心，并通過追蹤中心提供的圖形化界面來查看服務(wù)之間的調(diào)用軌跡以及所產(chǎn)生的調(diào)用延時(shí)，從而可分析出服務(wù)調(diào)用所產(chǎn)生的性能瓶頸。
我們可將以上過程繪制為一幅架構(gòu)圖，如圖1-11所示。
圖1-11 輕量級(jí)微服務(wù)運(yùn)行架構(gòu)
可見，在微服務(wù)運(yùn)行階段中，調(diào)用中心是其中的主角，注冊(cè)中心作為它的數(shù)據(jù)來源，服務(wù)容器作為它的調(diào)用目標(biāo)，它需要具備良好的高性能與高可用等特性。
3. 輕量級(jí)微服務(wù)全局架構(gòu)
我們用一張圖將輕量級(jí)微服務(wù)的部署架構(gòu)與運(yùn)行架構(gòu)進(jìn)行整合，它就是輕量級(jí)微服務(wù)架構(gòu)的全貌，如圖1-12所示。
圖1-12 輕量級(jí)微服務(wù)全局架構(gòu)
圖1-12所示的架構(gòu)圖中包括12個(gè)組件，其中的代碼倉(cāng)庫(kù)、部署中心、注冊(cè)中心、鏡像倉(cāng)庫(kù)、調(diào)用中心、服務(wù)容器這6個(gè)組件已在上冊(cè)中進(jìn)行描述，剩下的配置中心、文檔站點(diǎn)、消息中心、日志中心、監(jiān)控中心、追蹤中心這6個(gè)組件將在下冊(cè)后續(xù)章節(jié)中深入探索。
四、總結(jié)
本章從宏觀上描述了輕量級(jí)微服務(wù)架構(gòu)，為后續(xù)探險(xiǎn)歷程提供了明確的藍(lán)圖。首先我們從架構(gòu)與架構(gòu)師開始講起，簡(jiǎn)單回顧了架構(gòu)演進(jìn)的過程與微服務(wù)的發(fā)展趨勢(shì)，我們認(rèn)為，微服務(wù)的出現(xiàn)是必然的，而且它將朝著輕量級(jí)方向發(fā)展。隨后我們探討了在搭建微服務(wù)架構(gòu)之前需要準(zhǔn)備的工作，也認(rèn)識(shí)了微服務(wù)架構(gòu)的“冰山模型”，本書將重點(diǎn)集中在冰山之下的微服務(wù)基礎(chǔ)設(shè)施中，此外還介紹了切分微服務(wù)邊界的方法和技巧，我們認(rèn)為，合理地切分微服務(wù)邊界是微服務(wù)架構(gòu)師的職責(zé)之一。最后我們從部署與運(yùn)行兩個(gè)角度來觀察微服務(wù)架構(gòu)，并以一幅架構(gòu)全景圖來結(jié)束本章，隨后的章節(jié)將圍繞這張架構(gòu)圖的相關(guān)部分進(jìn)行展開，我們會(huì)選擇最為合適的技術(shù)選型來搭建這款輕量級(jí)微服務(wù)架構(gòu)。
聯(lián)系客服
