微服務(wù)或許你沒有真正實(shí)踐過，但一定聽說過，雖然已經(jīng)到了 2022 年，這個(gè)詞依然很熱，可以通過搜索 google 指數(shù)看得到。

起源

“微服務(wù)”一詞源于 2011 年 5 月在威尼斯附近的一次軟件架構(gòu)師研討會(huì)上進(jìn)行的架構(gòu)風(fēng)格的討論。2012 年 5 月 討論小組決定將這種架構(gòu)風(fēng)格命名為“微服務(wù)”。Fred George 同年在一次技術(shù)大會(huì)上進(jìn)行自己的微服務(wù)實(shí)踐分享，并說微服務(wù)是一種細(xì)粒度的 SOA ，但最終將其發(fā)揚(yáng)光大的是 Martin Fowler 2014 年寫的博文《 Microservices 》，原文鏈接如下：

https://martinfowler.com/articles/microservices.html。

自此以后，微服務(wù)就家喻戶曉了，Microservices 的 Google 指數(shù)也是在 2014 年后就一路飆升。

和微服務(wù)相對(duì)應(yīng)的是單體架構(gòu)，先來看看單體架構(gòu)是怎樣的。

單體架構(gòu)

大多數(shù)人做軟件開發(fā)應(yīng)該都是從單體架構(gòu)開始的，以 .NET 程序員來說，從最早的 WebForm、到后來的 MVC、再到現(xiàn)在的前后端分離，后端使用 .NET 的 WebAPI ，都是整個(gè)項(xiàng)目的代碼放到一個(gè)解決方案中，發(fā)布要么直接整個(gè)目錄進(jìn)行替換，或者更新有變更的 dll 文件。

包括到現(xiàn)在，這種單體架構(gòu)的模該還占著很大的比重，凡是存在，必有道理，單體架構(gòu)有著他的可取之處：

• 開發(fā)方便，.NET 程序員只需只需使用宇宙最強(qiáng) IDE VS 就可以。
• 調(diào)試方便，在開發(fā)階段，所有的項(xiàng)目都在一個(gè)解決方案下，項(xiàng)目之間是可以直接引用，斷點(diǎn)可以到達(dá)你想要的任何地方。
• 運(yùn)行方便，編碼完成，只需一個(gè) F5 搞定。
• 部署方便，無論是之前部署 IIS ，還是現(xiàn)在的容器部署，都只涉及到一個(gè)發(fā)布目錄。

不過，隨著產(chǎn)品的功能越來越復(fù)雜，代碼也會(huì)變得越來越復(fù)雜，團(tuán)隊(duì)的人數(shù)也會(huì)越來越多，這時(shí)單體架構(gòu)就會(huì)帶來一些問題：

• 因?yàn)榇a庫(kù)非常的臃腫，從編譯、構(gòu)建、運(yùn)行到測(cè)試這個(gè)時(shí)間會(huì)越來越長(zhǎng)。
• 技術(shù)棧幾乎是受限的，比如一個(gè) .NET 的工程，基本就是 C# 來開發(fā)了，不太可能混雜其他的語言。
• 不方便橫向擴(kuò)展，只能整套程序進(jìn)行擴(kuò)，滿足所有模塊的需求，對(duì)資源的利用率非常差。
• 不夠敏捷，團(tuán)隊(duì)成員越來越多多時(shí)，都在同一個(gè)代碼上進(jìn)行修改、提交、合并，容易引發(fā)沖突和其他問題。
• 一個(gè)很小的改動(dòng)點(diǎn)，容易引發(fā)全身問題，導(dǎo)致系統(tǒng)崩潰，因?yàn)橛绊扅c(diǎn)多，測(cè)試成本也會(huì)很高。
• 缺乏可靠性，我們就碰到過因?yàn)橐粋€(gè)序列化的問題導(dǎo)致 CPU 占用很高，結(jié)果整個(gè)系統(tǒng)癱瘓了。

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

上面提到的單體架構(gòu)存在的問題，采用微服務(wù)架構(gòu)可以很好地解決。微服務(wù)的核心是為了解耦，構(gòu)建成一個(gè)松耦合的分布式系統(tǒng)。

一個(gè)龐大的單體系統(tǒng)拆分成若干個(gè)小的服務(wù)，每個(gè)服務(wù)可以由一個(gè)小的團(tuán)隊(duì)來維護(hù)，團(tuán)隊(duì)會(huì)更加敏捷，構(gòu)建發(fā)布的時(shí)間更短，代碼也容易維護(hù)。

不同的微服務(wù)團(tuán)隊(duì)可以采用不同的技術(shù)棧，比如工作流引擎使用 .NET ，規(guī)則引擎可以使用 Java ，一些全新的模塊更容易采用新的技術(shù)，人員流動(dòng)和補(bǔ)充上也更加靈活。

每個(gè)服務(wù)通常采用獨(dú)立的數(shù)據(jù)庫(kù)，代碼或者數(shù)據(jù)庫(kù)層面的問題不會(huì)導(dǎo)致整個(gè)系統(tǒng)的崩潰。

擴(kuò)展方便，這個(gè)很重要，如果監(jiān)控發(fā)現(xiàn)流程引擎的壓力很大，可以只針對(duì)這個(gè)服務(wù)進(jìn)行橫向擴(kuò)展，服務(wù)器資源可以得到更好的利用。

上面說的都是好處，但沒有任何一種技術(shù)是銀彈，微服務(wù)解決問題的同時(shí)，也會(huì)帶來更多的問題。

1、開發(fā)調(diào)試變得困難了，需要通過日志的方式或者借助一些遠(yuǎn)程調(diào)試工具。

2、單體架構(gòu)中，模塊之間的調(diào)用都是進(jìn)程內(nèi)，添加類庫(kù)的引用后，就是本地方法的調(diào)用，微服務(wù)各自獨(dú)立部署，就會(huì)涉及到進(jìn)程間的通信。

3、線上問題往往需要多個(gè)服務(wù)團(tuán)隊(duì)一起來協(xié)作解決，會(huì)存在互相甩鍋的問題。

4、在分布式系統(tǒng)中，事務(wù)、數(shù)據(jù)一致性、聯(lián)合查詢等相比較單體更加復(fù)雜。

5、持續(xù)集成、部署、運(yùn)維的復(fù)雜度也顯著提升。

6、隨著服務(wù)越來越多，客戶端怎樣去找這些服務(wù)呢?

7、進(jìn)程內(nèi)的訪問不存在網(wǎng)絡(luò)的問題，拆分后的服務(wù)可能在同個(gè)機(jī)器的不同進(jìn)程，更多的時(shí)候是不同機(jī)器的不同進(jìn)程，網(wǎng)絡(luò)問題導(dǎo)致服務(wù)不穩(wěn)定怎么辦?

為了解決這些問題，各種中間件和框架就應(yīng)運(yùn)而生，又會(huì)帶來更多的學(xué)習(xí)成本。

在 .NET 技術(shù)棧中，會(huì)用到下面這些中間件：

• 服務(wù)注冊(cè)與發(fā)現(xiàn)：Consul。
• 網(wǎng)關(guān)：Ocelot。
• 熔斷降級(jí)：Polly。
• 服務(wù)鏈路追蹤：SkyWalking 或 Twitter 的 Zipkin。
• 配置中心：Apllo。
• 鑒權(quán)中心：IdentityServer4。

在 Java 中也有 Spring Cloud 和 Spring Cloud Alibaba 這種全家桶套件可以使用。

要不要轉(zhuǎn)微服務(wù)呢?

從單體到微服務(wù)是一個(gè)權(quán)衡和取舍的問題，切記不要跟風(fēng)。以我的經(jīng)驗(yàn)來看，可以分為兩類：

1. 做企業(yè)級(jí)系統(tǒng)。
2. 做互聯(lián)網(wǎng)系統(tǒng)。

做企業(yè)級(jí)應(yīng)用大多都是項(xiàng)目交付型的，客戶關(guān)系維系的好，后面可以做二期、三期，當(dāng)然也有一錘子買賣的。這其中一個(gè)關(guān)鍵點(diǎn)是要快，單從快速來看，采用單體架構(gòu)，開發(fā)、調(diào)試、部署都是最快的。

從客戶角度來說，只要能滿足業(yè)務(wù)，是單體還是微服務(wù)其實(shí)不太關(guān)心。

做互聯(lián)網(wǎng)應(yīng)用，也就是我們常說的 SaaS，也分為兩種情況：

1、將現(xiàn)有的私有化部署的系統(tǒng)(單體架構(gòu))改造成支持 SaaS 的模式。

這種我也不建議一上來就大刀闊斧地進(jìn)行微服務(wù)改造，可以在代碼的結(jié)構(gòu)上做一些調(diào)整，比如按照領(lǐng)域去拆分目錄，不同領(lǐng)域之間的調(diào)用可以再進(jìn)行一層抽象，目的是為了未來向微服務(wù)架構(gòu)轉(zhuǎn)化。

當(dāng)團(tuán)隊(duì)的技術(shù)棧變得豐富了，比如原先只有 .NET ,現(xiàn)在有些模塊采用的是 Java ,這時(shí)已然是朝著微服務(wù)架構(gòu)發(fā)展了，只是粒度比較大而已，相應(yīng)的一些中間件也需要引入，比如服務(wù)網(wǎng)關(guān)、服務(wù)發(fā)現(xiàn)、服務(wù)間通信等。

2、從零開始做一個(gè) SaaS 系統(tǒng)。

互聯(lián)網(wǎng)系統(tǒng)和企業(yè)級(jí)系統(tǒng)有很大的差別，如果說企業(yè)級(jí)系統(tǒng)更多關(guān)注功能性需求，那么互聯(lián)網(wǎng)系統(tǒng)除了功能性需求，還需要關(guān)注非功能性需求，比如：橫向擴(kuò)展、限流降級(jí)、日志追蹤、預(yù)警、灰度發(fā)布等。

即便因?yàn)闀r(shí)間關(guān)系，一開始是單體架構(gòu)，我覺得也應(yīng)該是微服務(wù)架構(gòu)的單體，隨著持續(xù)迭代和發(fā)展，根據(jù)實(shí)際情況逐步進(jìn)行拆分。

如果時(shí)間上比較充裕，可以一開始就按照微服務(wù)架構(gòu)進(jìn)行分離，但粒度不要太小。

總結(jié)

1. 解決常說的的三高問題(高并發(fā)、高性能、高可用)，一個(gè)核心的思路就是拆，分而治之，所以說微服務(wù)肯定是能解決掉我們的很多問題，也是發(fā)展方向。
2. 實(shí)踐微服務(wù)需要根據(jù)當(dāng)前的實(shí)際情況，如果單體運(yùn)行的很好，也沒什么問題，也不要為了炫技進(jìn)行微服務(wù)改造。
3. 如果決定要實(shí)踐微服務(wù)，先做好單體架構(gòu)的設(shè)計(jì)，讓代碼遵循面向?qū)ο蟮脑O(shè)計(jì)原則，否則即便形式上變成了微服務(wù)，也不能嘗到微服務(wù)的甜頭。