其實互聯(lián)網(wǎng)職業(yè)可以大致分兩個階段，在畢業(yè)后的3到5年內(nèi)主要都是以學(xué)習(xí)、積累為主，從一開始啥都不懂的校園“新鮮人”向“職業(yè)人”轉(zhuǎn)變。如果你是Java開發(fā)者，在這個階段你會學(xué)習(xí)：

1、基礎(chǔ)的Java知識，多線程、集合類、JVM
2、進階知識，設(shè)計模式、系統(tǒng)設(shè)計和方法論
3、主流框架，Spring、Spring Boot、MyBatis……
4、微服務(wù)，Dubbo、ETCD、Spring Cloud……
5、數(shù)據(jù)庫，Redis、ES、MySQL、分庫分表

分享一下我的學(xué)習(xí)之路

2017從杭州師范大學(xué)（也是馬云的母校）畢業(yè)后，我就留在了杭州，因為家庭原因，從大三開始已經(jīng)沒了考研的想法，只想快點工作，能稍微減輕父母身上的重擔(dān)。計算機科班畢業(yè)，當(dāng)時因為簡歷的原因在加上自己學(xué)的不是很好，投入大廠的簡歷全部石沉大海，沒有絲毫音訊。最終來到了一家上市公司，渾渾噩噩的渡過的兩年，除了CRUD啥都不懂，每月拿著9K+的薪水，日子過得緊張而又無趣。

今年年初，疫情覆蓋全國，造成了大小型互聯(lián)網(wǎng)公司全面縮水裁員，我們公司也不例外（公司不養(yǎng)閑人這個上班族都是明白的）毫無意外我被裁掉。本來感覺生活很無趣又慘遭下崗，這樣的打擊差點讓我崩潰。（不過后來我知道，這是個提升自己的契機）

微服務(wù)是什么

微服務(wù)起源于2005年P(guān)eter Rodgers博士在云端運算博覽會提出的微Web服務(wù)(Micro-Web-Service)，根本思想類似于Unix的管道設(shè)計理念。2014年，由Martin Fowler 與 James Lewis共同提出了微服務(wù)的概念，定義了微服務(wù)架構(gòu)風(fēng)格是一種通過一套小型服務(wù)來開發(fā)單個應(yīng)用的方法，每個服務(wù)運行在自己的進程中，并通過輕量級的機制進行通訊（HTTP API）。關(guān)鍵的三點是small、automated以及l(fā)ightweight。

對比SOA，微服務(wù)可以看做是SOA的子集，是輕量級的SOA，粒度更細的服務(wù)，獨立進程、數(shù)據(jù)分離，更注重敏捷、持續(xù)交付、DevOps以及去中心化實踐。其共同的架構(gòu)原理：

• 單一職責(zé)

• 關(guān)注分離：

  控制與邏輯相分離

• 模塊化和分而治之

特點：

• 用服務(wù)進行組件化

• 圍繞業(yè)務(wù)能力進行組織

• 是產(chǎn)品而非項目

• 端點智能化和啞管道: 控制邏輯都在端點，管道僅僅是傳輸

• 全自動化部署

• 語言和數(shù)據(jù)的去中心化控制

• 面向失敗設(shè)計

• 漸進式設(shè)計

綜合來看，其優(yōu)缺點如下：

優(yōu)點：

• 模塊的強邊界

• 獨立部署

• 技術(shù)選型的多樣性

缺點：

• 分布式帶來編程復(fù)雜度，遠程調(diào)用的消耗

• 舍棄強一致性，實現(xiàn)最終一致性

• 操作復(fù)雜性要求有一個成熟的運維團隊或者運維基礎(chǔ)設(shè)施

為什么要采用微服務(wù)

是否選擇微服務(wù)取決于你要設(shè)計的系統(tǒng)的復(fù)雜度。微服務(wù)是用來把控復(fù)雜系統(tǒng)的，但是隨之而來的就是引入了微服務(wù)本身的復(fù)雜度。需要解決包括自動化部署、監(jiān)控、容錯處理、最終一致性等其他分布式系統(tǒng)面臨的問題。即使已經(jīng)有一些普遍使用的解決方案，但是仍然是有不小的成本的。

生產(chǎn)力和復(fù)雜度的關(guān)系如圖所示，可見系統(tǒng)越復(fù)雜，微服務(wù)帶來的收益越大。此外，無論是單體應(yīng)用還是微服務(wù)，團隊的技能都需要能夠把控住。

馬丁.福勒的一個觀點是：除非管理單體應(yīng)用的成本已經(jīng)太復(fù)雜了（太大導(dǎo)致很難修改和部署），否則都不要考慮微服務(wù)。大部分應(yīng)用都應(yīng)該選擇單體架構(gòu)，做好單體應(yīng)用的模塊化而不是拆分成服務(wù)。

因此，系統(tǒng)一開始采用單體架構(gòu)，做好模塊化，之后隨著系統(tǒng)變得越來越復(fù)雜、模塊/服務(wù)間的邊界越來越清晰，再重構(gòu)為微服務(wù)架構(gòu)是一個合理的架構(gòu)演化路徑。

四個可以考慮上微服務(wù)的情況：

多人開發(fā)一個模塊/項目，提交代碼頻繁出現(xiàn)大量沖突。

模塊間嚴重耦合，互相依賴，每次變動需要牽扯多個團隊，單次上線需求太多，風(fēng)險大。

主要業(yè)務(wù)和次要業(yè)務(wù)耦合，橫向擴展流程復(fù)雜。

熔斷降級全靠if-else。

微服務(wù)的三個階段：

微服務(wù)1.0：

僅使用注冊發(fā)現(xiàn)，基于SpringCloud或者Dubbo進行開發(fā)。

微服務(wù)2.0：

使用了熔斷、限流、降級等服務(wù)治理策略，并配備完整服務(wù)工具和平臺。

微服務(wù)3.0：

Service Mesh將服務(wù)治理作為通用組件，下沉到平臺層實現(xiàn)，應(yīng)用層僅僅關(guān)注業(yè)務(wù)邏輯，平臺層可以根據(jù)業(yè)務(wù)監(jiān)控自動調(diào)度和參數(shù)調(diào)整，實現(xiàn)AIOps和智能調(diào)度。

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

先決條件

• 快速的環(huán)境提供能力：

  依賴于云計算、容器技術(shù)，快速交付環(huán)境。

• 基本的監(jiān)控能力：

  包括基礎(chǔ)的技術(shù)監(jiān)控和業(yè)務(wù)監(jiān)控。

• 快速的應(yīng)用部署能力：

  需要部署管道提供快速的部署能力。

• Devops文化：

  需要具有良好的持續(xù)交付能力，包括全鏈路追蹤、快速環(huán)境提供和部署等，還需要快速的反應(yīng)能力（對問題、故障的快速響應(yīng)），開發(fā)和運維的協(xié)同工作。

此外，根據(jù)康威定律和逆康威定律（技術(shù)架構(gòu)倒逼組織架構(gòu)改進），組織架構(gòu)也是一個很關(guān)鍵的因素。對應(yīng)于微服務(wù)架構(gòu)，組織架構(gòu)需要遵循以下原則：

一個微服務(wù)由一個團隊維護，團隊成員以三人為宜。

單個團隊的任務(wù)和發(fā)展是獨立的，不受其他因素影響。

團隊是功能齊全、全棧、自治的，扁平、自我管理。

基礎(chǔ)設(shè)施

微服務(wù)的推行需要依賴于很多底層基礎(chǔ)設(shè)施，包括提供微服務(wù)的編譯、集成、打包、部署、配置等工作，采用PaaS平臺解決微服務(wù)從開發(fā)到運行的全生命周期管理，同時提供異構(gòu)環(huán)境管理、容器資源隔離與互通、服務(wù)伸縮漂移、服務(wù)升級與回退、服務(wù)熔斷與降級、服務(wù)注冊與發(fā)現(xiàn)。

最基本的基礎(chǔ)設(shè)施

• 進程間通訊機制：

  微服務(wù)是獨立進程的，需要確定之間的通訊方式。

• 服務(wù)發(fā)現(xiàn)+服務(wù)路由: 提供服務(wù)注冊中心，服務(wù)提供者和消費者通過服務(wù)發(fā)現(xiàn)獲取服務(wù)的信息從而調(diào)用服務(wù)，實現(xiàn)服務(wù)的負載均衡等。

• 服務(wù)容錯：

  微服務(wù)架構(gòu)中，由于服務(wù)非常多，往往是一個服務(wù)掛了，整個請求鏈路的服務(wù)都受到影響，因此需要服務(wù)容錯，在服務(wù)調(diào)用失敗的時候能夠處理錯誤或者快速失敗，包括熔斷、fallback、重試、流控和服務(wù)隔離等。

• 分布式事務(wù)支持：

  隨著業(yè)務(wù)拆分為服務(wù)，那么有時候不可避免的就是跨服務(wù)的事務(wù)，即分布式事務(wù)的問題。

  原則是盡量避免分布式事務(wù)，如果無法避免那么可以使用消息系統(tǒng)或者CQRS和Event Sourcing方案來實現(xiàn)最終一致性。

  如果需要強一致性，則有兩階段提交、三階段提交、TCC等分布式事務(wù)解決方案。

提升外部服務(wù)對接效率和內(nèi)部開發(fā)效率

• API網(wǎng)關(guān): 負責(zé)外部系統(tǒng)的訪問，負責(zé)跨橫切面的公共層面的工作，包括安全、日志、權(quán)限控制、傳輸加密、請求轉(zhuǎn)發(fā)、流量控制等。

  典型的網(wǎng)關(guān)功能即對外暴露一個域名xx.com，根據(jù)第一級目錄做反向路由xx.com/user，xx.com/trade。

  每一級目錄，如user、trade對應(yīng)一個服務(wù)的域名。

  此外，API網(wǎng)關(guān)也可以有服務(wù)編排的功能（不推薦）。

• 接口框架: 規(guī)范服務(wù)之間通訊使用的數(shù)據(jù)格式、解析包、自解釋文檔，便于服務(wù)使用方快速上手等。

提升測試和運維效率

• 持續(xù)集成：

  這一部分并非是微服務(wù)特定的，對于之前的單體應(yīng)用，此部分一般來說也是必要的。

  主要是指通過自動化手段，持續(xù)地對代碼進程編譯構(gòu)建、自動化測試，以得到快速有效的質(zhì)量反饋，從而保證代碼的順利交付。

  自動化測試包括代碼級別的單元測試、單個系統(tǒng)的集成測試、系統(tǒng)間的接口測試。

• 自動化部署：

  微服務(wù)架構(gòu)，節(jié)點數(shù)動輒上百上千，自動化部署能夠提高部署速度和部署頻率，從而保證持續(xù)交付。

  包括版本管理、資源管理、部署操作、回滾操作等功能。

  而對于微服務(wù)的部署方式，包括藍綠部署、滾動部署以及金絲雀部署。

• 配置中心: 運行時配置管理能夠解決動態(tài)修改配置并批量生效的問題。

  包括配置版本管理、配置項管理、節(jié)點管理、配置同步等。

• 持續(xù)交付：

  包括持續(xù)集成、自動化部署等流程。

  目的就是小步迭代，快速交付。

進一步提升運維效率

• 服務(wù)監(jiān)控: 微服務(wù)架構(gòu)下節(jié)點數(shù)目眾多，需要監(jiān)控的機器、網(wǎng)絡(luò)、進程、接口等的數(shù)量大大增加，需要一個強大的監(jiān)控系統(tǒng)，能夠提供實時搜集信息進行分析以及實時分析之上的預(yù)警。

  包括監(jiān)控服務(wù)的請求次數(shù)、響應(yīng)時間分布、最大/最小響應(yīng)值、錯誤碼分布等

• 服務(wù)跟蹤：

  跟蹤一個請求的完整路徑，包括請求發(fā)起時間、響應(yīng)時間、響應(yīng)碼、請求參數(shù)、返回結(jié)果等信息，也叫做全鏈路跟蹤。

  通常的服務(wù)監(jiān)控可以和服務(wù)監(jiān)控做在一起，宏觀信息由服務(wù)跟蹤呈現(xiàn)，微觀單個服務(wù)/節(jié)點的信息由服務(wù)監(jiān)控呈現(xiàn)。

  服務(wù)跟蹤目前的實現(xiàn)理論基本都是Google的Dapper論文。

• 服務(wù)安全：

  內(nèi)網(wǎng)之間的微服務(wù)調(diào)用原則上講應(yīng)該是都可以互相訪問寫，一般并不需要權(quán)限控制，但有時候限于業(yè)務(wù)要求，會對接口、數(shù)據(jù)等方面有安全控制的要求。

  此部分可以以配置的方式存在于服務(wù)注冊中心中，和服務(wù)綁定，在請求時由做為服務(wù)提供者的服務(wù)節(jié)點進行安全策略控制。

  配置則可以存儲在配置中心以方便動態(tài)修改。

在微服務(wù)數(shù)量很少的情況下，以上基礎(chǔ)設(shè)施的優(yōu)先級自上而下降低。否則，僅僅依賴人工操作，則投入產(chǎn)出比會很低。

還需要提到的是Docker容器技術(shù)。雖然這個對于微服務(wù)并不是必須的，但是容器技術(shù)輕量級、靈活、與應(yīng)用依存、屏蔽環(huán)境差異的特性對于持續(xù)交付的實現(xiàn)是至關(guān)重要的，即使對于傳統(tǒng)的單體應(yīng)用也能夠給其帶來交付效率的大幅提升。

架構(gòu)設(shè)計模式

在引入微服務(wù)之后，傳統(tǒng)的單體應(yīng)用變?yōu)榱艘粋€一個服務(wù)，之前一個應(yīng)用直接提供接口給客戶端訪問的架構(gòu)不再適用。微服務(wù)架構(gòu)下，針對不同設(shè)備的接口做為BFF層（Backend For Frontend），也叫做用戶體驗適配層，負責(zé)聚合、編排微服務(wù)的數(shù)據(jù)轉(zhuǎn)換成前端需要的數(shù)據(jù)。服務(wù)之間的調(diào)用則在允許的情況下（允許延遲）盡可能使用異步消息傳遞方式，如此形成面向用戶體驗的微服務(wù)架構(gòu)設(shè)計模式。如下圖所示：

Client -> API Gateway -> BFF（Backend For Frontend） -> Downstream Microservices

• 后臺采用微服務(wù)架構(gòu)，微服務(wù)可以采用不同的編程語言和不同的存儲機制。

• 前臺采用BFF模式對不同的用戶體驗（如桌面瀏覽器，Native App，平板響應(yīng)式Web）進行適配。

• BFF、API Orchestration Layer，Edge Service Layer，Device Wrapper Layer是相同的概念。

• BFF不能過多，過多會造成代碼邏輯重復(fù)冗余。

• 可以將網(wǎng)關(guān)承擔(dān)的功能，如Geoip、限流、安全認證等跨橫切面功能和BFF做在同一層，雖然增加了BFF層的復(fù)雜性，但能夠得到性能優(yōu)勢。

服務(wù)拆分

微服務(wù)架構(gòu)最核心的環(huán)節(jié)，主要是對服務(wù)的橫向拆分。服務(wù)拆分就是講一個完整的業(yè)務(wù)系統(tǒng)解耦為服務(wù)，服務(wù)需要職責(zé)單一，之間沒有耦合關(guān)系，能夠獨立開發(fā)和維護。

服務(wù)拆分不是一蹴而就的，需要在開發(fā)過程中不斷地理清邊界。在完全理清服務(wù)之前，盡量推遲對服務(wù)的拆分，尤其是對數(shù)據(jù)庫的拆分。

拆分方法如下：

• 基于業(yè)務(wù)邏輯拆分

• 基于可擴展拆分

• 基于可靠性拆分

• 基于性能拆分

其中，對于無法修改的遺留系統(tǒng)，采用絞殺者模式：在遺留系統(tǒng)外面增加新的功能做成微服務(wù)方式，而不是直接修改原有系統(tǒng)，逐步的實現(xiàn)對老系統(tǒng)替換。

拆分過程需要遵守的規(guī)范如下：

• 先少后多、先粗后細（粒度）

• 服務(wù)縱向拆分最多三層，兩次調(diào)用：

  Controller、組合服務(wù)、基礎(chǔ)服務(wù)

• 僅僅單向調(diào)用，禁止循環(huán)調(diào)用

• 串行調(diào)用改為并行調(diào)用或者異步化

• 接口應(yīng)該冪等

• 接口數(shù)據(jù)定義嚴禁內(nèi)嵌，透傳

• 規(guī)范化工程名

• 先拆分服務(wù)，等服務(wù)粒度確定后再拆分數(shù)據(jù)庫。

微服務(wù)框架

上面講述了微服務(wù)架構(gòu)的眾多基礎(chǔ)設(shè)施，如果每一個基礎(chǔ)設(shè)施都需要自己開發(fā)的話是非常巨大的開發(fā)工作。目前市面上已經(jīng)有不少開源的微服務(wù)框架可以選擇。

Spring Boot

Spring Boot是用來簡化新Spring應(yīng)用的初始搭建以及開發(fā)過程的。其雖然不是微服務(wù)框架，但其設(shè)計的初衷本質(zhì)就是微應(yīng)用的底層框架，因此非常適合用于微服務(wù)基礎(chǔ)設(shè)施的開發(fā)以及微服務(wù)的應(yīng)用開發(fā)。尤其對于Spring技術(shù)棧的團隊來說，基于Spring Boot開發(fā)微服務(wù)框架和應(yīng)用是自然而然的一個選擇。

Dubbo&&Motan

Dubbo阿里開源的服務(wù)治理框架。其出現(xiàn)在微服務(wù)理念興起之前，可以看做是SOA框架的集大成之作。但其僅僅包含了微服務(wù)基礎(chǔ)設(shè)施的部分功能，諸如熔斷、服務(wù)跟蹤、網(wǎng)關(guān)等都沒有實現(xiàn)。

Motan則是微博開源的類似Dubbo的RPC框架，與Dubbo相比更輕量級。

• 服務(wù)發(fā)現(xiàn) ：

  服務(wù)發(fā)布、訂閱、通知

• 高可用策略 ：

  失敗重試（Failover）、快速失敗（Failfast）、資源隔離 - 負載均衡 ：

  最少活躍連接、一致性 Hash、隨機請求、輪詢等

• 擴展性 ：

  支持 SPI 擴展（service provider interface）

• 其他 ：

  調(diào)用統(tǒng)計、訪問日志等

Spring Cloud

Spring Cloud是基于Spring Boot實現(xiàn)的微服務(wù)框架，也可以看做一套微服務(wù)實現(xiàn)規(guī)范。基本涵蓋了微服務(wù)基礎(chǔ)設(shè)施的方方面面，包括配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線、全局鎖、決策競選、分布式會話和集群狀態(tài)管理等。其基于Spring生態(tài)，社區(qū)支持非常好。但其很多組件都沒有經(jīng)過生產(chǎn)環(huán)境驗證，需要慎重選擇。

Spring Cloud Netflix是Spring Cloud的一個子項目，是Spring對Netflix OSS的集成實現(xiàn)。基于Netflix的大規(guī)模使用，其中的已經(jīng)被廣泛使用的組件包括：

此外，另一個子項目Spring Cloud Alibaba則是Alibaba開源的基于Spring Boot的微服務(wù)框架，主要是對阿里云服務(wù)的支持。

• Eureka：

  服務(wù)注冊和服務(wù)發(fā)現(xiàn)

• Ribbon：

  彈性而智能的進程間和服務(wù)通訊機制，客戶端負載均衡

• Hystrix：

  熔斷器，在運行時提供延遲和容錯的隔離

• Zuul: 服務(wù)網(wǎng)關(guān)

Service Mesh

上述的微服務(wù)框架都是侵入式的，服務(wù)化的過程都需要進行代碼改造。Service Mesh則是下一代微服務(wù)架構(gòu)，最明顯的特征就是無入侵。采用sidecar模式來解決系統(tǒng)架構(gòu)微服務(wù)化后的服務(wù)間通信和治理問題。如下圖所示：

目前主流的開源實現(xiàn)包括：

限于Service Mesh帶來的性能延遲的開銷以及sidecar對分布復(fù)雜性的增加，其對大規(guī)模部署(微服務(wù)數(shù)目多)、異構(gòu)復(fù)雜(交互協(xié)議/開發(fā)語言類型多)的微服務(wù)架構(gòu)帶來的收益會更大。

• Linkerd和Envoy：

  以 sidecar 為核心，關(guān)注如何做好proxy，并完成一些通用控制平面的功能。

  缺乏對這些sidecar的管理和控制。

• Istio和Conduit：

  目前最為流行的Service Mesh實現(xiàn)方案，集中在更加強大的控制平面(sidecar被稱為數(shù)據(jù)平面)功能。

  前者由Google和IBM合作，并使用了Envoy作為sidecar部分的實現(xiàn)；

  后者則是Linkerd作者的作品。

  相比起來，Istio有巨頭背景，功能強大，但可用性和易用性一直不高，Conduit則相對簡單、功能聚焦。

Sofastack

螞蟻金服開源的構(gòu)建金融級分布式架構(gòu)的一套中間件。包括微服務(wù)開發(fā)框架、RPC框架、服務(wù)注冊中心、全鏈路追蹤、服務(wù)監(jiān)控、Service Mesh等一整套分布式應(yīng)用開發(fā)工具。

特別值得一提的是SOFAMesh。其是對下一代微服務(wù)架構(gòu)Service Mesh的大規(guī)模落地方案實踐，基于 Istio改進和擴展而來，應(yīng)該是國內(nèi)最為成熟的開源Service Mesh方案。

此外，需要提到Kubernetes(K8s)，其本身提供了部分的微服務(wù)特性支持（通過域名做服務(wù)發(fā)現(xiàn)），對代碼無侵入。但服務(wù)調(diào)用、熔斷這些都需要自己實現(xiàn)。

綜上，目前公司技術(shù)團隊技術(shù)棧是Spring，并且已有服務(wù)的實現(xiàn)都是基于Dubbo，因此選擇Spring Cloud Netflix做為基礎(chǔ)的微服務(wù)框架，對其中不成熟或者缺乏的組件，選擇業(yè)界更為成熟的組件替代即可。

• API網(wǎng)關(guān)：

  Zuul

• 服務(wù)注冊中心：

  Dubbo

• 配置中心：

  disconf

• 服務(wù)監(jiān)控&&全鏈路追蹤：

  CAT

• 服務(wù)開發(fā)框架：

  Spring Boot

• 日志監(jiān)控、告警：

  ELK + Elasalert

• 流量控制：

  Sentinel

• 消息隊列：

  Kafka

總結(jié)

總的來說，面試是有套路的，一面基礎(chǔ)，二面架構(gòu)，三面?zhèn)€人。

最后，小編這里收集整理了一些資料，其中包括面試題（含答案）、書籍、視頻等。希望也能幫助想進大廠的朋友，點擊這里即可免費獲取

CAT

• 服務(wù)開發(fā)框架：

  Spring Boot

• 日志監(jiān)控、告警：

  ELK + Elasalert

• 流量控制：

  Sentinel

• 消息隊列：

  Kafka

總結(jié)

總的來說，面試是有套路的，一面基礎(chǔ)，二面架構(gòu)，三面?zhèn)€人。

最后，小編這里收集整理了一些資料，其中包括面試題（含答案）、書籍、視頻等。希望也能幫助想進大廠的朋友，點擊這里即可免費獲取

[外鏈圖片轉(zhuǎn)存中…(img-NnkTbWSH-1621572290252)]

[外鏈圖片轉(zhuǎn)存中…(img-VSTM5zBz-1621572290253)]

[外鏈圖片轉(zhuǎn)存中…(img-zuZ9sY2i-1621572290254)]

總結(jié)

以上是生活随笔為你收集整理的干货来袭！手动搭建高可用的Redis5-0分片集群的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。