其實在十多年前，“架構(gòu)師”并不是一個需求很大的職業(yè)，一來那時還沒有“全民App”級別的應用，除了三大門戶網(wǎng)站以外，其他的網(wǎng)上應用業(yè)務壓力并不大;二來也沒有現(xiàn)如今這么豐富的技術(shù)選型，幾乎清一色的PHP(坊間一直流傳著PHP是世界上最好的語言這個說法，我08年左右寫過一年P(guān)HP，那是我人生最黑暗的一年)。因此呢對所謂“架構(gòu)師?”的需求并不是很大，那些年的高可用架構(gòu)大體上就是這個樣子的:

在上面的反向代理集群之下，是眾多Web服務器構(gòu)成的高可用集群不過這些服務器中部署的應用卻是千篇一律，什么意思呢?大家看過火影忍者吧，里面主人公經(jīng)常用的一招叫“多重影分身之術(shù)”,將一個自己的本尊復制為成千，上萬個本尊。這里的服務器集群是-個道理，將一個巨無霸的單體應用復制成N個單體應用，組成一個分布式的服務集群。

傳統(tǒng)架構(gòu)之殤

隨著互聯(lián)網(wǎng)行業(yè)的飛速發(fā)展，個人的衣食住行幾乎全依賴各種APP來滿足。每天早上起來刷刷淘寶，地鐵，上用視頻app看個短句，- -天微信不離手，睡前刷個抖音- -不小心就刷到了后半夜，這些現(xiàn)象級全民應用層出不窮，所承接的用戶訪問量遠飛上古時期的門戶網(wǎng)站所能比擬的。在這種用戶量級下還要能夠滿足不斷變化的用戶請求，就像給飛行中的飛機換引擎，傳統(tǒng)的架構(gòu)模式已經(jīng)完全不能滿足業(yè)務發(fā)展的節(jié)奏。

我們來舉幾個“單體應用”中經(jīng)常被人詬病的幾個問題:

數(shù)據(jù)訪問雜亂

同一個war包內(nèi)，在數(shù)據(jù)訪問層面沒有劃分領域模型，比如說我們有User、Product和Order三張表， 對于不同的Service來說， 都通過直接訪問數(shù)據(jù)庫的方式來獲取數(shù)據(jù)。這種做法有幾個顯而易見的缺點:

1)數(shù)據(jù)模型變更

拿Order表來說，如果某一天我的Data Model發(fā)生了重大變更，比如說引入了“子訂單”的概念，原先的數(shù)據(jù)模型不能再很好地支持業(yè)務必須重構(gòu)Orderi訂單表，與此同時，還要兼容老的訂單結(jié)構(gòu)。這種情況下你能貿(mào)然改動數(shù)據(jù)模型嗎?恐怕不行，原因就是這個Order表被這個系統(tǒng)中的各個服務引用到了，你的改動可能會破壞其他服務的功能。

再舉個例子，Product表 以前存放的是單個的商品記錄，數(shù)據(jù)模型非常簡單，后面引入了SKU的概念，這就要對數(shù)據(jù)模型做重大改動,同時還可能影響到庫存模塊(以往庫存落在Product級別，現(xiàn)在要落地到SKU級別)。

以上都是我做電商業(yè)務中遇到的實際場景，對于傳統(tǒng)的應用結(jié)構(gòu)來說，一丁點數(shù)據(jù)結(jié)構(gòu)的改變都會引起很大的影響。如果數(shù)據(jù)模型的變動是必須的，那我們?nèi)绾谓鉀Q這種情況呢?很簡單，通過微服務架構(gòu)在各個服務之間做好隔離，將Data Model的影響帶來的業(yè)務復雜度隔離在當前微服務中，劃分好領域模型，上' 下游服務只要對接微服務的接口就可以，領域模型驅(qū)動不用依賴底層數(shù)據(jù)結(jié)構(gòu)的變更。

2) 底層組件變更

假如現(xiàn)在我要對Product表的數(shù)據(jù)訪問規(guī)則做一個變更，比如引入MyCat分庫分表，或者對熱點數(shù)據(jù)的訪問加上緩存讀寫的步驟。那么意味著.上下游所有訪問Product表的業(yè)務，都需要連帶著做同樣的改動。

再說個更極端的例子，以前我們使用的是Oracle,這家伙老貴了，領導層想要換成MySQL,即便我們沒有存儲過程的牽絆，那么這個變更也是極其巨大的，可謂牽一發(fā)而動全身。

理論，上來說，我們應該盡可能對業(yè)務層屏蔽底層組件的變更，在傳統(tǒng)的分布式應用中非常難以辦到，但是在微服務架構(gòu)下卻沒有那么困難，因為微服務間的訪問依賴API接口+業(yè)務模型，我們只要在當前微服務中把這種底層組件的變更處理好，對上下游其他服務來講這個變更其實是無感知的，因為在微服務接口暴露出的業(yè)務模型并不會有什么變化。

代碼復用帶來的維護成本

一整個應用的代碼摻雜在一塊，少不了各種“借鑒”，咱來細數(shù)下這里面的坑:

1)碼農(nóng)的傲嬌-rewrite code

作為一個驕傲的碼農(nóng)，看別人寫的代碼都跟屎一樣，只有自己出品的才是最好的。路見不平重構(gòu)一番，重構(gòu)不了的干脆重新寫個功能上一模一樣但是代碼結(jié)構(gòu)上更“優(yōu)雅”的接口出來，隨著時間的推移，這深藏于碼農(nóng)血液里的“rewrite code”基因，終究會把一個代碼庫編程一座屎山。

2)小改動沒什么大不了

“我就改了個if條件啊，誰知道你們也用了這個方法，這方法我當初就寫給自己用的啊!”

碼農(nóng)之間的撕逼沒有那么轟轟烈烈，反正最后歸根結(jié)底就是-改出bug來了。上面那個情景在傳統(tǒng)架構(gòu)的系統(tǒng)里很常見，當你的業(yè)務需要添加一個新功能，瞄了幾眼發(fā)現(xiàn)，咦?我去年寫的這個方法改一下正好能用，隨手改了個if條件。誰曾料想，隔壁組的程序媛妹子沒打招呼也用了這個方法，被你這么一改，把別人的服務搞掛了，又不好意思跟人妹子撕逼，只好自己背了個生產(chǎn)事故的鍋。

時不我待！糙快猛才是生產(chǎn)力

不知道大伙有沒有經(jīng)歷過互聯(lián)網(wǎng)公司的業(yè)務節(jié)奏，擁抱變化不是白叫的，研發(fā)團隊沉浸在996的福報中不能自拔。就像前面說的，為了支持不斷變化的新業(yè)務，開發(fā)團隊對系統(tǒng)的改造就像給飛行中飛機換引擎，既要讓飛機飛，又要保證完成任務，還得要快。因此我們提出了“糙快猛”的開發(fā)模式，它是繼瀑布模型、敏捷模型等等軟件工程理論之后的具有中國特色的互聯(lián)網(wǎng)研發(fā)模式。

面對一個屎山- -般的單war包應用，產(chǎn)品的發(fā)布節(jié)奏往往是以月甚至年來計，-個變更從評估到上線，拖個- -年半載是很常見的事情這種節(jié)奏對于互聯(lián)網(wǎng)公司來說，倒閉100次都夠了。

小步快跑

互聯(lián)網(wǎng)產(chǎn)品的迭代依靠小步快跑，盡快上線，盡快驗證業(yè)務模式,有問題立即調(diào)整，-切都是“快字當頭”。對于傳統(tǒng)應用來說，發(fā)布節(jié)奏只能劃歸到一個千年等-回的發(fā)布窗口，再小的變更都得耗上很長的時間，可能每次發(fā)布都要經(jīng)歷很耗時的全鏈路回歸測試。對微服務架構(gòu)來說完全不存在這個問題，每個微服務模塊由于職責邊界足夠清晰，規(guī)?？煽乇阌诳焖僮兏蜏y試，完全可以讓團隊自己制定發(fā)布窗口，即便是上線前的回歸測試也只局限在當前服務模塊

回滾

回滾對于傳統(tǒng)的單war包分布式系統(tǒng)來說是個噩夢，好不容易等到了發(fā)布窗口，各個團隊牟足了勁把所有變更都發(fā)布了出去，結(jié)果因為其中某個小改動引發(fā)的問題，導致全部回滾。又要苦苦等待下一個發(fā)布窗口。

在微服務架構(gòu)中，回滾只局限在某個微服務的范圍內(nèi)，只要把出問題的應用回滾就好了，不會影響上下游其他應用的發(fā)布節(jié)奏。

技術(shù)前沿拓展

前端開發(fā)，你的認知不能僅局限于技術(shù)內(nèi)，需要發(fā)散思維了解技術(shù)圈的前沿知識。細心的人會發(fā)現(xiàn)，開發(fā)內(nèi)部工具的過程中，大量的頁面、場景、組件等在不斷重復，這種重復造輪子的工作，浪費工程師的大量時間。

介紹一款程序員都應該知道的軟件JNPF快速開發(fā)平臺，很多人都嘗試用過它，它是功能的集大成者，任何信息化系統(tǒng)都可以基于它開發(fā)出來。

這是一個基于 Java Boot/.Net Core 構(gòu)建的簡單、跨平臺快速開發(fā)框架。前后端封裝了上千個常用類，方便擴展；集成了代碼生成器，支持前后端業(yè)務代碼生成，實現(xiàn)快速開發(fā)，提升工作效率；框架集成了表單、報表、圖表、大屏等各種常用的 Demo 方便直接使用；后端框架支持 Vue2、Vue3。如果你有閑暇時間，可以做個知識拓展。

看完本文如果覺得有用，記得點個贊支持，收藏起來說不定哪天就用上啦～文章來源地址http://www.zghlxwxcb.cn/news/detail-802075.html

到了這里，關(guān)于為什么要將應用微服務化？的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！