在鹅厂面试5轮后扑街！微服务架构，我拿什么拯救你！
上周五接到朋友的電話，此前他一路披荊斬棘，離鵝廠Offer大概僅一步之遙。電話一接通我就說了一通讓他請客吃飯的話，對面沉默了幾秒鐘，淡淡地說了句 “我終面沒過....”?
這讓我一時語塞不知如何安慰他。兩個中年油膩男硬是打了2小時電話，最終他告訴我，啥都過了，最后竟倒在微服務架構的知識點上...
從掛了那通電話到今天，花費了整整一周的時間，我把我所知道的微服務知識，連同配套的學習資料，我全給整理出來了。從微服務的前世今生到實際落地，再到各個小點的深度解析。我希望看到本文的你，在任何時候，都別因為微服務架構這東西而減分！大家都是成年人了，5輪面試最后還被Pass，心臟受不了！掃碼下方二維碼，完整資料自取。順帶著整理了100多G各類學習資料，跳轉文末直接領取！
本文目錄
微服務的前世今生
與微服務架構相對的，叫單體架構。這是我們最熟悉的開發方式，就是一個項目搞定業務全過程，在同一個進程里面完成。隨著業務發展，數據量和并發上去了，一般會選擇右邊的垂直拆分，拆分后的每個系統，依舊是單體架構的。
垂直拆分后，子系統都能獨立做集群，承載能力大大提升。但隨著業務進一步發展，子系統會越來臃腫，而且根據二八原則，80%的請求其實都集中在20%的業務上，不同的子系統也都有很多重復的功能模塊。于是乎分布式就誕生了，將高頻重復的功能拆成獨立的服務部署，各系統都通過調用服務來完成功能。
分布式拆出服務獨立部署和維護， 既完成了功能的復用，又能保證高頻服務的伸縮性和高可用，代表著更高的生產力。然而欲戴王冠必承其重，分布式帶來的問題跟提供的價值一樣多，比如分布式鎖、一致性、可用性、復雜度等要命問題。
隨著時間推移，業務倒逼技術進步，在大數據高并發的要求下，分布式技術慢慢開始成熟，針對各種問題都形成了行之有效的辦法，然后分布式也成了架構設計系統的常規手段?；诜盏男问絹硗瓿蓪I務的解耦，提供高可用和伸縮性的特性，滿足了日益增長的業務需求。隨著業務的不斷拆分，粒度越來越細，一個新的稱謂微服務(Microservice)就應運而生！
什么是微服務架構？我理解為是一種架構設計系統的風格，基于小粒度的服務來完成對業務的解耦，將業務流程拆分成多個服務組裝。就像以前三層架構里面，一個業務會調用多個BLL方法，而現在換成了調用多個服務。這就是微服務了，當然，小伙伴兒認真想想會發現，真的要落地微服務，問題太多了！下面，我就以.Net Core技術棧下，對微服務架構落地的種種問題和解決方案來一一探討！
落地微服務架構
一 、進程間通信：?
這個是構建微服務的基礎，通常有以下三大類：
1
基于第三方存儲共享的通訊(數據庫/Redis/隊列等)
2
基于Http協議的服務(WebService/WCF/WebApi)
3
遠程調用模式(FX下的RPC和.Net Core下的gRPC)
二、服務注冊與發現：
微服務架構是搭建在底層服務實例基礎上，必須通過集群來保證服務的高可用和動態伸縮，因此服務注冊，服務發現，健康檢查，異常下線功能都是必須的，在.Net Core下可以考慮選擇Consul(首選)、etcd或者ZooKeeper。
三、網關Gateway
微服務架構支持多客戶端共用服務，而且底層服務數目眾多，不可能全部都暴露給外部客戶端(安全隱患/公網IP)，而且多客戶端也不可能維護無止境的服務實例地址，因此網關gateway是必須的！就像門面模式Fa?ade一樣管理好底層服務，通過路由映射底層服務實例，客戶端一律通過網關來完成服務調用。此外，由于請求都從網關走，那么也可以在網關這里完成鑒權授權、限流、熔斷、降級等進階功能。
四、鑒權授權
微服務架構里到處都是服務實例，還都是集群化部署，甚至還兼容不同技術平臺的服務實例，傳統的session共享式做權限驗證已經行不通了，當下都是使用token來做用戶識別。大致原理如下圖，由鑒權中心頒發token，然后帶著token去訪問各服務實例。在.Net Core里面首選IdentityServer4或者JWT。在真實落地微服務時，一般會建立個獨立的鑒權中心，然后在網關層完成鑒權授權，非常方便。
以上是系統架構，往下是功能性需求
五、瞬態故障處理
真的去寫代碼時，你會發現調用服務總沒有調用方法那么方便，會因為網絡、延遲等造成種種意外，因此需要一種優雅的方式來執行請求重試、超時處理、故障恢復等策略，目前.Net Core下推薦使用Polly，常見應用是集成到gateway或者AOP的模式插入到客戶端里面。
六、分布式追蹤
一個請求會涉及多個服務，而服務本身還有依賴，整個請求路徑就構成了一個網狀的調用鏈，想象一下其實挺害怕！在整個調用鏈中一旦某個節點發生異常，整個調用鏈的穩定性就會受到影響，因此必須得有跟蹤請求，性能分析的工具，以便快速定位和解決問題。SkyWalking (推薦)、Cat、Zipkin、Pinpoint都是可選項，這里就不建議大家自己造輪子了。
七、日志收集與分析
微服務下的日志已經不是單機系統日志那么簡單，茫茫多的服務節點，復雜的依賴調用關系，會帶來海量的日志，一套優秀的分布式日志收集和分析框架是必須入手的，這里我給大家推薦的是ExceptionLess，入手簡單資料齊全。
八、統一配置中心
配置管理平臺是必不可少的，那么多服務那么多集群，一個個人肉管理會瘋掉的。Apollo能夠集中化管理應用不同環境、不同集群的配置，配置修改后能夠實時推送到應用端，并且具備規范的權限、流程治理等特性，是由攜程框架部門研發的開源配置管理中心，.Net社區的驕傲，點贊！
九、分布式鎖
單體架構下，多線程操作同一個對象，可以用lock鎖保證只有一個線程能進入，微服務架構多進程下，怎么管控？核心思路是基于第三方的共享數據訪問加上互斥邏輯來完成管控，像數據庫/Nosql/Consul等介質均可。實踐中，Redis是首選不解釋。
十、分布式事務
CAP有言，在分布式的情況下，系統的可用性和一致性是沒法同時滿足的。微服務體系下，一個業務請求都需要N個服務節點協作，可用性是最高優先級，否則系統沒法正常運轉了。那如何數據的一致性怎么辦？當下主流的模式有3種，2PC/3PC，TCC以及本地消息表，前一個是犧牲可用性去保障一致性，用的較少，后面都是保障數據最終一致性。目前在互聯網公司主流選擇是下圖的基于消息隊列的分布式事務實現。
再往下是發布部署
十一、Jenkins-CI/CD
持續集成持續交付(CI/CD)是敏捷開發的核心，在微服務架構下也是常備的。簡單來說，就是能持續的合并代碼分支納入新功能，能持續的交付產出給下游，讓整個項目進展肉眼可見。不過靜心想想就知道有很多麻煩事兒，所以這一切就交給專業的工具來完成了，Jenkins值得擁有。
十二、Docker容器部署
微服務架構里，需要快捷啟動服務實例，支持不同系統環境，不同運行環境，不同語言的各種服務實例，獨立的物理服務器是不現實的，虛擬化技術的成本太高，快捷的沙箱環境+高效的資源利用+可復制快速啟動的容器Docker 成為首選，Build Once,Run AnyWhere!不會docker的程序員，已經不是一個好的工程師了。
十三、容器編排Kubernetes
有了Docker，我們可以肆無忌憚輕松愜意的擴充服務實例，樂極生悲，容器實例可能會膨脹到你控制不住的地步，可能一個月后整個團隊就沒人能搞清楚服務和容器間錯綜復雜的關系了。所以你需要一個管理工具，那就是Kubernete，用于編排容器，是管理應用的全生命周期的工具，可以理解為docker管家。
學習實踐微服務架構
能看到這里的小伙伴兒，可謂是飽受煎熬了，這么多的框架/組件/工具/方法，是不是讓你望而生畏了。確實，現在企業要落地微服務架構，對架構師也提出了更高的要求和挑戰(誰讓你拿的錢最多)。下面，我來給大家分享下如何學習和實踐微服務！
第一階段
理解單體架構設計，掌握OOP+AOP的編程設計思想，熟悉DDD領域驅動設計的分析設計方法，嘗試去簡單拆分系統。
第二階段
以微服務的思路去重構系統，將高頻且獨立的服務拆分，部署集群，Consul服務治理，整合網關，完成基礎微服務架構。
第三階段
進一步完善架構，開始重構鑒權授權、服務追蹤、分布式日志分析、引入配置中心等組件，解決分布式鎖和分布式事務，做到功能可用。
第四階段
去引入新的工具完成項目部署運營管理，Jenkins/Docker/K8S，一步步的納入使用，這里最省事兒的辦法是上云，阿里云、Azure云都值得推薦。
第五階段
項目全面微服務化，邁過前面的門檻了，后面會越來越順利，在完整項目實戰中去落地微服務架構，應對各種真實情況。
好了，以上是一個循序漸進的學習和實戰過程，也是架構班里面學習微服務架構的全過程，全程需要3個月時間，確實不易，不過收獲杠杠的！微服務相關配套學習資料，大家可以文末掃碼自取即可！
福
利
福
利
福
利
為了讓我朋友那種慘劇不再重演，除了微服務架構，我把面試可能考到的所有核心知識做了分類。從開發實戰項目到高級工程師，架構師的技術重難點，所有的學習資料，100多G干貨，一站式放送！僅限本公眾號粉絲專屬福利！（掃碼文末二維碼自取）
獲取以上全部學習資料
掃我掃我~
領取人數較多，添加以下兩個號碼也可免費領取哦！
微信號1：zhaoxiNico
微信號2：zhaoxiPenny
總結
以上是生活随笔為你收集整理的在鹅厂面试5轮后扑街！微服务架构，我拿什么拯救你！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 断！舍！离！
- 下一篇： 如何借助Kubernetes实现持续的业