淺談微服務架構

楊宸 田晴 金新穎

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

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

一、解決高并發，高可用問題

1.1問題簡介

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

1.2研究分析

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

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

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

二、開發效率

2.1問題簡介

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

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

2.2研究分析

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

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

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

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

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

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

三、結語

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

作者簡介：

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

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

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