淺談微服務架構

楊宸 田晴 金新穎

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

關鍵詞：單體架構;垂直拆分架構;分布式架構;面向服務架構;微服務架構;REST風格

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

1.1問題簡介

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

1.2研究分析

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

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

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

二、開發(fā)效率

2.1問題簡介

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

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

2.2研究分析

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

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

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

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

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

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

三、結語

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

作者簡介：

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

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

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