2020年了，很多小伙伴兒對微服務(wù)還比較陌生，說起來很多人可能不敢相信，其實(shí)微服務(wù)這個(gè)概念早在2012年就提出來了，經(jīng)過了這些年的發(fā)展，現(xiàn)在已經(jīng)成為企業(yè)非常主流的架構(gòu)選項(xiàng)了。今天，我就來帶大家一起探討下微服務(wù)的前世今生，以及在.Net Core下該如何落地。(文章較長下為全文目錄，全手寫，輕拍！想省心也可以掃碼看視頻版解說)。

本文目錄

VIP-懶人通道
貼心的我還準(zhǔn)備了真人視頻解說！文章太長讀不下去？直接掃碼上圖領(lǐng)取視頻，聽我講給你聽~

微服務(wù)的前世今生

與微服務(wù)架構(gòu)相對的，叫單體架構(gòu)。這是我們最熟悉的開發(fā)方式，就是一個(gè)項(xiàng)目搞定業(yè)務(wù)全過程，在同一個(gè)進(jìn)程里面完成。隨著業(yè)務(wù)發(fā)展，數(shù)據(jù)量和并發(fā)上去了，一般會(huì)選擇右邊的垂直拆分，拆分后的每個(gè)系統(tǒng)，依舊是單體架構(gòu)的。

垂直拆分后，子系統(tǒng)都能獨(dú)立做集群，承載能力大大提升。但隨著業(yè)務(wù)進(jìn)一步發(fā)展，子系統(tǒng)會(huì)越來臃腫，而且根據(jù)二八原則，80%的請求其實(shí)都集中在20%的業(yè)務(wù)上，不同的子系統(tǒng)也都有很多重復(fù)的功能模塊。于是乎分布式就誕生了，將高頻重復(fù)的功能拆成獨(dú)立的服務(wù)部署，各系統(tǒng)都通過調(diào)用服務(wù)來完成功能。

分布式拆出服務(wù)獨(dú)立部署和維護(hù)， 既完成了功能的復(fù)用，又能保證高頻服務(wù)的伸縮性和高可用，代表著更高的生產(chǎn)力。然而欲戴王冠必承其重，分布式帶來的問題跟提供的價(jià)值一樣多，比如分布式鎖、一致性、可用性、復(fù)雜度等要命問題。

隨著時(shí)間推移，業(yè)務(wù)倒逼技術(shù)進(jìn)步，在大數(shù)據(jù)高并發(fā)的要求下，分布式技術(shù)慢慢開始成熟，針對各種問題都形成了行之有效的辦法，然后分布式也成了架構(gòu)設(shè)計(jì)系統(tǒng)的常規(guī)手段?；诜?wù)的形式來完成對業(yè)務(wù)的解耦，提供高可用和伸縮性的特性，滿足了日益增長的業(yè)務(wù)需求。隨著業(yè)務(wù)的不斷拆分，粒度越來越細(xì)，一個(gè)新的稱謂微服務(wù)(Microservice)就應(yīng)運(yùn)而生！

什么是微服務(wù)架構(gòu)？我理解為是一種架構(gòu)設(shè)計(jì)系統(tǒng)的風(fēng)格，基于小粒度的服務(wù)來完成對業(yè)務(wù)的解耦，將業(yè)務(wù)流程拆分成多個(gè)服務(wù)組裝。就像以前三層架構(gòu)里面，一個(gè)業(yè)務(wù)會(huì)調(diào)用多個(gè)BLL方法，而現(xiàn)在換成了調(diào)用多個(gè)服務(wù)。這就是微服務(wù)了，當(dāng)然，小伙伴兒認(rèn)真想想會(huì)發(fā)現(xiàn)，真的要落地微服務(wù)，問題太多了！下面，我就以.Net Core技術(shù)棧下，對微服務(wù)架構(gòu)落地的種種問題和解決方案來一一探討！

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

一 、進(jìn)程間通信：?

這個(gè)是構(gòu)建微服務(wù)的基礎(chǔ)，通常有以下三大類：

1.基于第三方存儲(chǔ)共享的通訊(數(shù)據(jù)庫/Redis/隊(duì)列等)

2.基于Http協(xié)議的服務(wù)(WebService/WCF/WebApi)

3.遠(yuǎn)程調(diào)用模式(FX下的RPC和.Net Core下的gRPC)

二、服務(wù)注冊與發(fā)現(xiàn)：

微服務(wù)架構(gòu)是搭建在底層服務(wù)實(shí)例基礎(chǔ)上，必須通過集群來保證服務(wù)的高可用和動(dòng)態(tài)伸縮，因此服務(wù)注冊，服務(wù)發(fā)現(xiàn)，健康檢查，異常下線功能都是必須的，在.Net Core下可以考慮選擇Consul(首選)、etcd或者ZooKeeper。

三、網(wǎng)關(guān)Gateway

微服務(wù)架構(gòu)支持多客戶端共用服務(wù)，而且底層服務(wù)數(shù)目眾多，不可能全部都暴露給外部客戶端(安全隱患/公網(wǎng)IP)，而且多客戶端也不可能維護(hù)無止境的服務(wù)實(shí)例地址，因此網(wǎng)關(guān)gateway是必須的！就像門面模式Fa?ade一樣管理好底層服務(wù)，通過路由映射底層服務(wù)實(shí)例，客戶端一律通過網(wǎng)關(guān)來完成服務(wù)調(diào)用。此外，由于請求都從網(wǎng)關(guān)走，那么也可以在網(wǎng)關(guān)這里完成鑒權(quán)授權(quán)、限流、熔斷、降級(jí)等進(jìn)階功能。

四、鑒權(quán)授權(quán)

微服務(wù)架構(gòu)里到處都是服務(wù)實(shí)例，還都是集群化部署，甚至還兼容不同技術(shù)平臺(tái)的服務(wù)實(shí)例，傳統(tǒng)的session共享式做權(quán)限驗(yàn)證已經(jīng)行不通了，當(dāng)下都是使用token來做用戶識(shí)別。大致原理如下圖，由鑒權(quán)中心頒發(fā)token，然后帶著token去訪問各服務(wù)實(shí)例。在.Net Core里面首選IdentityServer4或者JWT。在真實(shí)落地微服務(wù)時(shí)，一般會(huì)建立個(gè)獨(dú)立的鑒權(quán)中心，然后在網(wǎng)關(guān)層完成鑒權(quán)授權(quán)，非常方便。

以上是系統(tǒng)架構(gòu)，往下是功能性需求

五、瞬態(tài)故障處理

真的去寫代碼時(shí)，你會(huì)發(fā)現(xiàn)調(diào)用服務(wù)總沒有調(diào)用方法那么方便，會(huì)因?yàn)榫W(wǎng)絡(luò)、延遲等造成種種意外，因此需要一種優(yōu)雅的方式來執(zhí)行請求重試、超時(shí)處理、故障恢復(fù)等策略，目前.Net Core下推薦使用Polly，常見應(yīng)用是集成到gateway或者AOP的模式插入到客戶端里面。

六、分布式追蹤

一個(gè)請求會(huì)涉及多個(gè)服務(wù)，而服務(wù)本身還有依賴，整個(gè)請求路徑就構(gòu)成了一個(gè)網(wǎng)狀的調(diào)用鏈，想象一下其實(shí)挺害怕！在整個(gè)調(diào)用鏈中一旦某個(gè)節(jié)點(diǎn)發(fā)生異常，整個(gè)調(diào)用鏈的穩(wěn)定性就會(huì)受到影響，因此必須得有跟蹤請求，性能分析的工具，以便快速定位和解決問題。SkyWalking (推薦)、Cat、Zipkin、Pinpoint都是可選項(xiàng)，這里就不建議大家自己造輪子了。

七、日志收集與分析

微服務(wù)下的日志已經(jīng)不是單機(jī)系統(tǒng)日志那么簡單，茫茫多的服務(wù)節(jié)點(diǎn)，復(fù)雜的依賴調(diào)用關(guān)系，會(huì)帶來海量的日志，一套優(yōu)秀的分布式日志收集和分析框架是必須入手的，這里我給大家推薦的是ExceptionLess，入手簡單資料齊全。

八、統(tǒng)一配置中心

配置管理平臺(tái)是必不可少的，那么多服務(wù)那么多集群，一個(gè)個(gè)人肉管理會(huì)瘋掉的。Apollo能夠集中化管理應(yīng)用不同環(huán)境、不同集群的配置，配置修改后能夠?qū)崟r(shí)推送到應(yīng)用端，并且具備規(guī)范的權(quán)限、流程治理等特性，是由攜程框架部門研發(fā)的開源配置管理中心，.Net社區(qū)的驕傲，點(diǎn)贊！

九、分布式鎖

單體架構(gòu)下，多線程操作同一個(gè)對象，可以用lock鎖保證只有一個(gè)線程能進(jìn)入，微服務(wù)架構(gòu)多進(jìn)程下，怎么管控？核心思路是基于第三方的共享數(shù)據(jù)訪問加上互斥邏輯來完成管控，像數(shù)據(jù)庫/Nosql/Consul等介質(zhì)均可。實(shí)踐中，Redis是首選不解釋。

十、分布式事務(wù)

CAP有言，在分布式的情況下，系統(tǒng)的可用性和一致性是沒法同時(shí)滿足的。微服務(wù)體系下，一個(gè)業(yè)務(wù)請求都需要N個(gè)服務(wù)節(jié)點(diǎn)協(xié)作，可用性是最高優(yōu)先級(jí)，否則系統(tǒng)沒法正常運(yùn)轉(zhuǎn)了。那如何數(shù)據(jù)的一致性怎么辦？當(dāng)下主流的模式有3種，2PC/3PC，TCC以及本地消息表，前一個(gè)是犧牲可用性去保障一致性，用的較少，后面都是保障數(shù)據(jù)最終一致性。目前在互聯(lián)網(wǎng)公司主流選擇是下圖的基于消息隊(duì)列的分布式事務(wù)實(shí)現(xiàn)。

再往下是發(fā)布部署

十一、Jenkins-CI/CD

持續(xù)集成持續(xù)交付(CI/CD)是敏捷開發(fā)的核心，在微服務(wù)架構(gòu)下也是常備的。簡單來說，就是能持續(xù)的合并代碼分支納入新功能，能持續(xù)的交付產(chǎn)出給下游，讓整個(gè)項(xiàng)目進(jìn)展肉眼可見。不過靜心想想就知道有很多麻煩事兒，所以這一切就交給專業(yè)的工具來完成了，Jenkins值得擁有。

十二、Docker容器部署

微服務(wù)架構(gòu)里，需要快捷啟動(dòng)服務(wù)實(shí)例，支持不同系統(tǒng)環(huán)境，不同運(yùn)行環(huán)境，不同語言的各種服務(wù)實(shí)例，獨(dú)立的物理服務(wù)器是不現(xiàn)實(shí)的，虛擬化技術(shù)的成本太高，快捷的沙箱環(huán)境+高效的資源利用+可復(fù)制快速啟動(dòng)的容器Docker 成為首選，Build Once,Run AnyWhere!不會(huì)docker的程序員，已經(jīng)不是一個(gè)好的工程師了。

十三、容器編排Kubernetes

有了Docker，我們可以肆無忌憚輕松愜意的擴(kuò)充服務(wù)實(shí)例，樂極生悲，容器實(shí)例可能會(huì)膨脹到你控制不住的地步，可能一個(gè)月后整個(gè)團(tuán)隊(duì)就沒人能搞清楚服務(wù)和容器間錯(cuò)綜復(fù)雜的關(guān)系了。所以你需要一個(gè)管理工具，那就是Kubernete，用于編排容器，是管理應(yīng)用的全生命周期的工具，可以理解為docker管家。

學(xué)習(xí)實(shí)踐微服務(wù)架構(gòu)

能看到這里的小伙伴兒，可謂是飽受煎熬了，這么多的框架/組件/工具/方法，是不是讓你望而生畏了。確實(shí)，現(xiàn)在企業(yè)要落地微服務(wù)架構(gòu)，對架構(gòu)師也提出了更高的要求和挑戰(zhàn)(誰讓你拿的錢最多)。下面，我來給大家分享下如何學(xué)習(xí)和實(shí)踐微服務(wù)！

第一階段

理解單體架構(gòu)設(shè)計(jì)，掌握OOP+AOP的編程設(shè)計(jì)思想，熟悉DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的分析設(shè)計(jì)方法，嘗試去簡單拆分系統(tǒng)。

第二階段

以微服務(wù)的思路去重構(gòu)系統(tǒng)，將高頻且獨(dú)立的服務(wù)拆分，部署集群，Consul服務(wù)治理，整合網(wǎng)關(guān)，完成基礎(chǔ)微服務(wù)架構(gòu)。

第三階段

進(jìn)一步完善架構(gòu)，開始重構(gòu)鑒權(quán)授權(quán)、服務(wù)追蹤、分布式日志分析、引入配置中心等組件，解決分布式鎖和分布式事務(wù)，做到功能可用。

第四階段

去引入新的工具完成項(xiàng)目部署運(yùn)營管理，Jenkins/Docker/K8S，一步步的納入使用，這里最省事兒的辦法是上云，阿里云、Azure云都值得推薦。

第五階段

項(xiàng)目全面微服務(wù)化，邁過前面的門檻了，后面會(huì)越來越順利，在完整項(xiàng)目實(shí)戰(zhàn)中去落地微服務(wù)架構(gòu)，應(yīng)對各種真實(shí)情況。

好了，以上是一個(gè)循序漸進(jìn)的學(xué)習(xí)和實(shí)戰(zhàn)過程，也是架構(gòu)班里面學(xué)習(xí)微服務(wù)架構(gòu)的全過程，全程需要3個(gè)月時(shí)間，確實(shí)不易，不過收獲杠杠的！下圖是微服務(wù)的體驗(yàn)課，一周時(shí)間了解和實(shí)踐微服務(wù)架構(gòu)的組件，本文的讀者直接限時(shí)免費(fèi)領(lǐng)取，趕快掃碼和大家一起交流學(xué)習(xí)吧！

福利福利福利

按照慣例，再給大家來一波福利，微服務(wù)架構(gòu)當(dāng)下是食物鏈頂層，需要準(zhǔn)備的知識(shí)也比較多，像CAP、分布式鎖分布式事務(wù)實(shí)現(xiàn)、DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)、.NetCore跨平臺(tái)開發(fā)等知識(shí)點(diǎn)需要提前掌握下，這里整了個(gè)清單(視頻+課件+代碼)，需要的掃碼自取，統(tǒng)統(tǒng)免費(fèi)！