[[392936]]

不管你喜不喜歡微服務，現(xiàn)在微服務無疑已經(jīng)是程序員們繞不過去的話題了。無論你是想把目前的架構(gòu)改成微服務，還是你要出去面試高級一點的崗位，需要深入理解微服務。

提起微服務，很多程序員對它是又愛又恨，想學微服務不知道如何開始，學了一點之后，又找不到地方去實踐?？傊褪歉杏X微服務遙不可及，又很難駕馭。

首先要明白的是微服務是有套路的，而這些套路基本上解決了微服務結(jié)構(gòu)面臨的幾乎所有重要問題。

這些套路就是微服務自己的架構(gòu)模式

如果我們能深入了解這些模式的其來龍去脈，就可以理解了微服務絕大部分內(nèi)容。學習快速，實用價值也極大。

1. 微服務最基本的模式

這篇文章先來講第一個最基本的模式，這個模式我估計需要三篇文章才能講透，這是上篇。打算中篇寫實踐，下篇寫問題。

希望大家能學的輕松。

微服務最基本的模式就是：

一個服務一個數(shù)據(jù)庫

上圖就是一個最簡單的微服務模式了。

一個服務一個數(shù)據(jù)庫這種模式，是微服務體系結(jié)構(gòu)中的最基礎也是最核心的模式?？粗唵危?，這個模式蘊含著微服務的最基本的思想。

要弄清楚一個服務一個數(shù)據(jù)庫這種模式，首先我們就需要問一下，為什么我們要搞微服務。

2. 傳統(tǒng)系統(tǒng)的問題

在談及微服務的時候，和微服務對應的概念叫做單體系統(tǒng)( Monolithic application )。簡單說，微服務是為了解決單體系統(tǒng)的問題才衍生出來的。單體系統(tǒng)結(jié)構(gòu)如下圖:

那么這種單體結(jié)構(gòu)出現(xiàn)了什么問題，導致現(xiàn)在大家必須開口閉口微服務了呢?

3. 單體系統(tǒng)太大了

最首要的一個原因就是應用系統(tǒng)太大。而由于應用系統(tǒng)的過于龐大，如果僅是單體系統(tǒng)的話，就引發(fā)了各種各樣的問題，體現(xiàn)在以下三個方面：

3.1. 系統(tǒng)本身業(yè)務復雜，模塊眾多

系統(tǒng)隨著時間的發(fā)展，業(yè)務需求越來越多。而為了滿足這些需求，就導致整個系統(tǒng)的模塊越來越多。而系統(tǒng)模塊越來越多，就導致能理解整套系統(tǒng)的人變得越來越少，直到最后沒有人可以理解整套系統(tǒng)。

3.2. 系統(tǒng)的代碼庫非常龐大

代碼量也會隨著系統(tǒng)的增大而增大，代碼量的龐大影響了整個開發(fā)流程，會導致整個開發(fā)成本變得很高。

• 首先，代碼量大，依賴關系復雜，所以對新接手的開發(fā)人員來說，配置開發(fā)環(huán)境非常耗費精力。
• 其次，代碼量大，加載這些代碼和對應的依賴需要的內(nèi)存就多，所以就會導致開發(fā)人員的 IDE 運行非常緩慢，導致編輯代碼都很麻煩。
• 再次，代碼量大，如果要把整個代碼編譯打包，需要的內(nèi)存也很多，所以也會導致功能開發(fā)完成后，對系統(tǒng)的構(gòu)建會非常緩慢，導致整個構(gòu)建的時間非常漫長。
• 再有，代碼量大，幾乎沒人能對整體代碼有比較深入的了解，哪怕可能其中一個要改動的功能，都會因為過于復雜導致開發(fā)人員理解不深入。而這些不深入的理解又會讓開發(fā)人員不能使用最佳的方式去做功能開發(fā)，從而導致隱藏的 bug。

3.3. 技術團隊變得非常龐大

由于功能模塊越來越多，這就需要越來越多的開發(fā)人員去開發(fā)和維護這套系統(tǒng)。但是，這些開發(fā)人員都是面對的同一套代碼庫，雖然可以搞分支，大家各搞各的?？墒且坏┬枰洗a，發(fā)布上線，就是場噩夢。

各種代碼沖突，代碼丟失，都可能在上線的時候發(fā)生。

不僅如此，由于顧慮代碼丟失和沖突，就需要在上線前，進行足量的測試，而這些測試又需要投入巨大的時間成本。

但是，現(xiàn)在都講敏捷開發(fā)，很可能在還沒上線的時候，后續(xù)的業(yè)務需求又接踵而至，簡直要命。

4. 業(yè)務需求的個性化

搞微服務，還有一個很重要的原因是業(yè)務需求的個性化和顆?；?。

隨著業(yè)務的發(fā)展，不管是由于市場競爭還是本身發(fā)展的需要，勢必需要對本身業(yè)務模型的深度挖掘以及提高用戶使用系統(tǒng)的各種體驗。而基于此類種種，就勢必要把系統(tǒng)的各個功能模塊做深做透。

這又會引發(fā)幾個新的問題:

4.1. 系統(tǒng)功能模塊可能變得更多更雜

系統(tǒng)功能模塊可能被不斷拆分成了更細碎的模塊，以致可能碎成了顆粒。而由于功能變得更碎更顆粒了，就會讓產(chǎn)品經(jīng)理們更容易的提出一些非常細致的業(yè)務需求。

這些非常細致的需求，很可能會造成頻繁的功能修改和上線要求。而這些無窮盡的快速需求相對整體龐大的系統(tǒng)上線和開發(fā)人員的疲于奔命形成了最激烈的沖突。

4.2. 功能模塊對系統(tǒng)的技術要求出現(xiàn)了沖突

比如，不同的功能模塊，訂單模塊和支付模塊。訂單模塊就希望系統(tǒng)能盡可能的能同時處理大量的訂單，甚至可以有一定的容錯性，出問題了砍單就可以了。

但是支付模塊則不一樣，支付模塊希望系統(tǒng)能盡量的穩(wěn)定，并且必須對準確度要求極高，幾乎沒有容錯的空間。

同樣的，在同樣的支付模塊中(根據(jù)系統(tǒng)模塊劃分而定)，可能同時存在本地賬戶轉(zhuǎn)賬和三方渠道支付，本地賬戶轉(zhuǎn)賬可能需要即時，要求極高的響應時間。但是對于第三方支付，則可以有一定的響應時間容忍度。

如果系統(tǒng)本身是個單體系統(tǒng)，就勢必要求開發(fā)人員對整套系統(tǒng)做一定的妥協(xié)，對沖突的技術需求做出一定的權(quán)衡。而這種權(quán)衡很可能影響的就是系統(tǒng)整體的體驗度。

4.3. 系統(tǒng)模塊對服務器的要求出現(xiàn)了沖突

由于功能的深耕細作，則勢必會出現(xiàn)性能上的不同需求。

比如，系統(tǒng)的訂單模塊，個人下單可能會被頻頻訪問，此時，就需要系統(tǒng)的集群多一些，去處理這些大規(guī)模的訪問。但是，同樣的功能模塊里，可能還存在一些企業(yè)團購需求，他們沒有那么大的訪問量，就不需要那么多的服務器集群。

又比如，用戶評論截圖，可能需要大量的數(shù)據(jù)存儲。但是，同樣的，針對用戶的個性化推薦就可能需要大規(guī)模的密集運算。

除了上面說的，系統(tǒng)龐大引發(fā)的問題帶來的一些附屬問題：

4.4. 故障的連鎖反應問題

單體系統(tǒng)從技術上，各個模塊是耦合在一起的。在實際運行里，很可能就會出現(xiàn)一處故障導致整個系統(tǒng)崩盤的現(xiàn)象。

比如，不常用的一個 XX 功能出現(xiàn)了內(nèi)存泄露，導致整個系統(tǒng)全部不可用了。

4.5. 系統(tǒng)的技術鎖死問題

坦白來說，你得承認在編程里，沒有一種語言是完美的，也沒有一個數(shù)據(jù)庫是萬能的。

比如，Java 做科學計算就沒有 Python 那么方便高效。比如，我們需要存儲很復雜的對象關系的時候，MySQL、Oracle 就不如任何一種圖形數(shù)據(jù)庫。

所以，系統(tǒng)越復雜，需要不同技術的概率就越高。但是又由于系統(tǒng)的復雜，引入新技術的風險也就越大。所以，新技術的使用非常困難。

同時，系統(tǒng)龐大后，如果一些組件，甚至語言 SDK 本身的問題如果需要升級，也是一件既繁瑣，又充滿風險的事情，所以，技術版本升級也非常困難。

綜上，對于傳統(tǒng)的單體應用來講，系統(tǒng)龐大引發(fā)的技術問題，業(yè)務發(fā)展引發(fā)的需求沖突問題……都是無法單憑單體系統(tǒng)的架構(gòu)思想就可以解決的。

那為什么 SOA 也不能解決這些問題呢?

5. SOA 的問題

咱們先來看看SOA的結(jié)構(gòu)

可以看到 SOA 架構(gòu)中有個 ESB(企業(yè)服務總線)。這個 ESB 就是專門用于 SOA 的服務和服務之間的互動，是 SOA 必備的基礎技術設施。

正因為 SOA 有了服務總線的思想，就注定 SOA 切分的服務不可能太細，因為服務出現(xiàn)的越多，這個服務總線就最終會變成一個整體系統(tǒng)的瓶頸。

SOA 的服務切分規(guī)模本身就受到了限制，這個限制就會帶來以下的問題:

1. 切分不夠細——我們說過，我們的主要問題根源是系統(tǒng)過于龐大，并且還堆在了一起。如果我們切分不夠細，那么可能的結(jié)果就會變?yōu)椋瑥囊粋€很大的系統(tǒng)被切分為了寥寥幾個也很大的系統(tǒng)，最終沒有解決問題不說，還可能因為系統(tǒng)變成了不同的分布式服務，又引入了新的分布式系統(tǒng)本身所帶來的問題。
2. ESB 本身就可能成為一個龐大無比的系統(tǒng)怪獸——ESB 作為 SOA 的基礎設施，它本身就已經(jīng)足夠復雜，很可能由于業(yè)務的發(fā)展，它自己也變成了一個恐怖的系統(tǒng)怪物。從而讓開發(fā)人員不僅需要維護原來的系統(tǒng)，很可能還需要為如何維護和修改ESB本身而傷透腦筋。

所以，可以看出來，SOA這種思維方式和架構(gòu)實現(xiàn)本身不足以解決龐大單體系統(tǒng)帶來的問題。

6. 為什么需要服務

回到我們的微服務的話題。我們知道了問題的根源，我們就需要著手解決這些問題。

首先，既然問題是由于系統(tǒng)的龐大復雜引起的，那么我們就可以參考軟件里很普遍的解決思想：分而克之。

無論一個系統(tǒng)有多大，如果我們將其拆的足夠小，就可以把一個復雜的大系統(tǒng)拆分成許多個小系統(tǒng)，再讓這分解出來的小系統(tǒng)通過對外提供服務的手段，將他們再聚合成一套大的完整體系，從結(jié)果上，就等價為了原來的復雜的大系統(tǒng)了。而這，就是微服務的最樸實的思想。

所以，微服務思想核心有兩個:

• 把系統(tǒng)拆分成不同的部分
• 這些部分要足夠小

微服務這樣做帶來了幾個好處:

1. 無論多大多復雜的系統(tǒng)，我只要能拆，會拆，就能把問題簡化，從而不用懼怕系統(tǒng)變得復雜。
2. 拆分出來的服務只要足夠小，那么無論開發(fā)、部署、運維上，都能得到無數(shù)原來因為系統(tǒng)龐大而無法獲得的好處：修改代碼可能變得簡單了，測試和運行也變得容易了……
3. 拆分出來的服務能各自獨立發(fā)展，不會互相制約。原來系統(tǒng)是單體系統(tǒng)的時候，模塊之間由于技術上的耦合，導致無法自由自在的選用最適合當前功能模塊的技術，也不能隨心所欲的根據(jù)當前功能模塊的負載情況去彈性的安排服務器。
4. 故障天然被隔離開了。我們把系統(tǒng)切分成了服務，每個服務都有自己的進程或者服務器，這樣故障從物理層面就被隔離開了，從而避免了一處不重要的功能故障導致整個系統(tǒng)崩盤。我們只需要把核心的功能弄的足夠健壯，即使非核心功能有了問題，也不會造成太大的損失。

所以，一套巨大的系統(tǒng)，由于本身的臃腫和復雜，就可能會要對其自身進行拆分。而這些拆分，根據(jù)一些指導原則，將其拆解的夠小，夠簡單，那么，拆解后帶來的效益是很可觀的。

7. 為什么需要拆庫

服務已經(jīng)拆了，已經(jīng)獲得那么大的好處了。

“但是為什么數(shù)據(jù)庫也必須要拆?”——這其實是很多使用微服務的同學最疑惑的問題了。

數(shù)據(jù)庫拆分不拆分本質(zhì)上其實就是數(shù)據(jù)共享的問題。而一個服務一個庫本身的觀念，其實就是盡最大程度的避免數(shù)據(jù)的共享。

數(shù)據(jù)共享會帶來如下幾個問題:

7.1. 技術實現(xiàn)依然可能耦合

因為沒有拆分數(shù)據(jù)庫，所以，很可能一個本來應該獨立出來的服務模塊，必須依賴于另外的服務模塊，而這和我們拆分服務的初衷出現(xiàn)了沖突。

比如，訂單服務和個性化推薦服務，很可能都需要訪問訂單相關數(shù)據(jù)。此時，如果不拆數(shù)據(jù)庫，則很可能由于訂單業(yè)務需求導致的訂單表結(jié)構(gòu)的修改，倒逼個性化推薦服務也要跟著修改。

7.2. 底層數(shù)據(jù)的過度暴露

還是上面訂單服務和個性化推薦服務的例子，個性化推薦很可能只是需要一些用戶 id、訂單類別之類的東西，但是由于數(shù)據(jù)庫是共享的，很可能開放的就是訂單表的全部數(shù)據(jù)，而這些數(shù)據(jù)有很多算是敏感數(shù)據(jù)，應該被隱藏的，現(xiàn)在則被暴露出去了。

7.3. 無必要的數(shù)據(jù)訪問競爭

因為是同一個數(shù)據(jù)庫，這勢必會造成對共享數(shù)據(jù)的競爭性訪問，而這些競爭性訪問則會大大影響業(yè)務模塊的彈性部署。比如，訂單模塊很可能由于個性化推薦的一些定時批量查詢，被影響了其能承載的并發(fā)數(shù)據(jù)量。

所以，看出來了吧，分庫是必須要考慮進微服務整個體系結(jié)構(gòu)的。

8. 最后留個尾巴

每一個服務對應一個數(shù)據(jù)庫這種模式，是微服務中的最核心最基本的模式，它體現(xiàn)了微服務最核心的思想：

拆分與解耦

一般來說，微服務大部分時候，都會盡量采用一個服務一個數(shù)據(jù)庫的模式。

這里只說了為什么要使用一個服務一個數(shù)據(jù)庫，而如何去分服務，如何去分數(shù)據(jù)庫，它們是否還存在一些實踐上的妥協(xié)，這會在下一篇文章里仔細解析。

本文轉(zhuǎn)載自微信公眾號「四猿外」，可以通過以下二維碼關注。轉(zhuǎn)載本文請聯(lián)系四猿外公眾號。