微服务和微服务架构
?
微服務
前言
最近公司某個項目的架構越來越龐大,維護起來非常難受。我主動想領導提出要把這個項目重構在工作中需要把原來的項目重構成微服務架構,因此學習微服務相關知識,在這里記錄下來,權當筆記的同時也希望能對你有啟發。今天就來聊聊什么是微服務?
單體應用
在聊微服務之前,我先給你們梳理下什么是單體應用。如果你不知道單體應用的痛,那也不會深刻理解微服務的價值。
單體應用
上圖為我司某項目架構,包含了四個模塊。可以看出我司此項目的架構完完全全屬于傳統的 MVC 架構,所有的子系統都集成在一個很繁雜的 JVM 進程中。
優點
這種單體架構的優點在于方便管理,所有代碼在同一項目中,但是當需求越來越多,項目規模越來越大,其壞處也很明顯。
缺點
當大大小小的功能模塊都集中在同一項目的時候,整個項目必然會變得臃腫,讓開發者難以維護。單體應用的代碼越來越多,依賴的資源越來越多時,應用編譯打包、部署測試一次非常耗時。
整個單體系統的各個功能模塊都依賴于同樣的數據庫、內存等資源,一旦某個功能模塊對資源使用不當,整個系統都會被拖垮。
早期在團隊開發人員只有兩三個人的時候,協作修改代碼,打包部署,更新發布這完全可以控制。但是團隊一旦擴張,還是按照早期的方法去開發,那如果測試階段只要有一塊功能有問題,就得重新編譯打包部署。所有的開發人員又都得參與其中,效率低下,開發成本極高。
當系統的訪問量越來越大的時候,單體系統固然可以進行水平擴展,部署在多臺機器上組成集群:
單體應用集群
但是這種擴展并非靈活的擴展。比如我們現在的性能瓶頸是支付模塊,希望只針對支付模塊做水平擴展,這一點在單體系統是做不到的。因此,急需一種方法將應用的不同模塊進行解耦,從而降低開發和部署成本。
要解決上面單體應用的問題,就必須引入服務化的概念。
什么是服務化?
用通俗的語言來說,服務化就是把傳統單體應用中通過 JAR 包依賴產生的本地方法調用,改造成 RPC 接口產生的遠程方法調用。這些服務是圍繞業務功能構建的,可以通過全自動部署機制獨立部署。 這些服務的集中管理最少,可以用不同的編程語言編寫,并使用不同的數據存儲技術。
以我司項目為例,這個項目包含的四個模塊都是相互依賴的,當這些模塊的代碼耦合到一起時,需要去加載每個模塊的代碼以及連接資源,任何一個出了問題,整個應用都會受到影響。
為此,可以把耦合度較高的模塊,獨立數據源,獨立成一個服務部署,以 RPC 接口的形式對外提供服務。例如訂單模塊和用戶模塊:
服務化
可見通過服務化,可以解決單體應用膨脹、團隊開發耦合度高、協作效率底下的問題。
什么是微服務架構?
微服務架構是一種架構風格,簡而言之,微服務架構風格是一種將單個應用程序作為一套小型服務開發的方法,每種應用程序都在自己的進程中運行,并與輕量級機制(通常是HTTP資源API)進行通信。得益于以 Docker 為代表的容器化技術的成熟以及 DevOps 文化的的興起,服務化的思想進一步演化,演變成我們今天所熟知的微服務。
說了這么多概念,微服務有什么樣的具體特點呢?
微服務可以說是更細維度的服務化,小到一個子模塊,只要該模塊依賴的資源與其他模塊都沒有關系,那么就可以拆分為一個微服務。
傳統的單體架構是以整個系統為單位進行部署,而微服務則是以每一個獨立組件(例如用戶服務,商品服務)為單位進行部署。
用一張經典的圖來表現,就是下面這個樣子:
左邊是單體架構的集群,右邊是微服務集群
什么意思呢?比如根據每個服務的吞吐量不同,支付服務需要部署100臺機器,用戶服務需要部署30臺機器,而商品服務只需要部署10臺機器。這種靈活部署只有微服務架構才能實現。
每個微服務都可以交由一個小團隊進行開發,測試維護部署,并對整個生命周期負責。比如在單體應用時期,我們的研發團隊是如下圖這樣傳統的水平架構:
水平團隊組織架構
而微服務時期,我們可以根據其思想把團隊劃分成垂直組織架構:
垂直團隊組織架構
當然,這種垂直劃分只是一個理想的架構,實際在企業中并不會把團隊組織架構拆分得這么絕對。
后語
文章介紹了微服務的發展由來,它是由單體應用進化到服務化拆分部署,后期隨著移動互聯網規模的不斷擴大,敏捷開發、持續交付、DevOps 理論的發展和實踐,以及基于 Docker 容器化技術的成熟,微服務架構開始流行,逐漸成為應用架構的未來演進方向。
以上就是我對微服務的理解,希望對你們有幫助。最后,對 Python 、Java 感興趣請長按二維碼關注一波,我會努力帶給你們價值,如果覺得本文對你哪怕有一丁點幫助,請幫忙點個贊。
總結
- 上一篇: 第四部分 Calendar使用示例
- 下一篇: pat天梯赛L1-051. 打折