楊宸 田晴 金新穎

摘 要：在軟件開發(fā)的過程中，架構(gòu)是難解的問題。開發(fā)一個(gè)軟件就好比蓋造樓房，一個(gè)簡(jiǎn)單的房屋或許不需要架構(gòu)圖來規(guī)范它的蓋造，但是一座摩天大樓必然需要詳細(xì)的架構(gòu)分析圖來規(guī)范包工隊(duì)伍的行為，開發(fā)一款高質(zhì)量的軟件也不例外。 下面來圍繞兩個(gè)我們認(rèn)為需要解決的問題來出發(fā)，介紹微服務(wù)架構(gòu)在當(dāng)今互聯(lián)網(wǎng)環(huán)境實(shí)現(xiàn)的必要性，以及在當(dāng)今互聯(lián)網(wǎng)環(huán)境的缺點(diǎn)的解決方案。

關(guān)鍵詞：?jiǎn)误w架構(gòu);垂直拆分架構(gòu);分布式架構(gòu);面向服務(wù)架構(gòu);微服務(wù)架構(gòu);REST風(fēng)格

一、解決高并發(fā)，高可用問題

1.1問題簡(jiǎn)介

當(dāng)今世界網(wǎng)民已經(jīng)達(dá)到40億，早已不是幾臺(tái)服務(wù)器就能承擔(dān)的，根據(jù)二八原則80%的用戶，在20%的時(shí)間點(diǎn)訪問網(wǎng)站，如果它的服務(wù)器解決不了并發(fā)壓力，就會(huì)降低用戶體驗(yàn)。

1.2研究分析

在此問題上，有人提出了對(duì)單體架構(gòu)的水平擴(kuò)充。但是，根據(jù)二八原則80%的業(yè)務(wù)功能集中在20%的代碼，代碼的冗余會(huì)造成資源的浪費(fèi)。那該怎么辦呢？

第二個(gè)架構(gòu)垂直拆分架構(gòu)閃亮登場(chǎng)，它依據(jù)業(yè)務(wù)功能把我們的項(xiàng)目拆分成一個(gè)又一個(gè)的子項(xiàng)目，從而在解決并發(fā)問題上根據(jù)我們的業(yè)務(wù)功能模塊進(jìn)行擴(kuò)充，節(jié)省了資源。但是它的弊端在長(zhǎng)期開發(fā)中也出現(xiàn)了，他的模塊之間是沒有通信的。舉個(gè)例子：一個(gè)主要的業(yè)務(wù)模塊依賴于一個(gè)并發(fā)量較低的權(quán)限模塊，業(yè)務(wù)模塊不得不編寫權(quán)限模塊的代碼，從而浪費(fèi)了服務(wù)器的資源。

之前有Java程序員嘗試過用Java的RMI（遠(yuǎn)程方法調(diào)用）來解決這個(gè)問題，但是RMI底層使用字節(jié)傳輸?shù)?，極容易被黑客偽造，這種架構(gòu)后來也消失在人們的視野中，但垂直拆分架構(gòu)一定程度上解決了高并發(fā)的問題。

二、開發(fā)效率

2.1問題簡(jiǎn)介

在公司中尤其是面向用戶的互聯(lián)網(wǎng)公司，如果不能按時(shí)更新，勢(shì)必會(huì)降低自己的口碑，降低用戶體驗(yàn)。因此架構(gòu)的改變也改變了開發(fā)模式的改變。

前面說到為了解決高并發(fā)的問題，聰明的軟件開發(fā)者們把架構(gòu)垂直拆分，但是也產(chǎn)生了拆分后的項(xiàng)目之間無法通信的問題。

2.2研究分析

第三種主流架構(gòu)——分布式架構(gòu)，悠然而生，通過模塊之間的鑒權(quán)，允許模塊之間進(jìn)行遠(yuǎn)程通信，開發(fā)人員也徹底解放：開發(fā)模式不再是十幾個(gè)人、幾百個(gè)人對(duì)著一個(gè)項(xiàng)目改來改去，而是按照模塊獨(dú)立開發(fā)，模塊之間的調(diào)用關(guān)系安排專門的人以文檔的形式來顯示。在很長(zhǎng)的一段時(shí)期中，這種架構(gòu)堪稱盛行，但很快他的弊病也顯示了出來：當(dāng)模塊越來越多時(shí)，調(diào)用關(guān)系錯(cuò)綜復(fù)雜，系統(tǒng)的耦合度增高，系統(tǒng)難以維護(hù)。舉個(gè)例子：假如你有20個(gè)模塊，最多有190種通信聯(lián)系，用戶想要改變需求，要求增加新功能，那么在原有的通信關(guān)系上加上新的模塊和關(guān)系將會(huì)是一個(gè)大工程，這樣開發(fā)效率不但沒有減少，反而隨著項(xiàng)目的增加而增大了，因?yàn)槟阋S護(hù)復(fù)雜的通信關(guān)系。同時(shí)，當(dāng)模塊集群部署時(shí)，怎么控制用戶應(yīng)該去訪問的模塊呢？

第四種，面向服務(wù)架構(gòu)（SOA），當(dāng)服務(wù)越來越多、小服務(wù)資源逐漸顯現(xiàn)，我們需要增加調(diào)度中心（常見：Nginx反向代理服務(wù)器）來管理集群壓力，把用戶的請(qǐng)求按訪問壓力進(jìn)行路由。這種架構(gòu)解決了外部需求和內(nèi)部模塊的訪問路由，但是仍然沒有解決模塊內(nèi)的調(diào)度解決方案。

為了解決開發(fā)效率以及模塊間的通信問題，微服務(wù)架構(gòu)產(chǎn)生了。它規(guī)定：1.每一個(gè)模塊稱為一個(gè)服務(wù)，職責(zé)單一;2.對(duì)外暴露一種面向資源的REST風(fēng)格接口，不關(guān)心技術(shù)的實(shí)現(xiàn);3.自治，每個(gè)服務(wù)對(duì)應(yīng)一個(gè)數(shù)據(jù)庫(kù)，小團(tuán)隊(duì)自治。我們發(fā)現(xiàn)，滿足微服務(wù)架構(gòu)的原則就好像云服務(wù)的感覺一樣，只不過每一個(gè)服務(wù)都是為了這個(gè)項(xiàng)目、這個(gè)用戶的需求而生的，一個(gè)開發(fā)團(tuán)隊(duì)可以拆分成若干個(gè)互不干擾的開發(fā)團(tuán)隊(duì)一樣，實(shí)現(xiàn)了開發(fā)的解耦，從而大大的提高了開發(fā)效率。當(dāng)然實(shí)現(xiàn)微服務(wù)架構(gòu)必然也要處理之前產(chǎn)生的架構(gòu)問題，并且又出現(xiàn)了新的問題。

在解決服務(wù)（之前的模塊）之間通信上，因?yàn)榧軜?gòu)規(guī)定每一個(gè)服務(wù)會(huì)對(duì)外暴露REST風(fēng)格接口，因此該架構(gòu)的技術(shù)都提供了一個(gè)服務(wù)注冊(cè)中心（比如：只有在滴滴上注冊(cè)的網(wǎng)約車才能被用戶找到），只有在注冊(cè)中心的服務(wù)才能被其他服務(wù)找到，并且依賴關(guān)系全部由注冊(cè)中心來管理，這樣復(fù)雜的通信關(guān)系再也不需要人為管理，用戶需要添加新的模塊我們只需要在注冊(cè)中心注冊(cè)一下即可，大大加快了開發(fā)的效率。因?yàn)榉?wù)之間是集群部署，實(shí)現(xiàn)微服務(wù)架構(gòu)必須應(yīng)用負(fù)載均衡框架和基于熔斷原理的框架，當(dāng)一個(gè)服務(wù)掛掉時(shí)，路由到集群中其他的服務(wù)，當(dāng)服務(wù)集群超過大比例掛掉時(shí)熔斷器打開，避免影響核心業(yè)務(wù)服務(wù)，這也就是說不僅開發(fā)自治，服務(wù)也是自治的。舉個(gè)例子：網(wǎng)上購(gòu)物時(shí)，訂單服務(wù)掛掉不影響我們把商品加入購(gòu)物車，這也是微服務(wù)的優(yōu)點(diǎn)之一。

受到SOA的啟發(fā)，服務(wù)外調(diào)用服務(wù)需要鑒權(quán)，服務(wù)內(nèi)之間的調(diào)用實(shí)際上是第三方注冊(cè)中心動(dòng)態(tài)代理的，其通信協(xié)議基于框架技術(shù)的協(xié)議，那么意味著內(nèi)部服務(wù)之間也是需要鑒權(quán)的。而微服務(wù)需要對(duì)外暴露REST風(fēng)格的接口，而該風(fēng)格最大特點(diǎn)就是無狀態(tài)性和表屬性狀態(tài)轉(zhuǎn)移。

我們來試想一下：Tomcat服務(wù)器需要保留用戶登陸的sessionID，客戶端cookie中保存登陸信息，以這種狀態(tài)的保存來判斷用戶登陸。但是REST風(fēng)格不允許，我們需要請(qǐng)求通過掛載token（可以理解客戶端的身份證）來判斷用戶登陸的狀態(tài)，也就是說每一個(gè)請(qǐng)求必須有token的存在，那么內(nèi)部服務(wù)調(diào)用也需要攜帶token，那么有20個(gè)模塊，你就要寫20次掛載代碼？網(wǎng)關(guān)的出現(xiàn)，解決了這個(gè)問題，網(wǎng)關(guān)攔截所有的內(nèi)、外部服務(wù)請(qǐng)求，實(shí)現(xiàn)鑒權(quán)，過濾，路由，熔斷，代理的功能。網(wǎng)關(guān)通過鑒權(quán)判斷你的請(qǐng)求是否合法，然后路由到對(duì)應(yīng)的服務(wù)，服務(wù)的REST接口返回到網(wǎng)關(guān)動(dòng)態(tài)代理調(diào)用，這樣我們?cè)诰W(wǎng)關(guān)就可以解決所有的服務(wù)之間的邏輯。當(dāng)然網(wǎng)關(guān)也要集群，這樣我們還是要沿用SOA架構(gòu)的形式，用反向代理服務(wù)器路由網(wǎng)關(guān)即可。

三、結(jié)語(yǔ)

本文中，提到了兩個(gè)問題需要解決。在解決問題途中，提到：提出了對(duì)單體架構(gòu)的水平擴(kuò)充，但會(huì)造成資源的浪費(fèi);把架構(gòu)垂直拆分解決了高并發(fā)、高可用問題，但也產(chǎn)生了拆分后的項(xiàng)目之間無法通信的問題;為了解決通信問題，又提出了分布式架構(gòu)，卻容易造成系統(tǒng)難以維護(hù);又有了面向服務(wù)架構(gòu)來解決訪問路由;直到微服務(wù)架構(gòu)的產(chǎn)生。我們深入分析了微服務(wù)架構(gòu)在當(dāng)今互聯(lián)網(wǎng)環(huán)境實(shí)現(xiàn)的必要性，提出了其在當(dāng)今互聯(lián)網(wǎng)環(huán)境的缺點(diǎn)的解決方案。架構(gòu)的發(fā)展是對(duì)“摩天大樓”的不斷完善，讓我們不斷向上延申了大樓的高度。

作者簡(jiǎn)介：

楊宸（2000-）北華航天工業(yè)學(xué)院計(jì)算機(jī)學(xué)院就讀，研究方向軟件工程。

田 晴（2002-）北華航天工業(yè)學(xué)院計(jì)算機(jī)學(xué)院就讀，研究方向軟件工程。

金新穎（1999-）北華航天工業(yè)學(xué)院就讀，研究方向計(jì)算機(jī)科學(xué)與技術(shù)。