[[336304]]

博客網(wǎng)址：httpswww.itzhai.com 

有不少朋友或同事都問過我這個(gè)問題：為什么我們要搞微服務(wù)架構(gòu)，一個(gè)項(xiàng)目把代碼從頭擼到尾不是很方便嗎，開發(fā)更快速，部署也容易。而且一提起微服務(wù)，涉及的技術(shù)就一大堆，好像幾輩子也學(xué)不完。

 

怎么解答這個(gè)問題呢?我想還是通過架構(gòu)的發(fā)展變遷史來說起，為什么會(huì)出現(xiàn)現(xiàn)在的各種架構(gòu)。只有從整體上了解了架構(gòu)的脈絡(luò)，我們才好更加全方位的評(píng)估一個(gè)架構(gòu)。為此，我們有理由來梳理一下架構(gòu)發(fā)展的來龍去脈，究竟為何會(huì)出現(xiàn)微服務(wù)，主要解決什么問題。微服務(wù)架構(gòu)是最先進(jìn)的架構(gòu)嗎?

本文我們來探索一下架構(gòu)的變遷。以及從Java工程師的角度來看技術(shù)的發(fā)展，了解我們?cè)谟懻撐⒎?wù)的時(shí)候，都會(huì)涉及哪些技術(shù)。微服務(wù)的下一步將如何發(fā)展。閱讀完本文，你將了解到：

• 軟件架構(gòu)的發(fā)展史
• SOA架構(gòu)與MSA架構(gòu)的區(qū)別
• 微服務(wù)架構(gòu)核心關(guān)注的問題是什么
• 如何做微服務(wù)架構(gòu)的技術(shù)選型
• 目前架構(gòu)正在朝著什么方向發(fā)展
• 架構(gòu)升級(jí)與業(yè)務(wù)發(fā)展的關(guān)系，一定要用最前衛(wèi)的架構(gòu)技術(shù)嗎?什么樣的架構(gòu)才是好的架構(gòu)
• 微服務(wù)的難點(diǎn)是什么，這里主要留給大家思考，會(huì)在后續(xù)文章中進(jìn)一步講解

首先我們還是回顧一下架構(gòu)的整體發(fā)展史。

0、架構(gòu)發(fā)展史

架構(gòu)也是隨著其缺陷不斷演變而來的，下面是粗略的架構(gòu)演變史：

 

70~80s：集中式(大型機(jī))

上世紀(jì)70年代和80年代，大型機(jī)是計(jì)算機(jī)的工作方式。

問題所在：最初的大型計(jì)算機(jī)使用打孔卡，并且大多數(shù)計(jì)算都在批處理過程中進(jìn)行。沒有在線處理，并且延遲為100%，因?yàn)闆]有實(shí)時(shí)處理。

架構(gòu)演變：隨著在線處理和用戶界面終端的推出，大型機(jī)范式發(fā)生了一些變化。

90s：CS架構(gòu)(分布式)

客戶端/服務(wù)器體系結(jié)構(gòu)將大多數(shù)邏輯放在服務(wù)器端，并將某些處理放在客戶端上。

問題所在：在該體系結(jié)構(gòu)的最初幾年中，開發(fā)社區(qū)仍在使用與大型機(jī)開發(fā)相同的過程，采用單層原則來為客戶端/服務(wù)器編寫軟件，從而產(chǎn)生了諸如意大利面條代碼和Blob之類的反模式。

架構(gòu)演變：引入了一項(xiàng)稱為面向?qū)ο蟪绦蛟O(shè)計(jì)(OOP)的重大改進(jìn);

客戶/服務(wù)器模型基于三層體系結(jié)構(gòu)，包括展示層，業(yè)務(wù)邏輯層和數(shù)據(jù)層。但是大多數(shù)應(yīng)用程序是使用兩層模型編寫的，胖客戶端將所有展示、業(yè)務(wù)和數(shù)據(jù)訪問邏輯封裝在一起，直接訪問數(shù)據(jù)庫。盡管業(yè)界已經(jīng)開始討論將展示與業(yè)務(wù)與數(shù)據(jù)訪問分開的必要性，但是這種做法直到基于Internet的應(yīng)用程序問世才真正變得至關(guān)重要。

2000：去中心化(Internet)

在90年代中期，互聯(lián)網(wǎng)革命發(fā)生了，Web瀏覽器成為客戶端軟件，而Web和應(yīng)用程序服務(wù)器托管所有處理和邏輯。

問題所在：開發(fā)人員仍在將軟件設(shè)計(jì)為緊密耦合的設(shè)計(jì)，從而導(dǎo)致混亂和其他反模式。

架構(gòu)演變：作為解決辦法，業(yè)界提出了三層體系結(jié)構(gòu)和實(shí)踐，例如領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)，企業(yè)集成模式(EIP)，SOA和松耦合技術(shù)。

2006：云托管

21世紀(jì)前10年見證了云計(jì)算作為服務(wù)托管形式的重大改變。應(yīng)用程序需要的一些能力，云計(jì)算平臺(tái)托管了基礎(chǔ)功能：分布式計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)以及計(jì)算等，與傳統(tǒng)的基礎(chǔ)架構(gòu)相比，云托管的方式能更好的控制成本。

問題所在：它誘使將尚未設(shè)計(jì)用于彈性分布式架構(gòu)的遺留應(yīng)用程序直接遷移和遷移到云中，從而產(chǎn)生了單體地獄這種反模式。

遷移到云還給行業(yè)帶來了管理第三方庫和技術(shù)上的應(yīng)用程序依賴項(xiàng)的挑戰(zhàn)。沒有足夠的標(biāo)準(zhǔn)來選擇第三方工具，我們開始看到一些依賴地獄。另外服務(wù)擴(kuò)容也是一個(gè)問題。

架構(gòu)演變：了應(yīng)對(duì)這些挑戰(zhàn)，業(yè)界提出了新的架構(gòu)模式，例如微服務(wù)和12要素應(yīng)用程序[8]，彈性服務(wù)。

2014：微服務(wù)

諸如DDD和EIP之類的軟件設(shè)計(jì)自2003年左右就已經(jīng)開始實(shí)踐起來了，此時(shí)一些團(tuán)隊(duì)將應(yīng)用程序開發(fā)為模塊化服務(wù)，但是傳統(tǒng)的基礎(chǔ)結(jié)構(gòu)(如Java應(yīng)用程序的重量級(jí)J2EE應(yīng)用程序服務(wù)器和.NET應(yīng)用程序的IIS)對(duì)模塊化部署并沒有幫助。

隨著云托管的出現(xiàn)，尤其是諸如Heroku和Cloud Foundry之類的PaaS產(chǎn)品的出現(xiàn)，開發(fā)人員社區(qū)擁有了真正的模塊化部署和可擴(kuò)展業(yè)務(wù)應(yīng)用所需的一切。這引起了微服務(wù)的發(fā)展。微服務(wù)為打造細(xì)粒度、可重用的功能和非功能服務(wù)提供了可能性。

問題所在：原本的單體系統(tǒng)、未被設(shè)計(jì)為微服務(wù)的傳統(tǒng)應(yīng)用程序開始被蠶食，試圖迫使它們進(jìn)入微服務(wù)體系結(jié)構(gòu)，由于拆解的不當(dāng)，從而導(dǎo)致了被稱為微單體的反模式。單體和微服務(wù)是兩種不同的模式，后者并不總是可以替代前者。如果我們不小心的話，最終可能會(huì)創(chuàng)建緊密耦合，混雜的微服務(wù)。微服務(wù)劇增的另一個(gè)不希望出現(xiàn)的副作用是所謂的“死亡星球”的反模式。

架構(gòu)演變：諸如服務(wù)網(wǎng)格，邊車，服務(wù)編排和容器之類的新興架構(gòu)模式可以有效地防御基于云的世界中的瀆職行為。隨著云平臺(tái)的出現(xiàn)，特別是像Kubernetes這樣的容器編排技術(shù)，服務(wù)網(wǎng)格已經(jīng)引起了人們的關(guān)注。服務(wù)網(wǎng)格是應(yīng)用程序服務(wù)之間的橋梁，可添加其他功能，例如流量控制，服務(wù)發(fā)現(xiàn)，負(fù)載平衡，彈性，可觀察性，安全性等。

幾種架構(gòu)反模式[3]說明

• 單體地獄[4]：
• 好處：早期開發(fā)簡(jiǎn)單、易于對(duì)程序做重大更改、直接測(cè)試、直接部署、易于擴(kuò)展;
• 缺點(diǎn)：隨著業(yè)務(wù)增長(zhǎng)，暴露問題：復(fù)雜度高、開發(fā)效率低下、從提交到部署耗時(shí)長(zhǎng)、伸縮性差、技術(shù)棧過時(shí)難以升級(jí)、缺乏故障隔離導(dǎo)致一個(gè)小功能可能會(huì)影響整個(gè)系統(tǒng);
• 微單體[5]：
• 一種非彈性和不可擴(kuò)展的微服務(wù)系統(tǒng)，即所謂的微單體;單體和微服務(wù)是兩種不同的模式，后者并不總是可以替代前者。如果我們不小心的話，最終可能會(huì)創(chuàng)建緊密耦合，混雜的微服務(wù)(微單體)。我們應(yīng)該根據(jù)應(yīng)用程序功能的業(yè)務(wù)和可伸縮性要求做抉擇;
• 積木塔：?jiǎn)误w應(yīng)用程序類似于積木塔：您永遠(yuǎn)不知道發(fā)生故障時(shí)哪塊磚可能會(huì)出問題。由于該應(yīng)用程序的所有模塊都在同一進(jìn)程中運(yùn)行，因此，如果某個(gè)模塊受到錯(cuò)誤的影響，則會(huì)降低整個(gè)過程，從而影響整個(gè)應(yīng)用程序。在完成故障排除之前，您可能會(huì)失去數(shù)百甚至數(shù)千個(gè)商機(jī);
• 科學(xué)怪人[7]：科學(xué)怪人是一部著名的美國電影，講述了一個(gè)天才科學(xué)家創(chuàng)造了一個(gè)怪物最終被其毀滅的故事。Istio 團(tuán)隊(duì)為以它來自嘲。Istio 本想扮演上帝一般的角色(統(tǒng)一 Service Mesh 江湖，成為微服務(wù)架構(gòu)的事實(shí)標(biāo)準(zhǔn))，卻因?yàn)檫^度設(shè)計(jì)與現(xiàn)實(shí)脫離，成為了一個(gè)怪獸(monster)。因此，重構(gòu)的第一階段，就是從肢解怪獸開始，把微服務(wù)架構(gòu)重新改回了單體架構(gòu)，但是內(nèi)部模塊劃分還是很清晰的;
• 方輪：重新發(fā)明方的輪子，已經(jīng)有了一個(gè)很好的方案，又搞一個(gè)方案來替代它;
• 死亡星球[6]：
• 在服務(wù)交互和服務(wù)到服務(wù)的安全性(身份驗(yàn)證和授權(quán))方面，如果沒有治理模型，微服務(wù)的泛濫通常會(huì)導(dǎo)致任何服務(wù)都可以隨意調(diào)用任何其他服務(wù)的情況。就有可能出現(xiàn)想死亡星球那樣的調(diào)用視圖，異常復(fù)雜。諸如服務(wù)網(wǎng)格，邊車，服務(wù)編排和容器之類的新興架構(gòu)模式可以有效地防御基于云的世界中的瀆職行為;
• 意大利面條式的設(shè)計(jì)：面條之間互相纏繞在一起，很難梳理清楚它們之間的關(guān)系。意大利面式的設(shè)計(jì)很形象的說明了軟件開發(fā)中的這種現(xiàn)象：系統(tǒng)很難維護(hù)，各種功能邏輯纏繞在一起，沒有清晰的模塊和層次關(guān)系;
• The Blob：表示的是一個(gè)類型具有了過多的職能，導(dǎo)致其過于龐大，最后使代碼難以維護(hù)。

架構(gòu)演變步驟

一般的，每一個(gè)架構(gòu)的出現(xiàn)，不是一蹴而就的，都會(huì)經(jīng)歷以下幾個(gè)過程：

• 引入新模型;
• 最佳架構(gòu)實(shí)踐未知或者不存在;
• 反模式，技術(shù)債務(wù)劇增;
• 行業(yè)開發(fā)新的體系結(jié)構(gòu)以適應(yīng)新的范式;
• 團(tuán)隊(duì)研究并采用新的標(biāo)準(zhǔn)架構(gòu);

下面我們將于Java工程師的角度來觀察架構(gòu)的大致發(fā)展史。

1、第一階段：學(xué)好SSH框架，走遍天下都不怕

早期，大部分IT系統(tǒng)都是單體系統(tǒng)，例如傳統(tǒng)的SSH架構(gòu)，此時(shí)前后端也沒有分離，UI組件也包含在了控制層：

 

這一時(shí)期服務(wù)的對(duì)象主要是傳統(tǒng)企業(yè)，并發(fā)不高，主要是業(yè)務(wù)開發(fā)，這種開發(fā)方式很方便。當(dāng)年剛畢業(yè)的時(shí)候我還和同學(xué)在納悶，那些互聯(lián)網(wǎng)公司是不是也用SSH框架。

其實(shí)真實(shí)情況呢?隨著互聯(lián)網(wǎng)企業(yè)的崛起，DAU持續(xù)增長(zhǎng)，業(yè)務(wù)并發(fā)量也逐漸增高，SSH架構(gòu)單JVM部署這種簡(jiǎn)單的方式并不能滿足高并發(fā)場(chǎng)景，我們需要一種能夠支持給系統(tǒng)進(jìn)行水平擴(kuò)展的架構(gòu)。

2、第二階段：分布式系統(tǒng)

為了方便給系統(tǒng)擴(kuò)容，以及增加系統(tǒng)的復(fù)用性，出現(xiàn)分布式系統(tǒng)。

另一方面，系統(tǒng)模塊快速膨脹，為了降低系統(tǒng)內(nèi)部的復(fù)雜度，于是對(duì)系統(tǒng)模塊進(jìn)行拆解，分布到不同的系統(tǒng)中，降低模塊耦合，加快迭代速度。

業(yè)界提出了三層體系結(jié)構(gòu)和實(shí)踐，例如域驅(qū)動(dòng)設(shè)計(jì)(DDD)，企業(yè)集成模式(EIP)，SOA和松耦合技術(shù)。

3、SOA

早期的分布式系統(tǒng)是基于面向服務(wù)的架構(gòu)SOA。SOA是微服務(wù)的前身，主要是為了擺脫單體應(yīng)用的問題，達(dá)到以下效果：

• 充分利用現(xiàn)有的基礎(chǔ)設(shè)施;
• SOA體系結(jié)構(gòu)依賴于消息傳遞(AMQP，MSMQ)和SOAP作為主要的遠(yuǎn)程訪問協(xié)議。
• 快速響應(yīng)業(yè)務(wù)變化;

根據(jù)一位印度小哥的介紹，我畫了下面這張SOA的架構(gòu)圖：

 

也就是說，異構(gòu)系統(tǒng)，也可以通過消息中間件的協(xié)議轉(zhuǎn)換進(jìn)行相互調(diào)用。一般這個(gè)消息中間件通常是用ESB企業(yè)總線實(shí)現(xiàn)的。ESB 是傳統(tǒng)中間件技術(shù)與XML、Web服務(wù)等技術(shù)相互結(jié)合的產(chǎn)物，消除了不同應(yīng)用之間的技術(shù)差異，讓不同的應(yīng)用服務(wù)器協(xié)調(diào)運(yùn)作，實(shí)現(xiàn)了不同服務(wù)之間的通信與整合。不同公司提供了不同的ESB中間件實(shí)現(xiàn)。

但是其表現(xiàn)并不佳，主要是其太重了，主要體現(xiàn)在：

• SOA更強(qiáng)調(diào)系統(tǒng)集成的規(guī)范與便利性，對(duì)業(yè)務(wù)服務(wù)本身沒有過多要求，一般服務(wù)拆分粒度不夠細(xì)，模塊間仍然會(huì)有比較大的耦合，迭代困難;
• SOA服務(wù)之間的通信相對(duì)比較復(fù)雜，重量級(jí)。WebService中常用的SOAP通信協(xié)議，通常使用XML格式進(jìn)行通信，數(shù)據(jù)冗余，協(xié)議過重;EBS通過總線隱藏內(nèi)部復(fù)雜性，其中心化管理模式，系統(tǒng)變更，對(duì)系統(tǒng)的影響范圍會(huì)擴(kuò)大。
• 在SOA模型下通常只有一個(gè)數(shù)據(jù)庫，限制了系統(tǒng)的擴(kuò)展性;
• 服務(wù)化管理和治理設(shè)施不完善;

后來逐漸演變?yōu)榱爽F(xiàn)在的MSA(Micro-Service Archeticture 微服務(wù)架構(gòu))，從而實(shí)現(xiàn)了更加松耦合以及更加靈活的系統(tǒng)。

4、微服務(wù)(MSA)

微服務(wù)使用各個(gè)子服務(wù)控制模塊的思想代替SOA中的總線。服務(wù)控制模塊通常至少包含：服務(wù)注冊(cè)與發(fā)布、路由、代理。

微服務(wù)與SOA的對(duì)比

• 目的：
• SOA強(qiáng)調(diào)異構(gòu)服務(wù)之間的協(xié)作和契約，強(qiáng)調(diào)有效集成，最大化應(yīng)用程序服務(wù)的可重用性;
• 微服務(wù)的目的是拆分解耦應(yīng)用，專注去耦合，讓不同不同的業(yè)務(wù)團(tuán)隊(duì)服務(wù)不同的微服務(wù)，專人專事，縮小迭代影響范圍，讓微服務(wù)更容易進(jìn)行水平擴(kuò)展;微服務(wù)遵循單一職責(zé)，是一種克服系統(tǒng)復(fù)雜性的分解技術(shù)。如果你覺得你的某個(gè)微服務(wù)很復(fù)雜，那么考慮看看是否拆分的不夠細(xì)?也正是因?yàn)檫@種拆分，本質(zhì)上增強(qiáng)了安全性和故障隔離;
• 部署方式：
• SOA服務(wù)不多，一般打包后直接通過war形式部署到服務(wù)器;
• 微服務(wù)由于數(shù)量眾多，需要實(shí)現(xiàn)快速擴(kuò)容和縮容，一般借助容器化技術(shù)來實(shí)現(xiàn)部署，微服務(wù)之間獨(dú)立部署，互不影響;
• 服務(wù)粒度：
• SOA對(duì)粒度無要求，通常是粗粒度的，更強(qiáng)調(diào)的是接口的規(guī)范化;
• 微服務(wù)提倡進(jìn)行細(xì)粒度的拆分，保證服務(wù)職責(zé)的單一。

 

4.1、微服務(wù)的優(yōu)勢(shì)

4.1.1、方便擴(kuò)容與保證服務(wù)可伸縮性

正是因?yàn)槲⒎?wù)的拆解，讓我們?cè)黾恿讼到y(tǒng)的安全性和故障隔離，可以讓我們針對(duì)不同的服務(wù)，實(shí)施不同的擴(kuò)容和存儲(chǔ)技術(shù)。

例如，一些微服務(wù)可能使用關(guān)系數(shù)據(jù)庫，而另一些可能使用NoSQL數(shù)據(jù)庫甚至掛載的文件系統(tǒng)。以這種方式構(gòu)建應(yīng)用程序增加了團(tuán)隊(duì)構(gòu)建應(yīng)用程序的可伸縮性。

4.1.2、降低耦合，利于團(tuán)隊(duì)協(xié)作與版本快速更新

在SOA系統(tǒng)，或者是傳統(tǒng)的單體系統(tǒng)中，使用一個(gè)項(xiàng)目的時(shí)候，通常會(huì)有一個(gè)大團(tuán)隊(duì)的人在同一個(gè)項(xiàng)目的同一個(gè)分支上工作，并且總是互相干擾，出現(xiàn)各種代碼沖突，隨著代碼增長(zhǎng)，開發(fā)速度會(huì)呈現(xiàn)指數(shù)級(jí)增長(zhǎng)。這是我們以前遇到過的問題，特別頭疼，后來花了很大的精力對(duì)系統(tǒng)做了服務(wù)化改造拆分。

當(dāng)然主導(dǎo)這個(gè)服務(wù)化改造也是需要申請(qǐng)不少資源的，即使沒有新的業(yè)務(wù)上線。為了讓老板認(rèn)為我們正在做的改造是存在價(jià)值的，當(dāng)時(shí)還寫了改造前后的各種利弊對(duì)比。這是很重要的，我們總不能無故的去改造一個(gè)運(yùn)行良好的系統(tǒng)。

有了微服務(wù)架構(gòu)，應(yīng)用程序由小型分散的開發(fā)團(tuán)隊(duì)構(gòu)建，這些團(tuán)隊(duì)獨(dú)立地工作和更改微服務(wù)。

4.1.3、服務(wù)自治

這使得測(cè)試和升級(jí)服務(wù)以及隨時(shí)間增加功能變得更加容易。

最終，如果一個(gè)微服務(wù)在規(guī)模和功能上增長(zhǎng)，它可以被分解并分成多個(gè)微服務(wù)，從而保持微服務(wù)的小型、可管理和自治。

4.1.4、讓項(xiàng)目保持技術(shù)多樣性

最后，采用微服務(wù)體系結(jié)構(gòu)允許使用最適合其開發(fā)的任何語言和技術(shù)堆棧來編寫單個(gè)服務(wù)。并沒有嚴(yán)格的限制所有的微服務(wù)都必須使用相同的技術(shù)來開發(fā)，只要它們都通過相同的輕量級(jí)協(xié)議(如HTTP和消息)進(jìn)行通信，并且數(shù)據(jù)結(jié)構(gòu)以相同的格式進(jìn)行序列化(JSON是最流行的選擇)。

微服務(wù)的特點(diǎn)是:

• 輕量級(jí)的組件;
• 服務(wù)獨(dú)立的部署能力;
• 輕量級(jí)、粗粒度api;
• 輕量級(jí)的服務(wù)總線;
• 輕量級(jí)的數(shù)據(jù)存儲(chǔ);

4.1.5、避免了單體系統(tǒng)開發(fā)效率低下的問題

單體系統(tǒng)要么是數(shù)據(jù)庫變得太大了，要么是代碼行太多了，更有可能的是，現(xiàn)在的開發(fā)人員不能快速地添加新特性。微服務(wù)體系結(jié)構(gòu)避免了單體系統(tǒng)的缺陷，使用真實(shí)且可靠的分解技術(shù)來解決這些缺陷，并將重點(diǎn)放在敏捷開發(fā)和可替換性上，而不是可重用性上。

此外，與單體系統(tǒng)不同，微服務(wù)是一個(gè)可持續(xù)的體系結(jié)構(gòu)，通過添加新的微服務(wù)來滿足快速變化的業(yè)務(wù)需求，而不是修改(和破壞)舊的服務(wù)。

4.2、微服務(wù)面臨的問題

沒有什么架構(gòu)是免費(fèi)的

盡管微服務(wù)有很多好處，但它并不是萬能的。微服務(wù)在減輕整體應(yīng)用程序固有的許多問題的同時(shí)，也帶來了其他挑戰(zhàn)。與技術(shù)領(lǐng)域的任何事情一樣，總是需要在不同的體系結(jié)構(gòu)和微服務(wù)之間進(jìn)行權(quán)衡。

4.2.1、增加了運(yùn)維的復(fù)雜度，以及維護(hù)微服務(wù)集群的復(fù)雜度

它所提供的敏捷性和開發(fā)速度是以增加操作復(fù)雜性為代價(jià)的，因?yàn)樽匀挥懈嗟幕顒?dòng)部件(或服務(wù))—可能比單體應(yīng)用還要多。

使用微服務(wù)架構(gòu)可能會(huì)增加運(yùn)維開銷。使用這種方法，您的部署可能需要大量資源。您可能需要更多的時(shí)間和精力來創(chuàng)建基礎(chǔ)架構(gòu)。所有服務(wù)可能都需要群集以實(shí)現(xiàn)故障轉(zhuǎn)移和彈性。您的系統(tǒng)可能具有數(shù)十個(gè)單獨(dú)的組件，并且在您添加新功能時(shí)，它將變得越來越復(fù)雜。

您可能會(huì)得到一個(gè)由20或30個(gè)或更多服務(wù)組成的解決方案，而不是一個(gè)整體系統(tǒng)，每個(gè)服務(wù)都運(yùn)行多個(gè)進(jìn)程。

最佳實(shí)踐是，您應(yīng)該通過DevOps自動(dòng)化解決這些額外的工作開銷。

4.2.2、單體系統(tǒng)遷移到微服務(wù)比價(jià)困難

把單體系統(tǒng)遷移到微服務(wù)也是一個(gè)巨大的工作量。不推薦用微服務(wù)重寫系統(tǒng)，這不太現(xiàn)實(shí)，特別是單體系統(tǒng)業(yè)務(wù)比較復(fù)雜的時(shí)候。建議采用一種更漸進(jìn)的方法，逐步地重構(gòu)一個(gè)單體系統(tǒng)，逐漸地將它轉(zhuǎn)變成一個(gè)由微服務(wù)組成的“新”應(yīng)用程序。隨著時(shí)間的推移，單體應(yīng)用程序?qū)崿F(xiàn)的功能數(shù)量會(huì)減少，直到完全消失或變成另一個(gè)微服務(wù)應(yīng)用程序。最后，不要覺得有必要立即開始分解一切;花時(shí)間和工作在最合理的方式為你的團(tuán)隊(duì)。

4.2.3、提高了開發(fā)的技術(shù)門檻

在開始實(shí)際的遷移過程之前，我們得思考權(quán)衡以下問題：可以肯定的是，具有微服務(wù)體系結(jié)構(gòu)的系統(tǒng)提供了大量的好處，例如獨(dú)立部署、強(qiáng)大的子系統(tǒng)邊界和技術(shù)多樣性。

但是，因?yàn)槲⒎?wù)是一個(gè)分布式系統(tǒng)，它帶來了開發(fā)分布式應(yīng)用程序相關(guān)的復(fù)雜性的代價(jià)，如：獨(dú)立的數(shù)據(jù)模型、微服務(wù)之間的彈性通信、最終一致性和操作復(fù)雜性等。開發(fā)和運(yùn)行大規(guī)模的分布式服務(wù)也不是一件容易的事情。

在實(shí)際的把單體系統(tǒng)拆分為微服務(wù)的過程中，不建議用服務(wù)大小來衡量拆分效果，而是拆分的業(yè)務(wù)邊界，可以考慮使用DDD的方式去進(jìn)行建模設(shè)計(jì)。DDD是我們架構(gòu)師工具箱中用于標(biāo)識(shí)和設(shè)計(jì)微服務(wù)的優(yōu)秀工具。

4.3、微服務(wù)技術(shù)體系

微服務(wù)需要關(guān)注的點(diǎn)很多，下面畫了一張圖來表述：

 

總的來說，微服務(wù)MSA架構(gòu)需要以下技術(shù)點(diǎn)的支持：

• 配置管理;
• 服務(wù)發(fā)現(xiàn)和負(fù)載均衡;
• 彈性和容錯(cuò);
• API管理;
• 服務(wù)安全;
• 日志管理;
• Metrics監(jiān)控;
• 分布式調(diào)用鏈追蹤;
• 調(diào)度和發(fā)布;
• 自動(dòng)伸縮和自愈;

除了技術(shù)相關(guān)的，組織結(jié)構(gòu)和團(tuán)隊(duì)文化也是很重要的。

下面是一般微服務(wù)涉及到的各種組件：

 

5、微服務(wù)技術(shù)選型

我們先來關(guān)注下微服務(wù)的各種技術(shù)棧的優(yōu)缺點(diǎn)。

5.1、Spring Cloud

為開發(fā)人員提供了用于構(gòu)建MSA的工具，例如：配置中心、服務(wù)發(fā)現(xiàn)、斷路器、路由等。它是基于Java的Netflix OSS庫構(gòu)建的。

關(guān)于如何使用Spring Cloud構(gòu)建一個(gè)微服務(wù)架構(gòu)，推薦您閱讀：Microservice Architectures With Spring Cloud and Docker：https://dzone.com/articles/microservice-architecture-with-spring-cloud-and-do，相關(guān)項(xiàng)目架構(gòu)圖如下：

 

5.1.1、優(yōu)點(diǎn)

• Spring技術(shù)棧，快速上手，開箱即用：Spring平臺(tái)提供了統(tǒng)一編程模型，以及Spring Boot快速創(chuàng)建應(yīng)用程序的功能，為開發(fā)人員提供了出色的微服務(wù)開發(fā)套件，僅僅需要很少的配置，就可以創(chuàng)建應(yīng)用;
• 組件庫豐富;
• 不同Spring Cloud組件可以很好的集成工作，一切基于注釋驅(qū)動(dòng)，易于開發(fā)，感覺就像是Java開發(fā)者的天堂。

5.1.2、缺點(diǎn)

• 僅限于Java。我們前面提到MSA架構(gòu)的魅力在于能夠在需要時(shí)修改技術(shù)棧，庫甚至語言的。Spring Cloud則無法做到這一點(diǎn)。Netflix的Prana項(xiàng)目中使用了邊車模式，通過HTTP調(diào)用可以在系統(tǒng)中集成非JVM的應(yīng)用。通過HTTP與Prana進(jìn)行跨進(jìn)程通信，使得用其他語言編寫的應(yīng)用程序或Memcached、Spark和Hadoop等服務(wù)能夠利用Netflix OSS庫提供的特性，而不必為目標(biāo)語言或平臺(tái)重新編寫庫;
• Java程序員承擔(dān)了太多的責(zé)任，服務(wù)發(fā)現(xiàn)、負(fù)載均衡、配置中心均需要單獨(dú)部署，而且我們要保證高可用，除了實(shí)現(xiàn)服務(wù)功能，我們還必須構(gòu)建和管理一個(gè)微服務(wù)平臺(tái);
• 不能覆蓋MSA整個(gè)生命周期：微服務(wù)平臺(tái)部分必備功能缺失，自動(dòng)化部署、調(diào)度、資源管理、進(jìn)程隔離、自我修復(fù)等仍然是一個(gè)問題。我們?nèi)匀恍枰隟ubernetes或者Cloud Foundry來解決此類問題。

5.2、Dubbo

其實(shí)dubbo只是一個(gè)rpc框架，其架構(gòu)如下(來源于官方網(wǎng)站^2)：

 

調(diào)用關(guān)系說明

1. 服務(wù)容器負(fù)責(zé)啟動(dòng)，加載，運(yùn)行服務(wù)提供者。
2. 服務(wù)提供者在啟動(dòng)時(shí)，向注冊(cè)中心注冊(cè)自己提供的服務(wù)。
3. 服務(wù)消費(fèi)者在啟動(dòng)時(shí)，向注冊(cè)中心訂閱自己所需的服務(wù)。
4. 注冊(cè)中心返回服務(wù)提供者地址列表給消費(fèi)者，如果有變更，注冊(cè)中心將基于長(zhǎng)連接推送變更數(shù)據(jù)給消費(fèi)者。
5. 服務(wù)消費(fèi)者，從提供者地址列表中，基于軟負(fù)載均衡算法，選一臺(tái)提供者進(jìn)行調(diào)用，如果調(diào)用失敗，再選另一臺(tái)調(diào)用。
6. 服務(wù)消費(fèi)者和提供者，在內(nèi)存中累計(jì)調(diào)用次數(shù)和調(diào)用時(shí)間，定時(shí)每分鐘發(fā)送一次統(tǒng)計(jì)數(shù)據(jù)到監(jiān)控中心。

其提供了Metrics監(jiān)控，服務(wù)發(fā)現(xiàn)和負(fù)載均衡，rpc調(diào)用，其實(shí)不能算是一個(gè)MSA體系，不過后來阿里整合了Spring Cloud，推出了Spring Cloud Alibaba，作為微服務(wù)開發(fā)的一站式解決方案。其中包含了Dubbo Spring Cloud。

由于 Dubbo Spring Cloud 構(gòu)建在原生的 Spring Cloud 之上，其服務(wù)治理方面的能力可認(rèn)為是 Spring Cloud Plus，不僅完全覆蓋 Spring Cloud 原生特性，而且提供更為穩(wěn)定和成熟的實(shí)現(xiàn)：

• 服務(wù)限流降級(jí)：默認(rèn)支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降級(jí)功能的接入，可以在運(yùn)行時(shí)通過控制臺(tái)實(shí)時(shí)修改限流降級(jí)規(guī)則，還支持查看限流降級(jí) Metrics 監(jiān)控。
• 服務(wù)注冊(cè)與發(fā)現(xiàn)：適配 Spring Cloud 服務(wù)注冊(cè)與發(fā)現(xiàn)標(biāo)準(zhǔn)，默認(rèn)集成了 Ribbon 的支持。
• 分布式配置管理：支持分布式系統(tǒng)中的外部化配置，配置更改時(shí)自動(dòng)刷新。
• 消息驅(qū)動(dòng)能力：基于 Spring Cloud Stream 為微服務(wù)應(yīng)用構(gòu)建消息驅(qū)動(dòng)能力。
• 分布式事務(wù)：使用 @GlobalTransactional 注解， 高效并且對(duì)業(yè)務(wù)零侵入地解決分布式事務(wù)問題。。
• 阿里云對(duì)象存儲(chǔ)：阿里云提供的海量、安全、低成本、高可靠的云存儲(chǔ)服務(wù)。支持在任何應(yīng)用、任何時(shí)間、任何地點(diǎn)存儲(chǔ)和訪問任意類型的數(shù)據(jù)。
• 分布式任務(wù)調(diào)度：提供秒級(jí)、精準(zhǔn)、高可靠、高可用的定時(shí)(基于 Cron 表達(dá)式)任務(wù)調(diào)度服務(wù)。同時(shí)提供分布式的任務(wù)執(zhí)行模型，如網(wǎng)格任務(wù)。網(wǎng)格任務(wù)支持海量子任務(wù)均勻分配到所有 Worker(schedulerx-client)上執(zhí)行。
• 阿里云短信服務(wù)：覆蓋全球的短信服務(wù)，友好、高效、智能的互聯(lián)化通訊能力，幫助企業(yè)迅速搭建客戶觸達(dá)通道。

5.3、Kubernetes

Kubernetes是一個(gè)開源系統(tǒng)，用于應(yīng)用程序自動(dòng)化容器部署、擴(kuò)展和管理。它支持多語言，并提供了用于配置，運(yùn)行，擴(kuò)展和管理分布式系統(tǒng)的原語。

優(yōu)點(diǎn)

多語言和通用容器管理平臺(tái)，能夠運(yùn)行云原生和傳統(tǒng)容器化應(yīng)用程序;

易于構(gòu)建跨團(tuán)隊(duì)的平臺(tái)：提供的服務(wù)(例如配置管理，服務(wù)發(fā)現(xiàn)，負(fù)載平衡，指標(biāo)收集，日志聚合)可以通過多種語言來使用;

解決了更多MSA的問題：除了提供運(yùn)行時(shí)服務(wù)外，Kubernetes還允許您置備環(huán)境、設(shè)置資源約束、RBAC、管理應(yīng)用程序生命周期、啟用自動(dòng)縮放和自我修復(fù)等;

社區(qū)活躍，技術(shù)發(fā)展迅猛;

缺點(diǎn)

具有通用化服務(wù)和原語的平臺(tái)，沒有針對(duì)特定語言或平臺(tái)進(jìn)行優(yōu)化，上手比較困難;

不是以開發(fā)人員為中心的平臺(tái)，致力于打造具有DevOps意識(shí)的IT人員使用，手動(dòng)安裝高可用的Kubernetes集群需要繁瑣的操作和配置;

是一個(gè)較新的平臺(tái)，仍然在發(fā)展，每個(gè)版本都會(huì)新增很多特性，新功能比較難跟上;但是其提供更多API是可擴(kuò)展的，并且向后兼容;

下面列一個(gè)表格總結(jié)下：

 

5.4、MSA技術(shù)選型

Dubbo只是一個(gè)RPC框架，提供的功能不能覆蓋整個(gè)MSA生命周期。

Spring Cloud是開發(fā)人員友好的平臺(tái)，可快速上手。

而Kubernetes是DevOps友好的，具有陡峭的學(xué)習(xí)曲線，但提供了更多的微服務(wù)問題解決方案。

Spring Cloud在JVM內(nèi)部非常強(qiáng)大，而Kubernetes在管理這些JVM方面非常強(qiáng)大。

 

根據(jù)以上對(duì)比，我們想要搭建一個(gè)完整的微服務(wù)體系架構(gòu)，有很多技術(shù)可以選擇的。那么究竟應(yīng)該如何選擇呢

下面是推薦技術(shù)選型方案：

• 如果是新團(tuán)隊(duì)做技術(shù)選型，建議直接上Kubernetes，當(dāng)然，你可以采用Spring Boot。為了提高內(nèi)部服務(wù)調(diào)用的效率，可以整合dubbo，但是建議采用Kubernetes內(nèi)置的服務(wù)發(fā)現(xiàn)和負(fù)載均衡，也就是引入的外部技術(shù)要最小化;
• 中小企業(yè)可能沒有人力成本去自建Kubernetes平臺(tái)，可以采用公有云;
• 盡量不要混搭，會(huì)增加維護(hù)成本;
• 針對(duì)歷史采用了Dubbo的項(xiàng)目，盡量遷移到Dubbo Spring Cloud完善其他組件。使用Dubbo Spring Cloud[1]，配合Kubernetes實(shí)現(xiàn)DevOps系統(tǒng)。內(nèi)部調(diào)用通過Dubbo RPC進(jìn)行，提高效率。

技術(shù)方案選型歸納如下：

 

6、關(guān)于架構(gòu)選型

架構(gòu)沒有好壞之分，只有最適合業(yè)務(wù)的架構(gòu)，才是最好的。

如何選型

這里我舉個(gè)例子來說明架構(gòu)選型是要跟業(yè)務(wù)匹配的。我們先來了解三種架構(gòu)：

• 單體架構(gòu)云：一個(gè)典型的單體應(yīng)用就是將所有的業(yè)務(wù)場(chǎng)景的表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層放在一個(gè)工程中，最終經(jīng)過編譯、打包，部署在一臺(tái)服務(wù)器上。
• 微服務(wù)架構(gòu)：微服務(wù)是將一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成，系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。
• Serverless架構(gòu)：無服務(wù)器架構(gòu)是指大量依賴第三方BaaS(后端即服務(wù))服務(wù)或暫存容器中運(yùn)行的自定義代碼FaaS(函數(shù)即服務(wù))的應(yīng)用程序，函數(shù)是無服務(wù)器架構(gòu)中抽象語言運(yùn)行時(shí)的最小單位。Severless架構(gòu)中，我們關(guān)注運(yùn)行函數(shù)所需的時(shí)間，從而計(jì)算需要支付多少服務(wù)費(fèi)用。

 

架構(gòu)升級(jí)與業(yè)務(wù)發(fā)展

我們必須在保證業(yè)務(wù)不受影響的前提下，引入更加合理的技術(shù)架構(gòu)，不斷發(fā)展和優(yōu)化技術(shù)架構(gòu)，同時(shí)開發(fā)提供一系列穩(wěn)定的業(yè)務(wù)應(yīng)用程序運(yùn)行于技術(shù)架構(gòu)之上;

需要支持快速的技術(shù)發(fā)展，同時(shí)保護(hù)業(yè)務(wù)應(yīng)用程序不受技術(shù)升級(jí)的影響;

不及時(shí)處理技術(shù)債務(wù)的IT領(lǐng)導(dǎo)者有造成軟件和組織面臨挑戰(zhàn)的風(fēng)險(xiǎn)。技術(shù)債務(wù)會(huì)打亂業(yè)務(wù)，甚至?xí)a(chǎn)生更多的債務(wù)，同時(shí)導(dǎo)致不良實(shí)踐的野蠻生長(zhǎng)和頂級(jí)人才的流失;沒有先進(jìn)的技術(shù)武器，再好的業(yè)務(wù)也會(huì)被人迎頭趕上。

7、云原生架構(gòu)

上一節(jié)我們講到了架構(gòu)的發(fā)展史，我們可以看出，目前正是從微服務(wù)時(shí)代過度到云原生時(shí)代的過程?；A(chǔ)的云平臺(tái)提供：

• laas將會(huì)為我們提供計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等資源能力;
• PaaS將會(huì)為我們提供常用的技術(shù)基礎(chǔ)平臺(tái)，我們直接使用其API即可;

我們基于云平臺(tái)提供的運(yùn)算能力，搭建自己的SaaS系統(tǒng)，最終通過DevOps部署到云上。關(guān)鍵層次劃分如下：

 

IaaS：Infrastructure-as-a-Service，基礎(chǔ)設(shè)施即服務(wù)，提供給消費(fèi)者的服務(wù)是對(duì)所有計(jì)算基礎(chǔ)設(shè)施的利用，包括處理CPU、內(nèi)存、存儲(chǔ)、網(wǎng)絡(luò)和其它基本的計(jì)算資源，用戶能夠部署和運(yùn)行任意軟件，包括操作系統(tǒng)和應(yīng)用程序;

PaaS：Platform-as-a-Service，平臺(tái)即服務(wù)，提供常用的技術(shù)組件方便系統(tǒng)的開發(fā)和維護(hù)。把客戶采用提供的開發(fā)語言和工具(例如Java，python, .Net等)開發(fā)的或收購的應(yīng)用程序部署到供應(yīng)商的云計(jì)算基礎(chǔ)設(shè)施上去;

SaaS：Software-as-a-Service，軟件即服務(wù)，提供開發(fā)好的應(yīng)用或服務(wù)，按功能或性能要求付費(fèi)。SaaS 是軟件的開發(fā)、管理、部署都交給第三方，不需要關(guān)心技術(shù)問題，可以拿來即用。普通用戶接觸到的互聯(lián)網(wǎng)服務(wù)，幾乎都是 SaaS。

想進(jìn)一步了解單體應(yīng)用如何拆分為微服務(wù)，然后上云，使用k8s進(jìn)行部署，從而實(shí)現(xiàn)從單體應(yīng)用走向云原生架構(gòu)之路?方案架構(gòu)師Andy Wu在Google云平臺(tái)討論了單體系統(tǒng)的問題，以及微服務(wù)的好處，服務(wù)上云計(jì)算的好處，并且通過一個(gè)真實(shí)的場(chǎng)景演示了遷移一個(gè)單體系統(tǒng)到這種新體系結(jié)構(gòu)的過程。公眾號(hào)回復(fù)：g01 獲取一手完整資料。(英文版)

微服務(wù)中的分布式技術(shù)

在設(shè)計(jì)微服務(wù)系統(tǒng)，或者研究其底層原理的時(shí)候，會(huì)涉及到分布式基礎(chǔ)知識(shí)的方方面面：分布式事務(wù)處理、分布式鎖、分布式ID、分布式緩存、分布式搜索技術(shù)、分布式協(xié)調(diào)組件、消息隊(duì)列、高性能通信框架Netty。這個(gè)我們?cè)诜植际綄ｎ}專門來探討下。

這篇文章的內(nèi)容就差不多介紹到這里了，能夠閱讀到這里的朋友真的是很有耐心，為你點(diǎn)個(gè)贊。

本文為arthinking基于相關(guān)技術(shù)資料和官方文檔撰寫而成，確保內(nèi)容的準(zhǔn)確性，如果你發(fā)現(xiàn)了有何錯(cuò)漏之處，煩請(qǐng)高抬貴手幫忙指正，萬分感激。

大家可以關(guān)注我的博客：itzhai.com 獲取更多文章，我將持續(xù)更新后端相關(guān)技術(shù)，涉及JVM、Java基礎(chǔ)、架構(gòu)設(shè)計(jì)、網(wǎng)絡(luò)編程、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)庫、算法、并發(fā)編程、分布式系統(tǒng)等相關(guān)內(nèi)容。

如果您覺得讀完本文有所收獲的話，可以關(guān)注我的賬號(hào)，或者點(diǎn)個(gè)贊吧，碼字不易，您的支持就是我寫作的最大動(dòng)力，再次感謝!

References

[1]: Dubbo Spring Cloud

https://github.com/alibaba/spring-cloud-alibaba/wiki/Dubbo-Spring-Cloud

[2]: Dubbo

http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html

[3]: Software Architecture AntiPatterns

https://sourcemaking.com/antipatterns/software-architecture-antipatterns

[4]: Escaping monolithic hell

https://livebook.manning.com/book/microservices-patterns/chapter-1/1

[5]: From building microliths to designing reactive microsystems

https://www.oreilly.com/radar/the-evolution-of-scalable-microservices/

[6]: An open-source benchmark suite for microservices and their hardware-software implications for cloud & edge systems

https://blog.acolyer.org/2019/05/13/an-open-source-benchmark-suite-for-microservices-and-their-hardware-software-implications-for-cloud-edge-systems/

[7]: 回歸單體 —— Istio的自我救贖?

https://www.servicemesher.com/blog/istio-self-salvation/

[8]: 用這 12 要素來構(gòu)建你的應(yīng)用程序

https://juejin.im/post/5dfdd9aef265da33b50740ee

構(gòu)建微服務(wù)技術(shù)中臺(tái)，SpringCloud和Kubernetes該如何選型?

https://blog.csdn.net/yang75108/article/details/99706510

Adoption of Cloud-Native Architecture, Part 1: Architecture Evolution and Maturity 架構(gòu)的演變和成熟度

https://www.infoq.com/articles/cloud-native-architecture-adoption-part1/

微服務(wù)架構(gòu)初探

https://www.sohu.com/a/225603928_617676

Spring Cloud for Microservices Compared to Kubernetes

https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/

微服務(wù)與SOA的差異

https://www.leanix.net/en/blog/microservices-vs-soa

Microservices vs SOA: What's the Difference?

https://dzone.com/articles/microservices-vs-soa-whats-the-difference

What is service-oriented architecture?

https://www.javaworld.com/article/2071889/what-is-service-oriented-architecture.html

Microservices vs SOA: What’s the Difference?

https://www.tiempodev.com/blog/microservices-vs-soa/

《分布式服務(wù)架構(gòu):原理、設(shè)計(jì)與實(shí)戰(zhàn)》

《Cloud-native-approach-with-microservices》

SpringCloud與Dubbo的比較

https://blog.csdn.net/xuri24/article/details/89283802

Dubbo 與 Spring Cloud 完美結(jié)合

https://www.cnblogs.com/babycomeon/p/11546737.html

Microservices Patterns

 

https://livebook.manning.com/book/microservices-patterns/about-this-book/

本文轉(zhuǎn)載自微信公眾號(hào)「Java架構(gòu)雜談」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java架構(gòu)雜談公眾號(hào)。