軟件產(chǎn)品架構(gòu)是不斷迭代演化的，從單體服務架構(gòu)發(fā)展到現(xiàn)在的服務化、微服務的架構(gòu)。

單體架構(gòu)

單體架構(gòu)就是所有的業(yè)務模塊都是耦合在一個項目中，開發(fā)、部署都在一起；如果其中一個模塊需要上線升級，那么所有模塊都要一起啟停；

在早期，單體架構(gòu)的項目團隊成員需要是“全?！?，因為前端、后端、數(shù)據(jù)庫都是一波人負責，后來開始進行了邏輯分層，團隊也分成了前端 UI 團隊、后端和 DBA 團隊，每個團隊都有自己負責的職責。

然而隨著業(yè)務邏輯越來越復雜，模塊和模塊之間的耦合度越來越高；另外隨著用戶和數(shù)據(jù)量的增多，單體架構(gòu)也不再能夠支撐高并發(fā)和大數(shù)據(jù)。

SOA 架構(gòu)

為了解決上面的問題，SOA 出現(xiàn)了。

SOA 代表了面向服務的架構(gòu)，SOA 將應用程序的業(yè)務模塊進行拆分，形成獨立的應用系統(tǒng)，系統(tǒng)和系統(tǒng)之間通過明確的接口串聯(lián)起來；

每個系統(tǒng)內(nèi)部結(jié)構(gòu)和邏輯發(fā)生改變，并不影響對外提供的服務，只要保持接口不變，服務內(nèi)部對外是透明的；

SOA 架構(gòu)中，服務定義標注的接口，可以提供給多個調(diào)用方使用，增加了服務的重用性。

SOA 架構(gòu)時代有兩個很重要技術(shù)實現(xiàn)方式：Web Service 和 ESB ：前者提供了標準的數(shù)據(jù)傳輸協(xié)議，后者實現(xiàn)了服務編排和協(xié)議轉(zhuǎn)換。

微服務架構(gòu)

但是隨著用戶和數(shù)據(jù)量的進一步增長，SOA 也暴露出來一些缺點，比如 SOAP 協(xié)議、XML較重；服務管理不完善；ESB本身就比較重，而且它本身算是一個單點，在軟件架構(gòu)中，單點意味著風險。

在微服務的架構(gòu)中，各個微服務可以獨立開發(fā)，獨立部署；微服務之間通常使用Restful風格的API通信，傳輸格式也通常選擇JSON；

微服務是SOA架構(gòu)的延續(xù)，它們和單體應用相比，大大提高了系統(tǒng)的負載能力，解決了應用高并發(fā)的需求；

服務和服務之間的耦合度也被降低，并且項目團隊可以被拆分成多個小團隊，每個微服務都可以進行敏捷開發(fā)部署；

每個團隊的技術(shù)棧也可以不相同，只要遵守接口協(xié)議即可。

至于微服務和 SOA 架構(gòu)的區(qū)別，我是這樣理解的：SOA 架構(gòu)和微服務架構(gòu)都屬于分布式架構(gòu)，分布式的思想就是把不同的業(yè)務模塊，部署在不同的服務器上，以應對高并發(fā)的問題；SOA 是一種分布式架構(gòu)，把業(yè)務系統(tǒng)分成多個子系統(tǒng)，提供不同的服務，再通過服務組合、編排實現(xiàn)業(yè)務流程；微服務是SOA的升華，如果非要說點兒不同的，那么微服務更加強調(diào)服務的細分和專業(yè)，去ESB總線、去中心化，部署粒度更細，服務擴展更靈活。

當然SOA、微服務的出現(xiàn)，在解決一些問題的時候，也帶來了另外一部分的問題，比如增加了網(wǎng)絡開銷、服務依賴性、增加了測試運維難度、數(shù)據(jù)一致性問題等等。

我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注。

面對微服務如火如荼的發(fā)展，很多人都在了解，學習希望能在自己的項目中幫得上忙，當你對微服務的廬山真面目有所了解后，接下來就是說服自己了，到底如何評估微服務，什么時候使用微服務，什么時間點最合適，需要哪些技術(shù)儲備和資源投入等等，這些都是你需要面對和解決的。

本文從單體架構(gòu)，微服務架構(gòu)，微服務風險評估，微服務落地條件等幾個方面探討微服務的落地過程，希望對你有所啟發(fā)。

　　講解微服務之前，我們先簡單了解下單體架構(gòu)。

一、單體架構(gòu)

單體架構(gòu)的優(yōu)點：

• 快速開發(fā)和驗證想法，證明產(chǎn)品思路是否可行

• 投入資源和成本，包括人力和物力相對比較節(jié)約

單體架構(gòu)的缺點：

　　隨著業(yè)務的復雜度增加，單體的靈活度會逐漸下降，比如：

• IDE過載：隨著代碼量增加，代碼整體編譯效率下降。

• 規(guī)?；簾o法滿足團隊規(guī)?；咝ч_發(fā)。

• 系統(tǒng)開發(fā)、測試、部署的沖突和效率低下等問題

• 只能關(guān)注一套技術(shù)棧

• 應用擴展性比較差

• 海量用戶高并發(fā)訪問數(shù)量有限

單體適用場景：

　　架構(gòu)設(shè)計的三大原則告訴我們，架構(gòu)需要的是簡單、適度、演化。

　　對于項目起步階段，單體是最高效也是最節(jié)省成本的方式。因為初期階段，由于人力，成本，業(yè)務熟悉程度，微服務技術(shù)積累等因素，如何過度設(shè)計可能工期和復雜度會急劇上升，造成交付困難，問題百出，從而錯過了時間窗口。最合適，簡單的方式還是單體優(yōu)先，這是創(chuàng)業(yè)公司的特點決定的。當然設(shè)計面向微服務的單體架構(gòu)也是一種聰明的方法，這遵守了系統(tǒng)演化的法則。

單體分層目的：

　　無論采取何種維度的架構(gòu)分層，分層的最核心目的是保證各層之間的差異足夠清晰，邊界足夠明顯，為將來可能產(chǎn)生的變化提供最容易、最小化的修改。比如客戶端要從安卓替換為IOS，底層無須任何改動，就像替換積木一樣。又比如，設(shè)備需要接入新的設(shè)備或協(xié)議，其他層也不需要做任何變化，可以無縫平滑接入任何設(shè)備。

建議

　　如果前期在業(yè)務不十分清晰，求的是驗證想法，證明產(chǎn)品思路是否可行性，并且業(yè)務量不大，僅限于省級范圍，建議只要對當前架構(gòu)稍加改良升級就可以了，這樣改動量相對較小，且至少能支撐一定時間段的業(yè)務增長。

二、微服務架構(gòu)

微服務的優(yōu)勢

　　支撐的業(yè)務更加龐大，可以支撐海量用戶高并發(fā)和海量設(shè)備接入，支持分布式多機房，多區(qū)域部署，支持服務器無限擴容。支持私有云，公有云，混合云等部署方式。所以微服務是大多數(shù)互聯(lián)網(wǎng)公司的首選。

微服務的代價

• 技術(shù)門檻高：微服務包括，服務描述，注冊中心，服務框架，服務監(jiān)控，服務追蹤，服務治理等幾大基本組件，以上每個組件缺一不可，每個組件展開又包括很多技術(shù)門檻，比如，容器技術(shù)，持續(xù)部署，DevOps等相關(guān)概念。
• 復雜性增加：相對單體架構(gòu)將所有功能打包部署在一起，集中地進行開發(fā)、測試和運維，微服務會將這些單體的服務進行拆分部署，業(yè)務拆分粒度是一個難點，拆分后服務聚合也是一個麻煩。因為服務粒度增加后，相互調(diào)用，相互依存，所以問題排查難度會增加，就需要一套完整的服務監(jiān)控，服務跟蹤和治理的系統(tǒng)。
• 觀念變化：微服務不僅僅是技術(shù)的升級，更是開發(fā)方式、組織架構(gòu)、開發(fā)觀念的轉(zhuǎn)變。
• 前期投入成本較高

微服務架構(gòu)圖

　　微服務架構(gòu)圖譜谷歌或Bing下，可以看到各種各樣的架構(gòu)圖，源于業(yè)務和架構(gòu)師自身的喜好或者粗細粒度，但是每個架構(gòu)圖的基本組件和架構(gòu)分層都差別不大，只是有的細一些，有的粗一下。比如有客戶端層，容器層(K8S)，API Gateway，微服務集群層，EventBus層是必須要有的，至于服務監(jiān)控和服務跟蹤、服務治理本身就是一個完整的系統(tǒng)，粒度就沒有細了?；谶@些概念，我把架構(gòu)圖稍微細化一下，這里省去服務監(jiān)控跟蹤和治理的部分，后續(xù)多帶帶抽離出來分析。

　　這邊的架構(gòu)圖譜相對之前的架構(gòu)圖，更加貼近業(yè)務，粒度也更細，雖然個別組件有所省略，比如跟蹤和治理部分。

　　以上架構(gòu)圖主要分4層，每個層次遵循架構(gòu)分層的核心思想：關(guān)注點分離，職責各異，邊界清晰。

　　第1層：客戶端：理論上包含一切可以聯(lián)網(wǎng)的設(shè)備，包括移動設(shè)備，Android、IoS、Pad、微信、微博、QQ、Web、各自瀏覽器、物聯(lián)網(wǎng)設(shè)備等等……

　　第2層：API網(wǎng)關(guān)：包括服務注冊，發(fā)現(xiàn)，認證授權(quán)，單點登錄，熔斷，限流……網(wǎng)關(guān)的知識點豐富，是微服務的核心之一。

• 假如網(wǎng)關(guān)對外提供統(tǒng)一的地址：www.jackyfei.com

　　第3層：微服務集群：包括各種具體的microservice，比如縱向劃分的業(yè)務服務(用戶服務，訂單服務，……)，橫向劃分的基礎(chǔ)或公共服務(元數(shù)據(jù)服務，公共服務……)

　　其他微服務的地址可能是這樣的：

• 用戶服務：1.user.jackyfei.com訂單服務：2.order.jackyfei.com元數(shù)據(jù)服務：3.base.jackyfei.com消息服務：4.msg.jackyfei.com

　　第4層：事件總線：Event Bus 目的是消息解耦，不要讓服務之間直接的鏈接。不同與SOA的服務總線，事件總線相對比較輕量，經(jīng)?；谙㈥犃幸孢M行解耦，目的是為了讓服務之間的關(guān)聯(lián)弱化，不直接進行關(guān)聯(lián)。很多時候用的是相對穩(wěn)定、可靠、企業(yè)級的RabbitMQ。

　　微服務的架構(gòu)其實不難，根據(jù)以上的架構(gòu)，每種業(yè)務都可以進行套用，這里的難點在于服務的劃分和粒度控制，另外如何管理膨脹的服務是一個麻煩事。

三、何時采用微服務?

3.1楊波說

　　這里引用架構(gòu)師楊波(前Ebay架構(gòu)師，目前任職拍拍貸研發(fā)部總監(jiān)，資深技術(shù)架構(gòu)師，微服務技術(shù)專家)的一些觀點：

　　“企業(yè)一開始不推薦直接使用微服務，因為微服務需要前期基礎(chǔ)設(shè)施的投資，復雜性很高，如果對問題領(lǐng)域并不是很理解，一開始用微服務，你很難去劃分服務的邊界，你的生產(chǎn)力反而會比較低，而且你花了很大精力進行開發(fā)，你的產(chǎn)品并沒有被市場驗證過，有可能會失敗，所以這個選項風險會比較高。所以我們推薦的是單塊優(yōu)先，先從單塊運用做起，這樣成本低，團隊成員也比較少，無須太多研發(fā)投入，就可以交付一些基本的功能給客戶使用。

　　隨著應用越來越成功，客戶增加，你的系統(tǒng)復雜度會越來越高，就會出現(xiàn)單塊應用和團隊規(guī)模之間的矛盾，生產(chǎn)力會隨著業(yè)務復雜度逐漸降低。所以在一些初創(chuàng)型公司，你更多看到的是單塊應用，只有一些中大型的公司會看到微服務架構(gòu)?！?/p>

　　“交叉點表明，業(yè)務已經(jīng)到達了一定的復雜性，單塊應用已經(jīng)無法滿足業(yè)務增長的需要，研發(fā)效率開始下降了，而微服務可以提升研發(fā)和交付的效率。這個點需要架構(gòu)師去綜合，權(quán)衡。個人經(jīng)驗，一般團隊需要達到百人規(guī)模，才去考慮微服務。”

　　以上的觀點講的很中肯，給我的啟發(fā)和幫助非常大。這里的交叉點怎么來確定和評估是重點，比如我們上線一個社交姑且叫抖信，初期為了快速上線，驗證可行性，可以只開發(fā)首頁聊天、通訊錄、評論等基本功能。產(chǎn)品上線后，經(jīng)過一段時間的運營，用戶開始逐步增多，可行性驗證通過，下一階段就需要進一步增加更多的新特性來吸引更多的目標用戶，比如再給這個社交抖信添加朋友圈、消息通知、游戲、電商等等功能。

　　“一般情況下，這個時候就需要大規(guī)模地擴張開發(fā)人員，以支撐多個功能的開發(fā)。如果這個時候繼續(xù)采用單體應用架構(gòu)，多個功能模塊混雜在一起開發(fā)、測試和部署的話，就會導致不同功能之間相互影響，一次打包部署需要所有的功能都測試 OK 才能上線。

　　不僅如此，多個功能模塊混部在一起，對線上服務的穩(wěn)定性也是個巨大的挑戰(zhàn)。比如 A 開發(fā)的一個功能由于代碼編寫考慮不夠全面，上線后產(chǎn)生了內(nèi)存泄漏，運行一段時間后進程異常退出，那么部署在這個服務池中的所有功能都不可訪問。

　　根據(jù)我的實際項目經(jīng)驗，一旦單體應用同時進行開發(fā)的人員超過 10 人，就會遇到上面的問題，這個時候就該考慮進行服務化拆分了。”---胡忠想(微博微服務技術(shù)專家)

　　至此，我們何時采用微服務已經(jīng)十分明確了，關(guān)鍵是業(yè)務復雜度和團隊規(guī)模兩大要點，而業(yè)務復雜度和市場窗口是權(quán)衡和抉擇的首要因素。

3.2微服務落地條件評估

　　一般情況下，業(yè)務系統(tǒng)引入新技術(shù)就必然會帶來架構(gòu)的復雜度提升，在具體決策前，你先要認識到新架構(gòu)會帶來哪些新的問題，這些問題你和你的團隊是否能夠解決？如何解決？是自己投入人力建設(shè)，還是采用業(yè)界開源方案？假如你和我一樣都是微服務的旁觀者或者學習者，那么下面的評估也許對你又所參考。

3.2.1落地方式選擇

不同的落地方式?jīng)Q定不同的資源配置。

方式一：借力外部架構(gòu)咨詢公司提供架構(gòu)DEMO和培訓服務助推內(nèi)部團隊技術(shù)轉(zhuǎn)型升級。

方式二：招聘相關(guān)經(jīng)驗豐富的人員進來，自行研究和搭建架構(gòu)并做內(nèi)部培訓，推動團隊技術(shù)升級。

建議：如果比較緊急，采用第一種方式，因為招聘匹配的人才比較困難，等不起。但是不管是那種方式，對于團隊來說都需要一定的技術(shù)人才儲備方便后續(xù)交接和運維。

3.2.2人才儲備

　　這里分成兩類人員，一類是研究型，一類是應用型。研究型主要是以技術(shù)攻堅為主，負責微服務的核心組件的研究和開發(fā)，比如服務發(fā)布和訂閱，服務跟蹤和監(jiān)控，服務的治理；應用型主要是負責技術(shù)理解應用為主。

3.2.3技術(shù)儲備

　　微服務相關(guān)技術(shù)棧和微服務周邊技術(shù)棧。周邊技術(shù)棧包括領(lǐng)域驅(qū)動涉及，持續(xù)交付，分布式至少，負載均衡，CAP理論，緩存原理，DevOps和容器化技術(shù)。

3.2.4團隊規(guī)模評估

　　楊波在給微服務的開發(fā)團隊規(guī)劃時候給了一個百人左右的大概預估，至于到底需要多少開發(fā)人員就沒有細說，可能作者本身呆過的公司都是大廠，對人力成本控制沒有那么大的包袱，對于中小企業(yè)，人力是最貴的成本。如果要一定要上微服務，該怎么辦？

　　對于微服務的團隊規(guī)模眾說紛紜，有的說要百來號人；有的說需要精兵10人左右；有的說和人數(shù)沒有關(guān)系，只和業(yè)務有關(guān)；有的說一個懂微服務的架構(gòu)師也能搞定。這些說法都比較籠統(tǒng)，如果你想上微服務，人力評估包括人力、能力、人數(shù)等等，這些因素還是非常重要的，畢竟成本才是商業(yè)的本質(zhì)，有可能不客觀的規(guī)劃會導致項目的潰敗。

　　對于微服務的團隊規(guī)模是哪些方面決定的呢？我覺得至少要從以下兩個維度來評估：

　　業(yè)務規(guī)模：如果你們的業(yè)務架構(gòu)非常復雜，有倉儲系統(tǒng)開發(fā)，ERP系統(tǒng)，OA系統(tǒng)，訂單系統(tǒng)等等，業(yè)務越多，需求人數(shù)越多(這里人數(shù)指的都是后臺開發(fā)人數(shù))。

　　技術(shù)能力：另外，別忘了非功能性的開發(fā)，比如API網(wǎng)關(guān)，服務跟蹤、治理等也是需要人去開發(fā)和維護的，這些非功能性的核心組件需要多少人，由于沒有完整的開發(fā)經(jīng)驗，加上個別組件，比如跟蹤系統(tǒng)，開發(fā)的程度可深可淺，開發(fā)周期可長可短，以目前個人的經(jīng)驗還無法給與合理的建議?？赡芘Ｈ?個人兩周就夠了，也可能高級開發(fā)2個人，一人分工三個核心組件，兩周也夠用?；蛘呒軜?gòu)外包，只要交接的人能跟上，也是一種解決方案。

　　總結(jié)：1個精通微服務落地經(jīng)驗的架構(gòu)師是必不可少的，圍繞架構(gòu)師周邊一幫高級開發(fā)，按根據(jù)實際業(yè)務來確定，一般一個開發(fā)負責2-3個核心模塊，不宜太多，比如目前核心模塊有8個，對應人數(shù)配置大概在3-4個左右。

3.3轉(zhuǎn)微服務風險評估

3.3.1重寫面廣

　　由于是架構(gòu)級別的調(diào)整，之前能保留下來的大部分是解耦比較好的代碼，比如前端代碼，采集服務代碼，部分業(yè)務邏輯代碼，所以對現(xiàn)有框架沖擊面比較大。

3.3.2復雜度高

　　因為微服務是一種觀念和思想，又是新近技術(shù)，本身就有各種架構(gòu)實現(xiàn)方式和技術(shù)解決方案。所以對技術(shù)人員來說，對比選型本身就是一個考驗。加上本身涉及的技術(shù)面就比較廣，所以復雜度和門檻相對比較高。

但是該技術(shù)發(fā)源于亞馬遜，經(jīng)過近些年的發(fā)展，雖然還在發(fā)展，但是已經(jīng)相對成熟。

3.3.3人員配置

　　微服務架構(gòu)工作量主要集中在后端，對后端開發(fā)人員的技術(shù)級別有較高的要求，主要是對微服務原理和開源組件的熟悉上，同時需要具備整體的微服務的意識。暫時不具備整體微服務開發(fā)意識和經(jīng)驗，需要通過培訓后進行轉(zhuǎn)型升級。

3.3.4合作方式

　　如果采用借助外部架構(gòu)力量來助推架構(gòu)升級，和架構(gòu)單位的合作就不是簡單的外包，涉及的面會變得比較廣，在完全交接過來之前，周期會比較長。包括對我們業(yè)務架構(gòu)的深入了解，然后根據(jù)業(yè)務架構(gòu)繪制可靠技術(shù)架構(gòu)藍圖，再根據(jù)技術(shù)藍圖進行落地實施(不建議只提供架構(gòu)方案而由其他單位實施落地)，包括新系統(tǒng)的開發(fā)，舊系統(tǒng)的升級，當然這種升級是平滑過度的，對業(yè)務窗口并不會產(chǎn)生影響。

3.4合理的拆分姿勢

　　如何正確拆分？這里正確指的是合理，因為沒有絕對的標準。按照前人的經(jīng)驗可以分為縱向和橫向兩種劃分方法：

3.4.1縱向拆分

　　是從業(yè)務維度進行拆分。標準是按照業(yè)務的關(guān)聯(lián)程度來決定，關(guān)聯(lián)比較密切的業(yè)務適合拆分為一個微服務，而功能相對比較獨立的業(yè)務適合多帶帶拆分為一個微服務，比如上圖中的訂單服務，用戶服務。另外粒度太小，服務聚合是一個坑，粒度太大，分和沒分一個樣。

3.4.2橫向拆分

　　是從公共且獨立功能維度拆分。標準是按照是否有公共的被多個其他服務調(diào)用，且依賴的資源獨立不與其他業(yè)務耦合。比如上圖中的元數(shù)據(jù)服務和消息服務。

3.4.3總結(jié)

　　借用《微服務設(shè)計》中的一句話：“你越不了解一個領(lǐng)域，為服務找到合適的界限上下文就越難……服務的界限劃分錯誤，可能會導致不得不頻繁地更改服務間的協(xié)作，而這種更改成本更高……”

四、SOA和微服務

　　由于SOA和微服務有千絲萬縷的關(guān)系，這里簡單羅列雙方的對比圖，算是一個小知識點：

　　兩種架構(gòu)背后的意圖是不同的：SOA嘗試將應用集成，一般采用中央管理模式來確保各應用能夠交互運作。微服務嘗試部署新功能，快速有效地擴展開發(fā)團隊。它著重于分散管理、代碼再利用與自動化執(zhí)行。

五、總結(jié)

　　最后讓我們回顧一下前人經(jīng)典的話語：

• 分布式第一定律是“盡量不要使用分布式”。
• 軟件行業(yè)從業(yè)者，尤其是那些已經(jīng)不寫代碼的從業(yè)者，總會期望有銀彈，但銀彈終究是沒有的。
• 微服務依賴于“基礎(chǔ)設(shè)施自動化”。微服務不是“銀彈”。

　　還是回到我們架構(gòu)設(shè)計的原則上，遵循簡單，適用，演化的原則，那么你的抉擇也許會變得沒有那么令人糾纏。

文章引用

• 從單體式架構(gòu)遷移到微服務架構(gòu)
• 《微服務設(shè)計》作者: [英] Sam Newman 出版社: 人民郵電出版社
• 4 Challenges You Need to Address with Microservices Adoption
• 為什么使用微服務？

單體架構(gòu)

在傳統(tǒng)IT行業(yè)的軟件系統(tǒng)設(shè)計大多都是各種獨立子系統(tǒng)的堆砌，這也就是所說的單體架構(gòu)，其本身擴展性差，可靠性低，維護成本高。單體架構(gòu)在初期系統(tǒng)規(guī)模比較小的情況下尚且能夠較好的支撐，但是隨著系統(tǒng)規(guī)模的擴大，它暴露出來的問題也越來越多，主要有以下幾點：

• 復雜性逐漸變高，問題修復和新功能開發(fā)難度和成本高，引入新問題的可能性變大。同時，任意模塊的缺陷都可能會影響整個系統(tǒng)，可靠性低。
  
• 隨著人員流動，加之復雜性高，新的問題很難被發(fā)現(xiàn)和解決，久而久之，問題逐漸變多，變難、變大，技術(shù)債務逐漸上升。
  
• 隨著模塊不斷集成，部署速度逐漸變慢
  
• 想進行整體的技術(shù)創(chuàng)新基本不可能，阻礙技術(shù)創(chuàng)新
  
• 垂直和水平的可擴展性差
  

SOA架構(gòu)

隨后，引入了SOA服務化（面向服務的架構(gòu)，它將應用程序的不同功能單元（服務）進行拆分，并通過這些服務之間定義良好的接口和契約聯(lián)系起來)。但是，由于 SOA 早期均使用了ESB總線模式，這種總線模式與某種技術(shù)棧是強綁定的，如，J2EE。這又使得很多企業(yè)的遺留系統(tǒng)很難對接，切換時間太長，對接成本太高，新系統(tǒng)穩(wěn)定性的收斂也需要一些時間。最終 SOA 看起來很美，但卻成為了企業(yè)級奢侈品，中小公司都望而生畏。

SOA服務化思想下的微服務架構(gòu)

微服務是在 SOA 上做的升華，微服務最早由Martin Fowler與James Lewis于2014年共同提出，微服務架構(gòu)風格是一種使用一套小服務來開發(fā)單個應用的方式途徑，每個服務運行在自己的進程中，并使用輕量級機制通信，通常是HTTP Rest API的方式（告別ESB服務總線），這些服務基于業(yè)務能力構(gòu)建，并能夠通過自動化部署機制來獨立部署，這些服務使用不同的編程語言實現(xiàn)，以及不同數(shù)據(jù)存儲技術(shù)，并保持最低限度的集中式管理。

簡單講，微服務不再強調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB服務總線，同時將SOA的思想延伸到單個業(yè)務系統(tǒng)內(nèi)部實現(xiàn)真正的組件化。微服務架構(gòu)強調(diào)的一個重點是“業(yè)務需要徹底的組件化和服務化”。

從微服務的概念可以看出它有如下好處：

• 每個服務可以獨立開發(fā)，易于開發(fā)，提高開發(fā)人員的生產(chǎn)效率
  
• 局部修改容易部署
  
• 技術(shù)棧不受限
  
• 單個服務支持獨立部署和發(fā)布，可以進行快速迭代部署，更快的交付時間
  
• 更有利于業(yè)務的擴展，可伸縮性強

轉(zhuǎn)自 @軟件測試開發(fā)技術(shù)棧 ，希望對您有所幫助。

單體架構(gòu)：

單體機構(gòu)是指在軟件設(shè)計中使用經(jīng)典的 3 層模型，即表示層、業(yè)務邏輯層和數(shù)據(jù)訪問層。雖然在設(shè)計中劃分了 3 層模型，但是對業(yè)務場景沒有劃分。一個典型的單體應用就是將所有的業(yè)務場景的表示層、業(yè)務邏輯層和數(shù)據(jù)訪問層放在一個工程中，最終經(jīng)過編譯、打包，部署在一臺服務器上。

優(yōu)點：

1. 易于開發(fā): 單體應用程序開發(fā)相對簡單，容易理解，單個程序員可以完成業(yè)務接口到數(shù)據(jù)庫的整個流程。
2. 部署簡單: 由于是完整的結(jié)構(gòu)體，可以直接部署在一個服務器上即可。
3. 技術(shù)單一: 項目不需要復雜的技術(shù)棧，往往一套熟悉的技術(shù)棧就可以完成開發(fā)。

缺點：

1. 開發(fā)成本高：代碼重復率高，需求變更困難，無法滿足新業(yè)務快速上線和敏捷交付。
2. 系統(tǒng)穩(wěn)定性差：任何一個模塊的錯誤均可能造成整個系統(tǒng)的宕機;
3. 擴展能力受限：系統(tǒng)的擴容只能只對這個應用進行擴容，不能做到對某個功能點進行擴容，關(guān)鍵性的代碼改動一處多處會受影響。

SOA架構(gòu):

SOA架構(gòu)即面向服務架構(gòu)，是一種粗粒度、松耦合服務架構(gòu)?；赟OA服務思想進行功能的抽取，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯(lián)系起來，以服務為中心各個系統(tǒng)之間依靠ESB企業(yè)服務總線進行調(diào)用，這使得構(gòu)件在各種各樣的系統(tǒng)中的服務可以以一種統(tǒng)一和通用的方式進行交互。

優(yōu)點：

1. 敏捷性：可以直接利用現(xiàn)有的資源進行組合，讓后在按照自己的客戶需求，進行進一步的開發(fā)。
2. 擴展性：可以更具不同的需求，進行重新的組合和構(gòu)造。
3. 易維護：服務的提供者和使用者是松耦合關(guān)系，開放標準接口的采用，使其具有很好的維護性和可用性。

缺點：

1. 開發(fā)難度: 架構(gòu)設(shè)計、服務抽取、接口設(shè)計等問題，考驗著領(lǐng)導者和開發(fā)人員過硬的技術(shù)能力。
2. 數(shù)據(jù)統(tǒng)一：存在“臟數(shù)據(jù)”相關(guān)問題，處理一致性是設(shè)計服務接口面臨的巨大挑戰(zhàn)之一。

微服務架構(gòu)：

微服務架構(gòu)是把一個大型的單個應用程序和服務拆分為多個的微服務，每個微服務僅關(guān)注并很好的完成一件任務。它的主要作用是將功能分解到離散的各個服務當中，從而降低系統(tǒng)的耦合性，并提供更加靈活的服務支持。

優(yōu)點：

1. 獨立性：是每個微服務組件都是簡單靈活的，能夠獨立部署。
2. 可擴展性：微服務之間是松耦合的，微服務內(nèi)部是高內(nèi)聚的，每個微服務很容易按需擴展，產(chǎn)品迭代周期更短。
3. 隔離性：每個微服務都是獨立的運行，任何一個或者多個微服務的失敗只影響自己或者少量其他微服務，而不會大面積地波及整個服務運行體系。

缺點：

1. 復雜性：開發(fā)的復雜性增加，因為一個業(yè)務流程需要多個微服務通過網(wǎng)絡交互來完成。
2. 服務治理：微服務過多，服務治理成本高，不利于系統(tǒng)維護。

其實，這三者到現(xiàn)在來說未必是那樣經(jīng)緯分明、非此即彼，很多基于微服務的單體架構(gòu)應用、結(jié)合分布式的SOA云服務總線來實現(xiàn)線上線下集成、內(nèi)部跟外部集成、構(gòu)建柔韌的企業(yè)IT架構(gòu)、滿足業(yè)務的變化、推動業(yè)務創(chuàng)新和變革，是軟件架構(gòu)不斷優(yōu)化、變遷、提升的源動力。

數(shù)通暢聯(lián)專注于企業(yè)IT架構(gòu)、SOA綜合集成、數(shù)據(jù)治理分析領(lǐng)域，感謝您的閱讀與關(guān)注

一圖了解什么是單體架構(gòu)、SOA架構(gòu)、微服務架構(gòu)

分別從三個維度來展示：

1、軟件過程維度

單體架構(gòu)通常采用瀑布模型開發(fā)；

SOA架構(gòu)通常采用敏捷/XP編程模式；

微服務架構(gòu)采用DevOps，使用IT交付流水線來全自動管理；

2、從架構(gòu)維度

單體架構(gòu)通常采用巨石結(jié)構(gòu)，不易維護；

SOA架構(gòu)通常以服務的方式對外連接，常見的支撐平臺有ESB企業(yè)服務總線進行服務貫通；

微服務架構(gòu)采用更細的拆分模式，每個獨立的模塊有多帶帶的數(shù)據(jù)庫、運行環(huán)境，在業(yè)務上完成一個具體的功能；

3、從部署形態(tài)維度

單體架構(gòu)早期多運行在物理機中，當然后期也可以運行在虛擬化資源中；

SOA架構(gòu)多運行在虛擬化/IAAS平臺上；

微服務架構(gòu)目前多運行在容器平臺上（當然也可以運行在虛擬化資源和物理機中，這種情況享受不到容器帶來的便利性）；

單體架構(gòu)

* 一個典型的單體應用就是將所有的業(yè)務場景的表示層、業(yè)務邏輯層和數(shù)據(jù)訪問層放在一個工程中，最終經(jīng)過編譯、打包，部署在一臺服務器上。

`例如：典型的J2EE工程，它是將表示層的JSP、業(yè)務邏輯層的Service、Controller和數(shù)據(jù)訪問層的Dao，打成war包，部署在Tomcat、Jetty或者其他Servlet容器中運行`

SOA架構(gòu)

* SOA架構(gòu)是面向服務的體系結(jié)構(gòu)，主要目的是為了各個系統(tǒng)更加容易地融合在一起。

`例如：以購物商城為例，由于功能模塊越來越多，系統(tǒng)非常臃腫所有對系統(tǒng)進行橫向拆分，各個服務之間彼此相對獨立，通過服務治理框架進行服務之間的通信以及管理，常用的服務治理框架有：dubbo、dubbox等`

微服務架構(gòu)

微服務是將一個大型復雜軟件應用由一個或多個微服務組成。系統(tǒng)中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關(guān)注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表著一個小的業(yè)務模塊。

我在低代碼開發(fā)平臺領(lǐng)域中接觸最多的就是微服務架構(gòu)，微服務是指開發(fā)一個單個 小型的但有業(yè)務功能的服務,每個服務都有自己的處理和輕量通訊機制,可以部署在單個或多個服務器上，而且部署方式也有多種，集群部署，雙機部署，單機部署等等，天翎的myapps平臺就是一個很好的例子，可以去了解一下這個架構(gòu)，是三種架構(gòu)里面使用得比較多也比較方便的軟件產(chǎn)品架構(gòu)

表面上看這是一個大問題。

實質(zhì)有內(nèi)聯(lián)關(guān)系。

你可以把一個單體架構(gòu)的應用看作是一大整塊豆腐。

SOA架構(gòu)就是豆腐切塊了。

微服務架構(gòu)就是豆腐切塊了之后又切成豆腐丁了。

大塊有大塊的好處，小塊有小塊的好處。

這里的利弊就是你打算怎么個做法能吃起來更可口。

應用切分到微服務也并不是絕對的好。

技術(shù)架構(gòu)細分也是軟件細化分工的一種體現(xiàn)。

僅此而已。