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