建站
咨詢
售后
建站咨詢
新聞中心
不管你喜不喜歡微服務(wù)，現(xiàn)在微服務(wù)無(wú)疑已經(jīng)是程序員們繞不過(guò)去的話題了。無(wú)論你是想把目前的架構(gòu)改成微服務(wù)，還是你要出去面試高級(jí)一點(diǎn)的崗位，需要深入理解微服務(wù)。
創(chuàng)新互聯(lián)是一家專業(yè)從事成都網(wǎng)站建設(shè)、成都做網(wǎng)站的網(wǎng)絡(luò)公司。作為專業(yè)的建站公司,創(chuàng)新互聯(lián)依托的技術(shù)實(shí)力、以及多年的網(wǎng)站運(yùn)營(yíng)經(jīng)驗(yàn),為您提供專業(yè)的成都網(wǎng)站建設(shè)、營(yíng)銷型網(wǎng)站及網(wǎng)站設(shè)計(jì)開發(fā)服務(wù)！
提起微服務(wù)，很多程序員對(duì)它是又愛又恨，想學(xué)微服務(wù)不知道如何開始，學(xué)了一點(diǎn)之后，又找不到地方去實(shí)踐。總之就是感覺微服務(wù)遙不可及，又很難駕馭。
首先要明白的是微服務(wù)是有套路的，而這些套路基本上解決了微服務(wù)結(jié)構(gòu)面臨的幾乎所有重要問題。
這些套路就是微服務(wù)自己的架構(gòu)模式
如果我們能深入了解這些模式的其來(lái)龍去脈，就可以理解了微服務(wù)絕大部分內(nèi)容。學(xué)習(xí)快速，實(shí)用價(jià)值也極大。
1. 微服務(wù)最基本的模式
這篇文章先來(lái)講第一個(gè)最基本的模式，這個(gè)模式我估計(jì)需要三篇文章才能講透，這是上篇。打算中篇寫實(shí)踐，下篇寫問題。
希望大家能學(xué)的輕松。
微服務(wù)最基本的模式就是：
一個(gè)服務(wù)一個(gè)數(shù)據(jù)庫(kù)
上圖就是一個(gè)最簡(jiǎn)單的微服務(wù)模式了。
一個(gè)服務(wù)一個(gè)數(shù)據(jù)庫(kù)這種模式，是微服務(wù)體系結(jié)構(gòu)中的最基礎(chǔ)也是最核心的模式?？粗?jiǎn)單，但是，這個(gè)模式蘊(yùn)含著微服務(wù)的最基本的思想。
要弄清楚一個(gè)服務(wù)一個(gè)數(shù)據(jù)庫(kù)這種模式，首先我們就需要問一下，為什么我們要搞微服務(wù)。
2. 傳統(tǒng)系統(tǒng)的問題
在談及微服務(wù)的時(shí)候，和微服務(wù)對(duì)應(yīng)的概念叫做單體系統(tǒng)( Monolithic application )。簡(jiǎn)單說(shuō)，微服務(wù)是為了解決單體系統(tǒng)的問題才衍生出來(lái)的。單體系統(tǒng)結(jié)構(gòu)如下圖:
那么這種單體結(jié)構(gòu)出現(xiàn)了什么問題，導(dǎo)致現(xiàn)在大家必須開口閉口微服務(wù)了呢?
3. 單體系統(tǒng)太大了
最首要的一個(gè)原因就是應(yīng)用系統(tǒng)太大。而由于應(yīng)用系統(tǒng)的過(guò)于龐大，如果僅是單體系統(tǒng)的話，就引發(fā)了各種各樣的問題，體現(xiàn)在以下三個(gè)方面：
3.1. 系統(tǒng)本身業(yè)務(wù)復(fù)雜，模塊眾多
系統(tǒng)隨著時(shí)間的發(fā)展，業(yè)務(wù)需求越來(lái)越多。而為了滿足這些需求，就導(dǎo)致整個(gè)系統(tǒng)的模塊越來(lái)越多。而系統(tǒng)模塊越來(lái)越多，就導(dǎo)致能理解整套系統(tǒng)的人變得越來(lái)越少，直到最后沒有人可以理解整套系統(tǒng)。
3.2. 系統(tǒng)的代碼庫(kù)非常龐大
代碼量也會(huì)隨著系統(tǒng)的增大而增大，代碼量的龐大影響了整個(gè)開發(fā)流程，會(huì)導(dǎo)致整個(gè)開發(fā)成本變得很高。
- 首先，代碼量大，依賴關(guān)系復(fù)雜，所以對(duì)新接手的開發(fā)人員來(lái)說(shuō)，配置開發(fā)環(huán)境非常耗費(fèi)精力。
- 其次，代碼量大，加載這些代碼和對(duì)應(yīng)的依賴需要的內(nèi)存就多，所以就會(huì)導(dǎo)致開發(fā)人員的 IDE 運(yùn)行非常緩慢，導(dǎo)致編輯代碼都很麻煩。
- 再次，代碼量大，如果要把整個(gè)代碼編譯打包，需要的內(nèi)存也很多，所以也會(huì)導(dǎo)致功能開發(fā)完成后，對(duì)系統(tǒng)的構(gòu)建會(huì)非常緩慢，導(dǎo)致整個(gè)構(gòu)建的時(shí)間非常漫長(zhǎng)。
- 再有，代碼量大，幾乎沒人能對(duì)整體代碼有比較深入的了解，哪怕可能其中一個(gè)要改動(dòng)的功能，都會(huì)因?yàn)檫^(guò)于復(fù)雜導(dǎo)致開發(fā)人員理解不深入。而這些不深入的理解又會(huì)讓開發(fā)人員不能使用最佳的方式去做功能開發(fā)，從而導(dǎo)致隱藏的 bug。
3.3. 技術(shù)團(tuán)隊(duì)變得非常龐大
由于功能模塊越來(lái)越多，這就需要越來(lái)越多的開發(fā)人員去開發(fā)和維護(hù)這套系統(tǒng)。但是，這些開發(fā)人員都是面對(duì)的同一套代碼庫(kù)，雖然可以搞分支，大家各搞各的?？墒且坏┬枰洗a，發(fā)布上線，就是場(chǎng)噩夢(mèng)。
各種代碼沖突，代碼丟失，都可能在上線的時(shí)候發(fā)生。
不僅如此，由于顧慮代碼丟失和沖突，就需要在上線前，進(jìn)行足量的測(cè)試，而這些測(cè)試又需要投入巨大的時(shí)間成本。
但是，現(xiàn)在都講敏捷開發(fā)，很可能在還沒上線的時(shí)候，后續(xù)的業(yè)務(wù)需求又接踵而至，簡(jiǎn)直要命。
4. 業(yè)務(wù)需求的個(gè)性化
搞微服務(wù)，還有一個(gè)很重要的原因是業(yè)務(wù)需求的個(gè)性化和顆?；?。
隨著業(yè)務(wù)的發(fā)展，不管是由于市場(chǎng)競(jìng)爭(zhēng)還是本身發(fā)展的需要，勢(shì)必需要對(duì)本身業(yè)務(wù)模型的深度挖掘以及提高用戶使用系統(tǒng)的各種體驗(yàn)。而基于此類種種，就勢(shì)必要把系統(tǒng)的各個(gè)功能模塊做深做透。
這又會(huì)引發(fā)幾個(gè)新的問題:
4.1. 系統(tǒng)功能模塊可能變得更多更雜
系統(tǒng)功能模塊可能被不斷拆分成了更細(xì)碎的模塊，以致可能碎成了顆粒。而由于功能變得更碎更顆粒了，就會(huì)讓產(chǎn)品經(jīng)理們更容易的提出一些非常細(xì)致的業(yè)務(wù)需求。
這些非常細(xì)致的需求，很可能會(huì)造成頻繁的功能修改和上線要求。而這些無(wú)窮盡的快速需求相對(duì)整體龐大的系統(tǒng)上線和開發(fā)人員的疲于奔命形成了最激烈的沖突。
4.2. 功能模塊對(duì)系統(tǒng)的技術(shù)要求出現(xiàn)了沖突
比如，不同的功能模塊，訂單模塊和支付模塊。訂單模塊就希望系統(tǒng)能盡可能的能同時(shí)處理大量的訂單，甚至可以有一定的容錯(cuò)性，出問題了砍單就可以了。
但是支付模塊則不一樣，支付模塊希望系統(tǒng)能盡量的穩(wěn)定，并且必須對(duì)準(zhǔn)確度要求極高，幾乎沒有容錯(cuò)的空間。
同樣的，在同樣的支付模塊中(根據(jù)系統(tǒng)模塊劃分而定)，可能同時(shí)存在本地賬戶轉(zhuǎn)賬和三方渠道支付，本地賬戶轉(zhuǎn)賬可能需要即時(shí)，要求極高的響應(yīng)時(shí)間。但是對(duì)于第三方支付，則可以有一定的響應(yīng)時(shí)間容忍度。
如果系統(tǒng)本身是個(gè)單體系統(tǒng)，就勢(shì)必要求開發(fā)人員對(duì)整套系統(tǒng)做一定的妥協(xié)，對(duì)沖突的技術(shù)需求做出一定的權(quán)衡。而這種權(quán)衡很可能影響的就是系統(tǒng)整體的體驗(yàn)度。
4.3. 系統(tǒng)模塊對(duì)服務(wù)器的要求出現(xiàn)了沖突
由于功能的深耕細(xì)作，則勢(shì)必會(huì)出現(xiàn)性能上的不同需求。
比如，系統(tǒng)的訂單模塊，個(gè)人下單可能會(huì)被頻頻訪問，此時(shí)，就需要系統(tǒng)的集群多一些，去處理這些大規(guī)模的訪問。但是，同樣的功能模塊里，可能還存在一些企業(yè)團(tuán)購(gòu)需求，他們沒有那么大的訪問量，就不需要那么多的服務(wù)器集群。
又比如，用戶評(píng)論截圖，可能需要大量的數(shù)據(jù)存儲(chǔ)。但是，同樣的，針對(duì)用戶的個(gè)性化推薦就可能需要大規(guī)模的密集運(yùn)算。
除了上面說(shuō)的，系統(tǒng)龐大引發(fā)的問題帶來(lái)的一些附屬問題：
4.4. 故障的連鎖反應(yīng)問題
單體系統(tǒng)從技術(shù)上，各個(gè)模塊是耦合在一起的。在實(shí)際運(yùn)行里，很可能就會(huì)出現(xiàn)一處故障導(dǎo)致整個(gè)系統(tǒng)崩盤的現(xiàn)象。
比如，不常用的一個(gè) XX 功能出現(xiàn)了內(nèi)存泄露，導(dǎo)致整個(gè)系統(tǒng)全部不可用了。
4.5. 系統(tǒng)的技術(shù)鎖死問題
坦白來(lái)說(shuō)，你得承認(rèn)在編程里，沒有一種語(yǔ)言是完美的，也沒有一個(gè)數(shù)據(jù)庫(kù)是萬(wàn)能的。
比如，Java 做科學(xué)計(jì)算就沒有 Python 那么方便高效。比如，我們需要存儲(chǔ)很復(fù)雜的對(duì)象關(guān)系的時(shí)候，MySQL、Oracle 就不如任何一種圖形數(shù)據(jù)庫(kù)。
所以，系統(tǒng)越復(fù)雜，需要不同技術(shù)的概率就越高。但是又由于系統(tǒng)的復(fù)雜，引入新技術(shù)的風(fēng)險(xiǎn)也就越大。所以，新技術(shù)的使用非常困難。
同時(shí)，系統(tǒng)龐大后，如果一些組件，甚至語(yǔ)言 SDK 本身的問題如果需要升級(jí)，也是一件既繁瑣，又充滿風(fēng)險(xiǎn)的事情，所以，技術(shù)版本升級(jí)也非常困難。
綜上，對(duì)于傳統(tǒng)的單體應(yīng)用來(lái)講，系統(tǒng)龐大引發(fā)的技術(shù)問題，業(yè)務(wù)發(fā)展引發(fā)的需求沖突問題……都是無(wú)法單憑單體系統(tǒng)的架構(gòu)思想就可以解決的。
那為什么 SOA 也不能解決這些問題呢?
5. SOA 的問題
咱們先來(lái)看看SOA的結(jié)構(gòu)
可以看到 SOA 架構(gòu)中有個(gè) ESB(企業(yè)服務(wù)總線)。這個(gè) ESB 就是專門用于 SOA 的服務(wù)和服務(wù)之間的互動(dòng)，是 SOA 必備的基礎(chǔ)技術(shù)設(shè)施。
正因?yàn)?SOA 有了服務(wù)總線的思想，就注定 SOA 切分的服務(wù)不可能太細(xì)，因?yàn)榉?wù)出現(xiàn)的越多，這個(gè)服務(wù)總線就最終會(huì)變成一個(gè)整體系統(tǒng)的瓶頸。
SOA 的服務(wù)切分規(guī)模本身就受到了限制，這個(gè)限制就會(huì)帶來(lái)以下的問題:
- 切分不夠細(xì)——我們說(shuō)過(guò)，我們的主要問題根源是系統(tǒng)過(guò)于龐大，并且還堆在了一起。如果我們切分不夠細(xì)，那么可能的結(jié)果就會(huì)變?yōu)?，從一個(gè)很大的系統(tǒng)被切分為了寥寥幾個(gè)也很大的系統(tǒng)，最終沒有解決問題不說(shuō)，還可能因?yàn)橄到y(tǒng)變成了不同的分布式服務(wù)，又引入了新的分布式系統(tǒng)本身所帶來(lái)的問題。
- ESB 本身就可能成為一個(gè)龐大無(wú)比的系統(tǒng)怪獸——ESB 作為 SOA 的基礎(chǔ)設(shè)施，它本身就已經(jīng)足夠復(fù)雜，很可能由于業(yè)務(wù)的發(fā)展，它自己也變成了一個(gè)恐怖的系統(tǒng)怪物。從而讓開發(fā)人員不僅需要維護(hù)原來(lái)的系統(tǒng)，很可能還需要為如何維護(hù)和修改ESB本身而傷透腦筋。
所以，可以看出來(lái)，SOA這種思維方式和架構(gòu)實(shí)現(xiàn)本身不足以解決龐大單體系統(tǒng)帶來(lái)的問題。
6. 為什么需要服務(wù)
回到我們的微服務(wù)的話題。我們知道了問題的根源，我們就需要著手解決這些問題。
首先，既然問題是由于系統(tǒng)的龐大復(fù)雜引起的，那么我們就可以參考軟件里很普遍的解決思想：分而克之。
無(wú)論一個(gè)系統(tǒng)有多大，如果我們將其拆的足夠小，就可以把一個(gè)復(fù)雜的大系統(tǒng)拆分成許多個(gè)小系統(tǒng)，再讓這分解出來(lái)的小系統(tǒng)通過(guò)對(duì)外提供服務(wù)的手段，將他們?cè)倬酆铣梢惶状蟮耐暾w系，從結(jié)果上，就等價(jià)為了原來(lái)的復(fù)雜的大系統(tǒng)了。而這，就是微服務(wù)的最樸實(shí)的思想。
所以，微服務(wù)思想核心有兩個(gè):
- 把系統(tǒng)拆分成不同的部分
- 這些部分要足夠小
微服務(wù)這樣做帶來(lái)了幾個(gè)好處:
- 無(wú)論多大多復(fù)雜的系統(tǒng)，我只要能拆，會(huì)拆，就能把問題簡(jiǎn)化，從而不用懼怕系統(tǒng)變得復(fù)雜。
- 拆分出來(lái)的服務(wù)只要足夠小，那么無(wú)論開發(fā)、部署、運(yùn)維上，都能得到無(wú)數(shù)原來(lái)因?yàn)橄到y(tǒng)龐大而無(wú)法獲得的好處：修改代碼可能變得簡(jiǎn)單了，測(cè)試和運(yùn)行也變得容易了……
- 拆分出來(lái)的服務(wù)能各自獨(dú)立發(fā)展，不會(huì)互相制約。原來(lái)系統(tǒng)是單體系統(tǒng)的時(shí)候，模塊之間由于技術(shù)上的耦合，導(dǎo)致無(wú)法自由自在的選用最適合當(dāng)前功能模塊的技術(shù)，也不能隨心所欲的根據(jù)當(dāng)前功能模塊的負(fù)載情況去彈性的安排服務(wù)器。
- 故障天然被隔離開了。我們把系統(tǒng)切分成了服務(wù)，每個(gè)服務(wù)都有自己的進(jìn)程或者服務(wù)器，這樣故障從物理層面就被隔離開了，從而避免了一處不重要的功能故障導(dǎo)致整個(gè)系統(tǒng)崩盤。我們只需要把核心的功能弄的足夠健壯，即使非核心功能有了問題，也不會(huì)造成太大的損失。
所以，一套巨大的系統(tǒng)，由于本身的臃腫和復(fù)雜，就可能會(huì)要對(duì)其自身進(jìn)行拆分。而這些拆分，根據(jù)一些指導(dǎo)原則，將其拆解的夠小，夠簡(jiǎn)單，那么，拆解后帶來(lái)的效益是很可觀的。
7. 為什么需要拆庫(kù)
服務(wù)已經(jīng)拆了，已經(jīng)獲得那么大的好處了。
“但是為什么數(shù)據(jù)庫(kù)也必須要拆?”——這其實(shí)是很多使用微服務(wù)的同學(xué)最疑惑的問題了。
數(shù)據(jù)庫(kù)拆分不拆分本質(zhì)上其實(shí)就是數(shù)據(jù)共享的問題。而一個(gè)服務(wù)一個(gè)庫(kù)本身的觀念，其實(shí)就是盡最大程度的避免數(shù)據(jù)的共享。
數(shù)據(jù)共享會(huì)帶來(lái)如下幾個(gè)問題:
7.1. 技術(shù)實(shí)現(xiàn)依然可能耦合
因?yàn)闆]有拆分?jǐn)?shù)據(jù)庫(kù)，所以，很可能一個(gè)本來(lái)應(yīng)該獨(dú)立出來(lái)的服務(wù)模塊，必須依賴于另外的服務(wù)模塊，而這和我們拆分服務(wù)的初衷出現(xiàn)了沖突。
比如，訂單服務(wù)和個(gè)性化推薦服務(wù)，很可能都需要訪問訂單相關(guān)數(shù)據(jù)。此時(shí)，如果不拆數(shù)據(jù)庫(kù)，則很可能由于訂單業(yè)務(wù)需求導(dǎo)致的訂單表結(jié)構(gòu)的修改，倒逼個(gè)性化推薦服務(wù)也要跟著修改。
7.2. 底層數(shù)據(jù)的過(guò)度暴露
還是上面訂單服務(wù)和個(gè)性化推薦服務(wù)的例子，個(gè)性化推薦很可能只是需要一些用戶 id、訂單類別之類的東西，但是由于數(shù)據(jù)庫(kù)是共享的，很可能開放的就是訂單表的全部數(shù)據(jù)，而這些數(shù)據(jù)有很多算是敏感數(shù)據(jù)，應(yīng)該被隱藏的，現(xiàn)在則被暴露出去了。
7.3. 無(wú)必要的數(shù)據(jù)訪問競(jìng)爭(zhēng)
因?yàn)槭峭粋€(gè)數(shù)據(jù)庫(kù)，這勢(shì)必會(huì)造成對(duì)共享數(shù)據(jù)的競(jìng)爭(zhēng)性訪問，而這些競(jìng)爭(zhēng)性訪問則會(huì)大大影響業(yè)務(wù)模塊的彈性部署。比如，訂單模塊很可能由于個(gè)性化推薦的一些定時(shí)批量查詢，被影響了其能承載的并發(fā)數(shù)據(jù)量。
所以，看出來(lái)了吧，分庫(kù)是必須要考慮進(jìn)微服務(wù)整個(gè)體系結(jié)構(gòu)的。
8. 最后留個(gè)尾巴
每一個(gè)服務(wù)對(duì)應(yīng)一個(gè)數(shù)據(jù)庫(kù)這種模式，是微服務(wù)中的最核心最基本的模式，它體現(xiàn)了微服務(wù)最核心的思想：
拆分與解耦
一般來(lái)說(shuō)，微服務(wù)大部分時(shí)候，都會(huì)盡量采用一個(gè)服務(wù)一個(gè)數(shù)據(jù)庫(kù)的模式。
這里只說(shuō)了為什么要使用一個(gè)服務(wù)一個(gè)數(shù)據(jù)庫(kù)，而如何去分服務(wù)，如何去分?jǐn)?shù)據(jù)庫(kù)，它們是否還存在一些實(shí)踐上的妥協(xié)，這會(huì)在下一篇文章里仔細(xì)解析。
本文轉(zhuǎn)載自微信公眾號(hào)「四猿外」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系四猿外公眾號(hào)。
當(dāng)前名稱：“一學(xué)就會(huì)”微服務(wù)的架構(gòu)模式：一個(gè)服務(wù)一個(gè)數(shù)據(jù)庫(kù)模式之一
網(wǎng)頁(yè)鏈接：http://m.5511xx.com/article/dhcdcei.html
