微服務：系統架構的演變

通過這篇文章我們來學習我們項目系統架構的演變過程。沒部署過項目的或者沒做過項目的小夥伴也可以康康，hhhh..

當我們系統的用戶逐漸增多，我們系統就必須具備了高可用、高併發這樣的特性。如何解決？

1、單體應用架構

這種應用架構就是我們在校園中做項目（例如一個網站、一個小程序等）經常用的架構，說白了，學校也不可能給你幾臺服務器讓你玩分佈式，第一是有這種需求也不會交給學生做，第二是學校的系統一般的併發量還沒達到這個級別。我個人現在大三，在學校做過大大小小很多系統，到最後說白了就是反覆做同一個事，也沒啥難的（吹個牛B）。

優點：（1）所有的功能集成在一個項目工程中（2）項目架構簡單，前期開發成本低，週期短，小型項目的首選。

缺點：（1）全部功能集成在一個工程中，對於大型項目不易開發、擴展及維護（2）系統性能擴展只能通過擴展集羣結點，成本高、有瓶頸。 （3）技術棧受限（4）容錯不好，如果其中一個模塊出現問題，可能導致整個項目崩掉。

單體應用架構

2、垂直應用架構

當訪問量增加，我們就得想一下如何解決問題。將應用拆成互不相干的幾個應用，以提升效率

這裏將三個模塊系統，部署到三臺服務器上，這樣各自應用不會互相干擾，形成分流。三個系統是毫無關係的，但是這樣我們就需要寫一些重複的開發代碼了，比如後臺管理系統要看到電商系統的數據，那麼必然調用電商系統的數據內容。這個架構並沒有根本上解決高併發的問題。只是將原來的項目，一刀切爲3份而已。

優點：（1）項目架構簡單，前期開發成本低，週期短，小型項目的首選。（2）通過垂直拆分，原來的單體項目不至於無限擴大（3）不同的項目可採用不同的技術。

缺點：（1）全部功能集成在一個工程中，對於大型項目不易開發、擴展及維護。（2）系統性能擴展只能通過擴展集羣結點，成本高、有瓶頸。

3、分佈式SOA架構

SOA 全稱爲 Service-Oriented Architecture，即面向服務的架構。它可以根據需求通過網絡對鬆散耦合的粗粒度應用組件(服務)進行分佈式部署、組合和使用。一個服務通常以獨立的形式存在於操作系統進程中。
 

站在功能的角度，把業務邏輯抽象成可複用、可組裝的服務，通過服務的編排實現業務的快速再生，目的：把原先固有的業務功能轉變爲通用的業務服務，實現業務邏輯的快速複用。通過上面的描述可以發現 SOA 有如下幾個特點：分佈式、可重用、擴展靈活、鬆耦合。

 

相信你看的一臉懵比，木事，直接上圖！

 

 

我們將這三個系統，拆分成了很多個服務，整個系統分爲展示層（消費者）、服務層（提供者）以及esb或者dubbo。這樣將一個服務單獨部署在一個服務器或者集羣，然後通過註冊中心，消費者調用提供者，展示層通常就是我們說的controller層，服務層就是service。關於dubbo實現這樣一個架構可以參考：https://blog.csdn.net/weixin_44588495/article/details/104855903 還有我自己模擬寫了一個rpc：https://blog.csdn.net/weixin_44588495/article/details/105279242 

 

有人可能說這個跟上面的有啥區別，單獨的提供者之間不是相互獨立的，是可以相互調用的。而且服務是可以多點提供的，可以提供給不同的消費者。

 

優點：（1）抽取公共的功能爲服務,提高開發效率 （2）對不同的服務進行集羣化部署解決系統壓力 （3）基於ESB/DUBBO減少系統耦合

缺點：（1）抽取服務的粒度較大（2）服務提供方與調用方接口耦合度較高（3）分佈式事務等問題

 

4、微服務架構

 

 

微服務實際上就是將服務再細劃分爲更小粒度的服務。職責更加明確。而且爲前端調用提供接口，供http調用。

 

優點：（1）通過服務的原子化拆分，以及微服務的獨立打包、部署和升級，小團隊的交付週期將縮短，運維成

本也將大幅度下（2）微服務遵循單一原則。微服務之間採用Restful等輕量協議傳輸。

缺點：（1）微服務過多，服務治理成本高，不利於系統維護。 （2）分佈式系統開發的技術成本高（容錯、分佈式事務等）。

 

5、soa和微服務的關係

SOA（ Service Oriented Architecture ）“面向服務的架構”:他是一種設計方法，其中包含多個服 務， 服務之間通過相互依賴最終提供一系列的功能。一個服務 通常以獨立的形式存在與操作系統進程 中。各個服務之間 通過網絡調用。

微服務架構:其實和 SOA 架構類似,微服務是在 SOA 上做的昇華，微服務架構強調的一個重點是“業務需 要徹底的組件化和服務化”，原有的單個業務系統會拆分爲多個可以獨立開發、設計、運行的小應用。 這些小應用之間通過服務完成交互和集成。

 

功能	SOA	微服務
組件大小	大塊業務邏輯	單獨任務或小塊業務邏輯
耦合	通常鬆耦合	總是鬆耦合
公司架構	任何類型	小型、專注於功能交叉團隊
管理	着重中央管理	着重分散管理
目標	確保應用能夠交互操作	執行新功能、快速拓展開發團隊