微服務架構的前世今生（二）：技術架構演變

上一篇我們講了微服務架構的前世今生（一）：傳統行業向互聯網行業的轉型，本文接著3講述微服務技術架構演變，

下圖表示從單體應用逐漸轉變為微服務應用，

一、單一應用架構

通俗地講，“單體應用（monolith application）”就是將應用程式的所有功能都打包成一個獨立的單元，當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本，

1、特點

• 所有的功能集成在一個專案工程中；
• 所有的功能打一個 war 包部署到服務器；
• 應用與資料庫分開部署；
• 通過部署應用集群和資料庫集群來提高系統的性能，

2、優點

• 「開發簡單」：一個 IDE 就可以快速構建單體應用；

• 「便于共享」：單個歸檔檔案包含所有功能，便于在團隊之間以及不同的部署階段之間共享；

• 「易于測驗」：單體應用一旦部署，所有的服務或特性就都可以使用了，這簡化了測驗程序，因為沒有額外的依賴，每項測驗都可以在部署完成后立刻開始；

• 「容易部署」：整個專案就一個 war 包，Tomcat 安裝好之后，應用扔上去就行了，群化部署也很容易，多個 Tomcat + 一個 Nginx 分分鐘搞定，

3、缺點

• 「妨礙持續交付」：隨著時間的推移，單體應用可能會變得比較大，構建和部署時間也相應地延長，不利于頻繁部署，阻礙持續交付，在移動應用開發中，這個問題會顯得尤為嚴重；
• 「不夠靈活」：隨著專案的逐漸變大，整個開發流程的時間也會變得很長，即使在僅僅更改了一行代碼的情況下，軟體開發人員需要花費幾十分鐘甚至超過一個小時的時間對所有代碼進行編譯，并接下來花費大量的時間重新部署剛剛生成的產品，以驗證自己的更改是否正確，如果多個開發人員共同開發一個應用程式，那么還要等待其他開發人員完成了各自的開發，這降低了團隊的靈活性和功能交付頻率；
• 「受技術堆疊限制」：專案變得越來越大的同時，我們的應用所使用的技術也會變得越來越多，這些技術有些是不兼容的，就比如在一個專案中大范圍地混合使用 C++ 和 Java 幾乎是不可能的事情，在這種情況下，我們就需要拋棄對某些不兼容技術的使用，而選擇一種不是那么適合的技術來實作特定的功能，
• 「可靠性差」：某個環節出現了死回圈，導致記憶體溢位，會影響整個專案掛掉，
• **伸縮性差：**系統的擴容只能針對應用進行擴容，不能做到對某個功能進行擴容，擴容后必然帶來資源浪費的問題，
• 「技術債務」：假設我的代碼庫中有一個混亂的模塊結構，此時，我需要添加一個新功能，如果這個模塊結構清晰，可能我只需要2天時間就可以添加好這個功能，但是如今這個模塊的結構很混亂，所以我需要4天時間，多出來的這兩天就是債務利息，隨著時間推移、人員變動，技術債務必然也會隨之增多，

二、垂直應用架構

當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率，

1、特點

• 以單體結構規模的專案為單位進行垂直劃分，就是將一個大專案拆分成一個一個單體結構專案，
• 專案與專案之間存在資料冗余，耦合性較大，比如上圖中三個專案都存在用戶資訊，
• 專案之間的介面多為資料同步功能，如：資料庫之間的資料庫，通過網路介面進行資料庫同步，

2、優點

• 開發成本低，架構簡單；

• 避免單體應用的無限擴大；

• 系統拆分實作了流量分擔，解決了并發問題；

• 可以針對不同系統進行擴容、優化；

• 方便水平擴展，負載均衡，容錯率提高；

• 不同的專案可采用不同的技術；

• 系統間相互獨立，

3、缺點

• 系統之間相互呼叫，如果某個系統的埠或者 IP 地址發生改變，呼叫系統需要手動變更；
• 垂直架構中相同邏輯代碼需要不斷的復制，不能復用，
• 系統性能擴展只能通過擴展集群結點，成本高、有瓶頸，

三、SOA 面向服務架構

當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基于訪問壓力實時管理集群容量，提高集群利用率，

P.S.：從軟體設計的角度上來說，ESB 是一個抽象的間接層，提取了服務呼叫程序中呼叫與被呼叫動態互動中的一些共同的東西，減輕了服務呼叫者的負擔，Java 編程思想里提到：“所有的軟體設計的問題都可以通過增加一個抽象的間接層而得到解決或者得到簡化！”簡單來說 ESB 就是一根管道，用來連接各個服務節點，為了集成不同系統，不同協議的服務，ESB 做了訊息的轉化解釋和路由作業，讓不同的服務互聯互通，

1、特點

• 基于 SOA 的架構思想將重復公用的功能抽取為組件，以服務的形式給各系統提供服務，
• 各專案（系統）與服務之間采用 WebService、RPC 等方式進行通信，
• 使用 ESB 企業服務總線作為專案與服務之間通信的橋梁，

2、優點

• 將重復的功能抽取為服務，提高開發效率，提高系統的可重用性、可維護性，
• 可以針對不同服務的特點制定集群及優化方案；
• 采用 ESB 減少系統中的介面耦合，

3、缺點

• 系統與服務的界限模糊，不利于開發及維護，
• 雖然使用了 ESB，但是服務的介面協議不固定，種類繁多，不利于系統維護，
• 抽取的服務的粒度過大，系統與服務之間耦合性高，
• 涉及多種中間件，對開發人員技術堆疊要求高，
• 服務關系復雜，運維、測驗部署困難

四、微服務架構

1、特點

• 將系統服務層完全獨立出來，并將服務層抽取為一個一個的微服務，
• 微服務中每一個服務都對應唯一的業務能力，遵循單一原則，
• 微服務之間采用 RESTful 等輕量協議傳輸，

2、優點

• 團隊獨立：每個服務都是一個獨立的開發團隊，這個小團隊可以是 2 到 5 人的開發人員組成；
• 技術獨立：采用去中心化思想，服務之間采用 RESTful 等輕量協議通信，使用什么技術什么語言開發，別人無需干涉；
• 前后端分離：采用前后端分離開發，提供統一 Rest 介面，后端不用再為 PC、移動端開發不同介面；
• 資料庫分離：每個微服務都有自己的存盤能力，可以有自己的資料庫，也可以有統一資料庫；
• 服務拆分粒度更細，有利于資源重復利用，提高開發效率；
• 一個團隊的新成員能夠更快投入生產；
• 微服務易于被一個開發人員理解，修改和維護，這樣小團隊能夠更關注自己的作業成果，無需通過合作才能體現價值；
• 可以更加精準的制定每個服務的優化方案（比如擴展），提高系統可維護性；
• 適用于互聯網時代，產品迭代周期更短，

3、缺點

• 微服務過多，服務治理成本高，不利于系統維護；
• 分布式系統開發的技術成本高（網路問題、容錯問題、呼叫關系、分布式事務等），對團隊挑戰大；
• 微服務將原來的函式式呼叫改為服務呼叫，不管是用 rpc，還是 http rest 方式，都會增大系統整體延遲，這個是再所難免的，這個就需要我們將原來的串行編程改為并發編程甚至異步編程，增加了技術門檻；
• 多服務運維難度，隨著服務的增加，運維的壓力也在增大；
• 測驗的難度提升，服務和服務之間通過介面來互動，當介面有改變的時候，對所有的呼叫方都是有影響的，這時自動化測驗就顯得非常重要了，如果要靠人工一個個介面去測驗，那作業量就太大了，所以 API 檔案的管理尤為重要，

 本文就介紹到這里，想獲取java微服務架構學習視頻資料，請點擊訪問java微服務架構spring全家桶教程，

下一篇文章將分享2個故事，幫助大家更好的理解 SOA 與微服務的區別，

標籤：Java

上一篇：求助，不會寫的題

下一篇：Hello.java