前言
最近公司某個(gè)項(xiàng)目的架構(gòu)越來越龐大，維護(hù)起來非常難受。領(lǐng)導(dǎo)提出要把這個(gè)項(xiàng)目重構(gòu)，在工作中需要把原來的項(xiàng)目重構(gòu)成微服務(wù)架構(gòu)，因此學(xué)習(xí)微服務(wù)相關(guān)知識，在這里記錄下來，權(quán)當(dāng)筆記的同時(shí)也希望能對你有啟發(fā)。今天就來聊聊什么是微服務(wù)？
單體應(yīng)用
在聊微服務(wù)之前，我先給你們梳理下什么是單體應(yīng)用。如果你不知道單體應(yīng)用的痛，那也不會深刻理解微服務(wù)的價(jià)值。
上圖為我司某項(xiàng)目架構(gòu)，包含了四個(gè)模塊?？梢钥闯鑫宜敬隧?xiàng)目的架構(gòu)完完全全屬于傳統(tǒng)的 MVC 架構(gòu)，所有的子系統(tǒng)都集成在一個(gè)很繁雜的 JVM 進(jìn)程中。
優(yōu)點(diǎn)
這種單體架構(gòu)的優(yōu)點(diǎn)在于方便管理，所有代碼在同一項(xiàng)目中，但是當(dāng)需求越來越多，項(xiàng)目規(guī)模越來越大，其壞處也很明顯。
缺點(diǎn)
- 項(xiàng)目過于臃腫，部署效率低下
當(dāng)大大小小的功能模塊都集中在同一項(xiàng)目的時(shí)候，整個(gè)項(xiàng)目必然會變得臃腫，讓開發(fā)者難以維護(hù)。單體應(yīng)用的代碼越來越多，依賴的資源越來越多時(shí)，應(yīng)用編譯打包、部署測試一次非常耗時(shí)。
- 系統(tǒng)高可用性差，資源無法隔離
整個(gè)單體系統(tǒng)的各個(gè)功能模塊都依賴于同樣的數(shù)據(jù)庫、內(nèi)存等資源，一旦某個(gè)功能模塊對資源使用不當(dāng)，整個(gè)系統(tǒng)都會被拖垮。
- 開發(fā)成本高
早期在團(tuán)隊(duì)開發(fā)人員只有兩三個(gè)人的時(shí)候，協(xié)作修改代碼，打包部署，更新發(fā)布這完全可以控制。但是團(tuán)隊(duì)一旦擴(kuò)張，還是按照早期的方法去開發(fā)，那如果測試階段只要有一塊功能有問題，就得重新編譯打包部署。所有的開發(fā)人員又都得參與其中，效率低下，開發(fā)成本極高。
- 無法靈活拓展
當(dāng)系統(tǒng)的訪問量越來越大的時(shí)候，單體系統(tǒng)固然可以進(jìn)行水平擴(kuò)展，部署在多臺機(jī)器上組成集群：
但是這種擴(kuò)展并非靈活的擴(kuò)展。比如我們現(xiàn)在的性能瓶頸是支付模塊，希望只針對支付模塊做水平擴(kuò)展，這一點(diǎn)在單體系統(tǒng)是做不到的。因此，急需一種方法將應(yīng)用的不同模塊進(jìn)行解耦，從而降低開發(fā)和部署成本。
要解決上面單體應(yīng)用的問題，就必須引入服務(wù)化的概念。
什么是服務(wù)化？
用通俗的語言來說，服務(wù)化就是把傳統(tǒng)單體應(yīng)用中通過 JAR 包依賴產(chǎn)生的本地方法調(diào)用，改造成 RPC 接口產(chǎn)生的遠(yuǎn)程方法調(diào)用。這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過全自動(dòng)部署機(jī)制獨(dú)立部署。 這些服務(wù)的集中管理最少，可以用不同的編程語言編寫，并使用不同的數(shù)據(jù)存儲技術(shù)。
以我司項(xiàng)目為例，這個(gè)項(xiàng)目包含的四個(gè)模塊都是相互依賴的，當(dāng)這些模塊的代碼耦合到一起時(shí)，需要去加載每個(gè)模塊的代碼以及連接資源，任何一個(gè)出了問題，整個(gè)應(yīng)用都會受到影響。
為此，可以把耦合度較高的模塊，獨(dú)立數(shù)據(jù)源，獨(dú)立成一個(gè)服務(wù)部署，以 RPC 接口的形式對外提供服務(wù)。例如訂單模塊和用戶模塊：
可見通過服務(wù)化，可以解決單體應(yīng)用膨脹、團(tuán)隊(duì)開發(fā)耦合度高、協(xié)作效率底下的問題。
什么是微服務(wù)？
簡而言之，微服務(wù)架構(gòu)風(fēng)格是一種將單個(gè)應(yīng)用程序作為一套小型服務(wù)開發(fā)的方法，每種應(yīng)用程序都在自己的進(jìn)程中運(yùn)行，并與輕量級機(jī)制（通常是HTTP資源API）進(jìn)行通信。得益于以 Docker 為代表的容器化技術(shù)的成熟以及 DevOps 文化的的興起，服務(wù)化的思想進(jìn)一步演化，演變成我們今天所熟知的微服務(wù)。
說了這么多概念，微服務(wù)有什么樣的具體特點(diǎn)呢？
- 服務(wù)拆分粒度更細(xì)
微服務(wù)可以說是更細(xì)維度的服務(wù)化，小到一個(gè)子模塊，只要該模塊依賴的資源與其他模塊都沒有關(guān)系，那么就可以拆分為一個(gè)微服務(wù)。
- 服務(wù)獨(dú)立部署
傳統(tǒng)的單體架構(gòu)是以整個(gè)系統(tǒng)為單位進(jìn)行部署，而微服務(wù)則是以每一個(gè)獨(dú)立組件（例如用戶服務(wù)，商品服務(wù)）為單位進(jìn)行部署。
用一張經(jīng)典的圖來表現(xiàn)，就是下面這個(gè)樣子：
什么意思呢？比如根據(jù)每個(gè)服務(wù)的吞吐量不同，支付服務(wù)需要部署100臺機(jī)器，用戶服務(wù)需要部署30臺機(jī)器，而商品服務(wù)只需要部署10臺機(jī)器。這種靈活部署只有微服務(wù)架構(gòu)才能實(shí)現(xiàn)。
- 服務(wù)獨(dú)立維護(hù)，分工明確
每個(gè)微服務(wù)都可以交由一個(gè)小團(tuán)隊(duì)進(jìn)行開發(fā)，測試維護(hù)部署，并對整個(gè)生命周期負(fù)責(zé)。比如在單體應(yīng)用時(shí)期，我們的研發(fā)團(tuán)隊(duì)是如下圖這樣傳統(tǒng)的水平架構(gòu)：
而微服務(wù)時(shí)期，我們可以根據(jù)其思想把團(tuán)隊(duì)劃分成垂直組織架構(gòu)：
當(dāng)然，這種垂直劃分只是一個(gè)理想的架構(gòu)，實(shí)際在企業(yè)中并不會把團(tuán)隊(duì)組織架構(gòu)拆分得這么絕對。
后語
文章介紹了微服務(wù)的發(fā)展由來,它是由單體應(yīng)用進(jìn)化到服務(wù)化拆分部署,后期隨著移動(dòng)互聯(lián)網(wǎng)規(guī)模的不斷擴(kuò)大,敏捷開發(fā)、持續(xù)交付、DevOps 理論的發(fā)展和實(shí)踐,以及基于 Docker 容器化技術(shù)的成熟,微服務(wù)架構(gòu)開始流行,逐漸成為應(yīng)用架構(gòu)的未來演進(jìn)方向。
以上就是我對微服務(wù)的理解，希望對你們有幫助。最后，對 Python 、Java 感興趣請長按二維碼關(guān)注一波，我會努力帶給你們價(jià)值，如果覺得本文對你哪怕有一丁點(diǎn)幫助，請幫忙點(diǎn)個(gè)贊
小福利
如果看到這里，喜歡這篇文章的話，請幫點(diǎn)個(gè)好看。微信搜索一個(gè)優(yōu)秀的廢人，關(guān)注后回復(fù)電子書送你 1000+ 本編程電子書 ，包括 C、C++、Java、Python、GO、Linux、Git、數(shù)據(jù)庫、設(shè)計(jì)模式、前端、人工智能、面試相關(guān)、數(shù)據(jù)結(jié)構(gòu)與算法以及計(jì)算機(jī)基礎(chǔ)，詳情看下圖?；貜?fù) 1024 送你一套完整的 java 視頻教程。
|
