個人認(rèn)為一名優(yōu)秀的架構(gòu)師應(yīng)該具備如下幾個特點：

第一、強(qiáng)烈的好奇心。

????不只是對軟件技術(shù)本身，對大千世界都保持強(qiáng)烈的好奇心，強(qiáng)烈的好奇心能夠讓你敏銳地發(fā)現(xiàn)有潛力的重要的新技術(shù)；

第二、敏銳的業(yè)務(wù)嗅覺。

????工程技術(shù)不同于科學(xué)研究，工程技術(shù)最終要服務(wù)于實際業(yè)務(wù)的，要產(chǎn)生實際價值，是要賺錢的，那么業(yè)務(wù)需要什么樣的功能，需要什么樣的技術(shù)去實現(xiàn)，都需要有敏銳的業(yè)務(wù)嗅覺；

第三、扎實的技術(shù)基礎(chǔ)。

????基本功一定要扎實，如操作系統(tǒng)、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)庫原理，編程語言和算法原理，設(shè)計模式和設(shè)計原則等。只要這些軟件技術(shù)基礎(chǔ)都扎實了，才能構(gòu)建起敏銳的技術(shù)嗅覺，才能構(gòu)建起自己堅實的技術(shù)體系；

第四、出色的編程能力。

????雖然可能再需要你寫代碼，但是要有出色的編程能力，這樣才能對架構(gòu)中那些最敏感的技術(shù)點保持敏銳的技術(shù)嗅覺，能夠抓住軟件的關(guān)鍵點，不會在紛繁復(fù)雜的問題中迷失方向；

第五、深刻領(lǐng)悟主流技術(shù)產(chǎn)品和模式。

????架構(gòu)師不是憑空進(jìn)行架構(gòu)設(shè)計，是站在巨人的肩膀上，在現(xiàn)有的其他優(yōu)秀架構(gòu)基礎(chǔ)上進(jìn)一步設(shè)計出符合自己業(yè)務(wù)特點的架構(gòu)系統(tǒng)。只有深刻領(lǐng)悟主流技術(shù)產(chǎn)品和模式是如何設(shè)計的，才能根據(jù)自己的業(yè)務(wù)特點，去其糟粕，做最好的匹配和改進(jìn)，從而設(shè)計出屬于自己的優(yōu)秀的系統(tǒng)。

架構(gòu)師的學(xué)習(xí)可從如下幾個方面著手：

第一、基礎(chǔ)方面：包括數(shù)據(jù)結(jié)構(gòu)、操作系統(tǒng)、算法應(yīng)用、設(shè)計模式等一切擁有優(yōu)秀編程能力所應(yīng)該熟知的軟件基礎(chǔ)知識；

第二、技術(shù)方面：如何使用優(yōu)秀的技術(shù)產(chǎn)品去構(gòu)建自己的系統(tǒng)，這些技術(shù)產(chǎn)品各自的特點是什么，有什么優(yōu)缺點、具體原理是怎樣的？都要有深刻掌握和理解。對大型互聯(lián)網(wǎng)系統(tǒng)而言，主要包括緩存、異步、分布式存儲、微服務(wù)等；

第三、架構(gòu)方面：考慮點主要包括高可用、高性能、高擴(kuò)展這三部分

總之，作為一名技術(shù)人，我們既然選擇了這個職業(yè)，就一定要有上進(jìn)的決心，不能只顧寫代碼，一定要提升架構(gòu)設(shè)計能力。因為即使代碼寫得再好，做的也是執(zhí)行層面的事兒，就會有收入的天花板，想要突破它，就要突破你做事兒的邊界，讓自己成為一個架構(gòu)師或技術(shù)負(fù)責(zé)人。

分布式：

什么是分布式架構(gòu)？

????當(dāng)系統(tǒng)的并發(fā)處理能力，存儲能力等不足時，我們可能會創(chuàng)建多個Web服務(wù)(多個tomcat 服務(wù)器),多個數(shù)據(jù)庫服務(wù)(主動架構(gòu)等)，這些服務(wù)器通過網(wǎng)絡(luò)進(jìn)行連接，然后協(xié)同處理客戶端的并發(fā)請求，這樣的系統(tǒng)我們稱之為分布式系統(tǒng)。（這里要說明的一點是微服務(wù)架構(gòu)是分布式架構(gòu)，但分布式架構(gòu)不一定是微服務(wù)架構(gòu)）例如：

為什么需要分布式架構(gòu)？

????當(dāng)一個系統(tǒng)的業(yè)務(wù)量越來越大時，我們需要垂直或是水平拆分業(yè)務(wù)系統(tǒng)，同時為了避免所有業(yè)務(wù)都部署在一臺機(jī)器上時，一旦機(jī)器出現(xiàn)故障從而導(dǎo)致整體不可用，就需要將這些業(yè)務(wù)部署在多臺計算機(jī)上，來構(gòu)建一個分布式架構(gòu)。

?????分布式架構(gòu)可以更好的提高系統(tǒng)的容量、可靠性（避免單點故障）、性能。同時因為模塊化，系統(tǒng)的可重用性以及并行開發(fā)的效率也會提高。

分布式架構(gòu)有哪些優(yōu)勢？

1.????? 可以實現(xiàn)更大數(shù)據(jù)量的存儲。（字節(jié)跳動每天幾十個 PB 的數(shù)據(jù)）

2.????? 可以更好提高系統(tǒng)的高可用性。（業(yè)務(wù)冗余、業(yè)務(wù)拆分、限流、降級….）

3.????? 可以更好提高系統(tǒng)的可重用性。(公共模塊-例如訂單系統(tǒng)、支付系統(tǒng)，日志收集系統(tǒng)，監(jiān)控系統(tǒng)，。。。)

4.????? 可以更好提高系統(tǒng)的性能。（并行處理能力）

分布式架構(gòu)有什么劣勢？

? ??分布式系統(tǒng)架構(gòu)雖然解決了“單點”、“性能”和”容量“的問題，但卻新增了一些新的問題。

???1.會增加架構(gòu)設(shè)計的難度。

????2.部署和維護(hù)的成本也會加大。

?很多技術(shù)方案都是“按下葫蘆浮起瓢”，都是有得有失，分布式架構(gòu)也是如此，理性面對即可。

分布式架構(gòu)有哪些關(guān)鍵技術(shù)？

服務(wù)治理。

????服務(wù)治理的最大意義是需要把服務(wù)間的依賴關(guān)系、服務(wù)調(diào)用鏈，以及關(guān)鍵的服務(wù)給梳理出來，并對這些服務(wù)進(jìn)行性能和可用性方面的管理。

架構(gòu)管理。

????基于服務(wù)所形成的架構(gòu)需要有架構(gòu)版本管理、整體架構(gòu)的生命周期管理，以及對服務(wù)的編排、聚合、事務(wù)處理等服務(wù)調(diào)度功能。

DevOps。

????分布式系統(tǒng)可以更為快速地更新服務(wù)，但是對于服務(wù)的測試和部署都會是挑戰(zhàn)。所以，還需要DevOps的全流程，其中包括環(huán)境構(gòu)建、持續(xù)集成、持續(xù)部署等。自動化運維。有DevOps 后，我們就可以對服務(wù)進(jìn)行自動伸縮、故障遷移、配置管理、狀態(tài)管理等 一系列的自動化運維技術(shù)了。

資源調(diào)度管理。

?????應(yīng)用層的自動化運維需要基礎(chǔ)層的調(diào)度支持，也就是云計算IaaS層的計算、存儲、網(wǎng)絡(luò)等資源調(diào)度、隔離和管理。

整體架構(gòu)監(jiān)控。

????如果沒有一個好的監(jiān)控系統(tǒng)，那么自動化運維和資源調(diào)度管理只可能成為一個泡影， 因為監(jiān)控系統(tǒng)是你的眼睛。沒有眼睛，沒有數(shù)據(jù)，就無法進(jìn)行高效的運維。所以說，監(jiān)控是非常重要 的部分。這里的監(jiān)控需要對三層系統(tǒng)（應(yīng)用層、中間件層、基礎(chǔ)層）進(jìn)行監(jiān)控。

流量控制

????我們的流量控制，負(fù)載均衡、服務(wù)路由、熔斷、降級、限流等和流量相關(guān)的調(diào)度都 會在這里，包括灰度發(fā)布之類的功能也在這里。

基于分布式架構(gòu)如何提高其高性能？

???一般面對這樣的問題，從整體維度去思考時，通常要分析問題，例如影響系統(tǒng)性能的因素有哪些？??

1)? 請求數(shù)據(jù)的處理時間

2)? 響應(yīng)數(shù)據(jù)的傳輸時間

3)? 響應(yīng)數(shù)據(jù)的渲染時間 （json->html/css/js）

解決方案如下：

1)? 減少數(shù)據(jù)傳輸時間？(加帶寬，減少數(shù)據(jù)傳輸量，減少傳輸距離，數(shù)據(jù)壓縮)

2)? 提高請求數(shù)據(jù)的處理速度？(分布式架構(gòu)，緩存，算法，sql調(diào)優(yōu)，索引的設(shè)計，異步，硬件)

3)? 提高數(shù)據(jù)在客戶端的渲染時間？(局部更新，減少不必要的元素等)

具體從架構(gòu)層面進(jìn)行設(shè)計的話可以從如下幾個維度進(jìn)行思考：

應(yīng)用緩存。

????為系統(tǒng)添加緩存，可以有效地提高系統(tǒng)的訪問能力。從前端的瀏覽?，到網(wǎng)絡(luò)，再到后端的服務(wù)，底層的數(shù)據(jù)庫、文件系統(tǒng)、硬盤和CPU，全都有緩存，這是提高快速訪問能力最有效的手段。

負(fù)載均衡。

????負(fù)載均衡是做水平擴(kuò)展的關(guān)鍵技術(shù)，我們可以使用多臺機(jī)?來共同分擔(dān)一部分流量請求。

異步調(diào)用。

????異步系統(tǒng)主要通過消息隊列來對請求做排隊處理，這樣可以把前端的請求的峰值給“削平”

了，而后端通過自己能夠處理的速度來處理請求。

數(shù)據(jù)分區(qū)和數(shù)據(jù)鏡像。

????數(shù)據(jù)分區(qū)是把數(shù)據(jù)按一定的方式分成多個區(qū)（比如通過地理位置），不同的數(shù)據(jù)區(qū)來分擔(dān)不

同區(qū)的流量。

如何基于架構(gòu)提高系統(tǒng)的穩(wěn)定性？

服務(wù)拆分：服務(wù)拆分可以更好的實現(xiàn)故障隔離，同時也可以重用服務(wù)模塊。

服務(wù)冗余：服務(wù)冗余是為了去除單點故障，支持服務(wù)的彈性伸縮，以及故障遷移。

限流降級：當(dāng)系統(tǒng)扛不住壓力時，只能通過限流或者功能降級的方式來停掉一部分服務(wù)，或是拒絕一部分用戶，以確保整個架構(gòu)不會掛掉。

高可用架構(gòu)：高可用就是從冗余架構(gòu)的角度來保障可用性。比如多租戶隔離，災(zāi)備多活等?？傊褪菫?/span>了不出單點故障。

高可用運維：指的是 DevOps 中的 CI（持續(xù)集成）/CD（持續(xù)部署）。一個良好的運維應(yīng)做了足夠的自動化測試，做了相應(yīng)的灰度發(fā)布，以及對線上系統(tǒng)的自動化控制。這樣，可以做到“計劃內(nèi)”或是“非計劃內(nèi)”的宕機(jī)事件的時長最短。

?分布式架構(gòu)有什么難點？

異構(gòu)系統(tǒng)存在很多不標(biāo)準(zhǔn)問題

????構(gòu)建軟件時使用的編程語言、通訊協(xié)議、數(shù)據(jù)格式、運維標(biāo)準(zhǔn)可能不同，進(jìn)而導(dǎo)致架構(gòu)設(shè)計的復(fù)雜度越來越高。

系統(tǒng)架構(gòu)中的服務(wù)依賴問題。

????傳統(tǒng)的單體應(yīng)用，一臺機(jī)器掛了，整個軟件就掛掉了，分布式架構(gòu)下也可能會出現(xiàn)這樣的問題，因為一個服務(wù)可能會依賴于另一個服務(wù)，某個服務(wù)掛掉了，會導(dǎo)致調(diào)用鏈上的服務(wù)都出現(xiàn)故障（這就是多米諾骨牌效應(yīng)）

故障發(fā)生的概率更大。

????分布式系統(tǒng)中，服務(wù)和機(jī)器都會比較多，故障發(fā)生的頻率會更大，只是影響面沒有單體應(yīng)用的影響面大，分布式系統(tǒng)中故障可以被隔離。還有就是分布式架構(gòu)管理相對于單體架構(gòu)也更加復(fù)雜，沒有優(yōu)秀的架構(gòu)管理人員，故障的頻率還是會非常高。

多層架構(gòu)的運維復(fù)雜度更大。

????分布式架構(gòu)中，我們可以將系統(tǒng)分為四層(基礎(chǔ)層、平臺層、應(yīng)用層、接入層)。

1)基礎(chǔ)層:包括機(jī)器、網(wǎng)絡(luò)和存儲設(shè)備。

2)平臺層:就是中間件層包括tomcat、MySQL、Redis、Kafka類似的軟件。

3)應(yīng)用層:就是我們的業(yè)務(wù)軟件，包括各種業(yè)務(wù)服務(wù)。

4)接入層:就是接入用戶請求的網(wǎng)關(guān)、負(fù)載均衡、CDN、DNS等。

微服務(wù)入門

什么是微服務(wù)？

????微服務(wù)是一種分布式架構(gòu)，簡單點就是將整體大應(yīng)用，基于業(yè)務(wù)打散為更為微小的服務(wù)。然后作為獨立的進(jìn)程進(jìn)行開發(fā)、測試、部署、運行、維護(hù)。

微服務(wù)架構(gòu)誕生的背景？

????服務(wù)大了太臃腫，要拆成若干個小系統(tǒng)，然后進(jìn)行分而治之（例如北京一個火車站到多個火車站）。

這樣分了以后，可以把每個服務(wù)作為一個獨立的開發(fā)項目，由團(tuán)隊進(jìn)行快速開發(fā)、迭代升級。

為什么需要微服務(wù)架構(gòu)？

????對系統(tǒng)分而治之,故障隔離、同時解決因并發(fā)訪問過大帶來的系統(tǒng)復(fù)雜性(例如:業(yè)務(wù),開發(fā), 測試,升級,可靠性等)

微服務(wù)架構(gòu)可能帶來什么問題？

????數(shù)據(jù)一致性問題、網(wǎng)絡(luò)通信故障、限流與熔斷機(jī)制、調(diào)用鏈路跟蹤(sleuth與zipkin)、集群監(jiān)控、用戶登錄與權(quán)限管理。

微服務(wù)解決方案有哪些？

????????大廠一般會自研,中小企業(yè)采用開源 Spring Cloud Netfix（大部分組件停止更新）， Spring Cloud Alibaba（一站式解決方案）,Spring Clound Tencent(一站式解決方案) 等

微服務(wù)架構(gòu)中有哪些關(guān)鍵組件？

????注冊中心、配置中心,限流降級,API網(wǎng)關(guān),鏈路追蹤和監(jiān)控，統(tǒng)一認(rèn)證服務(wù)，分布式事務(wù)管理等。

注冊中心部分

服務(wù)注冊中心誕生的背景？

????注冊中心本質(zhì)上就是存儲服務(wù)信息的一個服務(wù),也可以理解為一個中介(這里用到了中介者模式)。我們知道服務(wù)多了，需要統(tǒng)一管理。例如所有公司需要在工商局進(jìn)行備案，淘寶也可以理解為買家和賣家的注冊中心。

服務(wù)注冊中心你是如何選型的？

????選型時，我們首先要從這樣的幾個維度進(jìn)行思考：

1)? 社區(qū)活躍度(用戶群的大小)

2)? 穩(wěn)定性

3)? 功能

4)? 性能

5)? 學(xué)習(xí)成本。

你了解哪些服務(wù)注冊中心？

????Zookeeper,Eureka,Nacos(阿里),Consul

說說你對 Nacos 的理解？

????Nacos是Alibaba基于SpringBoot技術(shù)實現(xiàn)的一個注冊中心,配置中心，本質(zhì)上也是一個 web服務(wù)，提供了服務(wù)的注冊,發(fā)現(xiàn),配置等功能?？梢宰鳛楦鱾€服務(wù)的一個中介，也就是所謂的中介者模式。

Nacos 如何檢測服務(wù)狀態(tài)？

????通過心跳包實現(xiàn),服務(wù)啟動時會定時向nacos發(fā)送心跳包-BeatInfo。默認(rèn)是每隔5秒發(fā)送一次，Nacos會通過對心跳包的監(jiān)控判斷服務(wù)的狀態(tài)(是否健康)。

Nacos 注冊中心有哪些常用配置？

服務(wù)之間進(jìn)行調(diào)用你是如何實現(xiàn)的 ？

????在微服務(wù)架構(gòu)中，服務(wù)之間調(diào)用一般有兩種方式：

?1)? Restful方式（直接基于http協(xié)議進(jìn)行遠(yuǎn)端服務(wù)調(diào)用，數(shù)據(jù)格式標(biāo)準(zhǔn)，通用性強(qiáng)，代表作品有SpringCloud中的OpenFeign）

?2)? RPC方式(直接基于tcp協(xié)議進(jìn)行遠(yuǎn)端服務(wù)調(diào)用，協(xié)議數(shù)據(jù)格式不夠通用，但是效率會比較好，代表組件有Dubbo)

你是如何理解 OpenFeign 的？

????它基于restful方式進(jìn)行聲明式服務(wù)調(diào)用的一個服務(wù)調(diào)用組件，它可以嵌入到服務(wù)調(diào)用的客戶端服務(wù)中，然后由客戶端基于Feign代理以及Restful規(guī)范進(jìn)行服務(wù)調(diào)用。

微服務(wù)調(diào)用過程中你用的負(fù)載均衡組件是什么？

????SpringCloud中基于Feign方式進(jìn)行遠(yuǎn)程服務(wù)調(diào)用時，負(fù)載均衡組件默認(rèn)使用的是Ribbon。Ribbon組件中內(nèi)置了一些負(fù)載均衡算法，我們可以基于業(yè)務(wù)、策略選擇不同的算法進(jìn)行服務(wù)的負(fù)載均衡調(diào)用。

常用負(fù)載均衡算法有哪些？

????輪詢、哈希（每次請求都對應(yīng)同一個服務(wù)器）、權(quán)重(能者多勞)、重試、隨機(jī)等

配置中心部分

誕生的背景？

????實際項目中我們會有很多配置，例如連接數(shù)據(jù)庫的配置，日志級別的配置，負(fù)載均衡的配置，限流算法的配置，緩存是否開啟等，這些配置起初可能是寫在配置文件，但是項目上線以后，我們直接再通過配置文件方式修改具體配置就不太方便了，即使可以，那我們修改了配置件是否要重啟系統(tǒng)呢？你重啟氣筒時，系統(tǒng)是否要停止對外界服務(wù)呢？，基于這些問題“配置中心”就誕生了。

什么是配置中心？

????配置中心是存儲項目（服務(wù)）配置信息的一個服務(wù)，這個服務(wù)可以對所有服務(wù)的配置進(jìn)行統(tǒng)一管理，并且可以實現(xiàn)配置的動態(tài)發(fā)布和更新（更新了配置中心的數(shù)據(jù)，微服務(wù)中的配置數(shù)據(jù)會自動更新）。

為什么要使用配置中心？

????集中管理配置信息，動態(tài)發(fā)布配置信息，服務(wù)自動感知配置,提高服務(wù)可用性。例如實際項目中我們數(shù)據(jù)庫的賬號和密碼可能每隔兩周或 1 個月都要更新一下（更新的目的是要保證系統(tǒng)的安全），假如應(yīng)用了配置中心，我們可以直接在配置中心進(jìn)行更新即可，它會自動同步到具體的服務(wù)，我們不需要重啟服務(wù)就可以獲取最新的配置了。

你在配置中心配置過什么內(nèi)容？

????連接數(shù)據(jù)庫配置，負(fù)載均衡策略、連接池，日志、緩存、限流、熔斷規(guī)則。

為什么要定義 bootstrap.yml 文件？

????此文件屬于系統(tǒng)級配置文件，被讀取的優(yōu)先級比較高（比application.yml的優(yōu)先級還要高），可以在服務(wù)啟動時基于這個配置文件中的配置，訪問配置中心，然后讀取配置中心的數(shù)據(jù)。然后通過這些數(shù)據(jù)來更新配置。

配置中心宕機(jī)了，還可以讀到配置信息嗎？

????配置中心的數(shù)據(jù)可以在服務(wù)本地存儲一份，所以配置中心宕機(jī)了，可以從本地內(nèi)存讀取。

微服務(wù)配置中心如何感知配置中心的配置的變化？

????1.4.x版本中的nacos客戶端會基于長輪詢機(jī)制從nacos獲取配置信息。這個輪詢可以這樣去理解，我們騎著共享單車去火車站買票，但是票賣完了，一種方式是直接返回（這種方式稱之為短輪詢）。還有一種方式在火車站的椅子上等一會，看看是否還會放票，是否有人會退票等。那這種機(jī)制就是長輪詢(nacos默認(rèn)長輪訓(xùn)的時間為30秒，就是服務(wù)會每隔30秒去訪問一次Nacos)。

Nacos 的配置管理模型是怎樣的？

????在nacos中的配置管理模型中，一個namespace可以有多個分組（group），每個分組下又可以有多個服務(wù)實例。例如：namespace>group>service/data-id

Nacos 配置中心基礎(chǔ)配置有哪些？

限流降級部分

為什么要限流？

????請求量比較大,但是系統(tǒng)資源處理能力不足。類似車輛限號。

你了解哪些限流組件？

????阿里巴巴的Sentinel(雙十一),....

你了解哪些限流算法？

????計數(shù)器,令牌桶,漏桶,滑動窗口算法。

Sentinel 如何對請求進(jìn)行限流？

????可以基于Spring MVC 攔截器以及aop方式對請求進(jìn)行限流（鏈路限流、熱點數(shù)據(jù)限流）。當(dāng)請求傳遞到服務(wù)端后，服務(wù)器可以調(diào)用攔截器對請求進(jìn)行攔截，判定此請求是否允許放行，請求量太大可能就要被限制了。當(dāng)然在熱點數(shù)據(jù)限流上還可以通過AOP方式進(jìn)行限制。

Sentinel 出現(xiàn)限流時的異常類型是什么？

????BlockException（限流的異常類型-父類類型）

Sentinel 中默認(rèn)的異常處理器是什么？

????DefaultBlockExceptionHandler ，假如默認(rèn)的異常處理器不能滿足我們需求時，可以自己定義異常處理器，直接或間接繼承BlockExceptionHandler。

Sentinel 限流的閾值類型有哪些？
????QPS（每秒請求次數(shù)），線程數(shù)（不準(zhǔn)確，應(yīng)用相對較少）

?Sentinel 的流控模式有哪些？

1)直接模式：直接對請求url進(jìn)行限流，

2)關(guān)聯(lián)模式：一種霸權(quán)主義，要保證我(核心業(yè)務(wù))先行。

3)鏈路模式：對同一個資源的訪問有多條鏈路，然后對指定鏈路進(jìn)行限流。

?如何理解 Sentinel 的關(guān)聯(lián)限流？

????霸權(quán)方式,當(dāng)對A的資源的訪問量比較大時,限流其它資源的訪問(例如我們可以優(yōu)先保證創(chuàng)建訂單可以成功、查詢訂單可以被限流)

如何理解 Sentinel 的鏈路限流？

????對同一個資源的訪問,可能會有多條鏈路,可以對指定鏈路進(jìn)行限流。（例如對Google的訪問）。

@SentinelResource 注解的作用是什么？

????定義限流切入點方法,底層可以基于 aop 方式對請求鏈路進(jìn)行限制（一般應(yīng)用于鏈路限流、熱點數(shù)據(jù)限流）。對應(yīng)的切面（SentinelResourceAspect）。

Sentinel 常見的限流效果是什么？

????快速失?。⊕伋霎惓＃?warm up（預(yù)熱方式-3秒放100請求）,排隊等待（超過的QPS的數(shù)量的請求等待）

什么是服務(wù)降級？

????系統(tǒng)出現(xiàn)大量的慢調(diào)用（一個請求響應(yīng)的時間比較長）或一些異常（經(jīng)常運行過程中會出現(xiàn)異常），可以對這些服務(wù)進(jìn)行熔斷-暫時關(guān)閉系統(tǒng)

如何理解慢調(diào)用？

????客戶端發(fā)起一個請求，得到服務(wù)端的響應(yīng)比較慢。當(dāng)然一般會給出一個時間標(biāo)準(zhǔn)（我們自己定義）

如何理解熱點數(shù)據(jù)？

???頻繁訪問的數(shù)據(jù)-例如文章、視頻、圖片、....?

Sentinel 如何判斷哪些數(shù)據(jù)是熱點數(shù)據(jù)？

????LRU算法（最近最少使用算法-一般應(yīng)用于緩存淘汰策略。）

對熱點數(shù)據(jù)限流，底層基于什么機(jī)制去實現(xiàn)？

????AOP (@SentinelResuource注解定義切入點方法，然后在SentinelResourceAspect切面中基于限流策略，進(jìn)行限流。)

?API網(wǎng)關(guān)部分

為什么要使用 API 網(wǎng)關(guān)？

1)統(tǒng)一url訪問（Restful，RPC）:一個頁面中的數(shù)據(jù)可能來自多個服務(wù)

2)服務(wù)保護(hù)（不對外暴露內(nèi)部服務(wù)的真實地址，同時可以對外部請求進(jìn)行校驗）

3)統(tǒng)一身份認(rèn)證（單點登陸系統(tǒng)-不用每個服務(wù)都編寫一個登陸認(rèn)證模塊-公園的通票）

4)統(tǒng)一跨域設(shè)計（跨域可以在客戶端配置，也可以在服務(wù)端配置-例如nginx,gateway,…）

5)限流降級(通過Sentinel實現(xiàn)限流和降級)

6)黑白名單(通過全局過濾器GlobalFilter去實現(xiàn)對請求的統(tǒng)一校驗)

API 網(wǎng)關(guān)都可以配置什么？

1)動態(tài)路由（uri，predicate，filter）

2)統(tǒng)一身份認(rèn)證

3)負(fù)載均衡(Ribbon)

4)黑白名單設(shè)計(自定義)

5)限流熔斷(Sentinel)

6)跨域等

7)……

API 網(wǎng)關(guān)中的負(fù)載均衡如何實現(xiàn)？

Ribbon

SpringCloud Gateway 處理請求的基本流程？

1)客戶端向Spring Cloud Gateway發(fā)出請求。

2)基于GatewayHandlerMapping調(diào)用謂詞predicates(predicates)的集合判定請求與路由(Routers)是否匹配，不匹配則拋出異常。

3)將請求其發(fā)送到 Gateway Web Handler。此對象基于路由配置調(diào)用過濾鏈中的過濾器

（也就是所謂的責(zé)任鏈模式）進(jìn)一步的處理請求。

4)將請求轉(zhuǎn)發(fā)到具體的服務(wù)。

?網(wǎng)關(guān)中謂詞(Predicate)的作用是什么？

????這里的Predicate都是基于Jdk8中的Predicate接口實現(xiàn)的，用于對請求url、請求數(shù)據(jù)進(jìn)行校驗，符合規(guī)則再交給過濾器去處理。

你知道哪些謂詞對象(Predicate)對象？

1)? Path相關(guān)的 （請求路徑是否匹配）

2)? 日期時間相關(guān)的 （請求時間的限制）

3)? IP相關(guān)的 （ip地址的限制）

4)? Cookie相關(guān)的 (基于Cookie中數(shù)據(jù)的限制)

5)? 請求參數(shù)相關(guān)的?

6)? 請求方式相關(guān)

7)? 請求頭相關(guān)的

8)? 上傳文件大小相關(guān)的

網(wǎng)關(guān)中的過濾器是如何分類的？

1）全局過濾器(不需要配置)，作用于所有路由。

2）局部過濾器（這個需要針對具體路由進(jìn)行配置），只作用于具體路由。

你知道 Gateway 中的哪些過濾器？

1)? 負(fù)載均衡相關(guān)的

2)? 請求轉(zhuǎn)發(fā)相關(guān)的

3)? 限流相關(guān)的

4)? 請求前綴、后綴相關(guān)的

API Gateway 如何基于 Sentinel 進(jìn)行限流？

1)? 依賴

2)? 配置

分布式事務(wù)

什么是分布式事務(wù)？

????分布式事務(wù)是分布式架構(gòu)下的一種事務(wù)處理方式，是指位于不同的節(jié)點之上的事務(wù)參與者，執(zhí)行一系列操作時，要確保這些操作要么都執(zhí)行成功，要么都執(zhí)行失敗。本質(zhì)上來說，就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

分布式系統(tǒng)中的 CAP 定理是什么？

分布式系統(tǒng)有三個指標(biāo)：

1)Consistency：一致性

2)Availability：可用性

3)Partition tolerance：分區(qū)容錯性?

這三個指標(biāo)不可能同時滿足，這個定理就叫CAP定理。

在分布式系統(tǒng)中，通常分區(qū)容錯性是必須滿足的，可用性(AP)和一致性(CP)只能選擇其一。

BASE 理論是什么？

Base全稱是Basically Available（基本可用），Soft state（軟狀態(tài)），和 Eventually consistent（最終一致性）三個短語的縮寫，BASE理論是對CAP中一致性和可用性權(quán)衡的結(jié)果，核心思想是：即使無法做到強(qiáng)一致性，但每個應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點，采用適當(dāng)?shù)姆绞絹硎瓜到y(tǒng)達(dá)到最終一致性（通?？梢詫⑦@種事務(wù)方式理解柔性事務(wù)）。

分布式事務(wù)中的二階段提交？

????分布式事務(wù)中增加了一個新的角色，事務(wù)協(xié)調(diào)者（Coordinator），它的職責(zé)就是協(xié)調(diào)各個分支事務(wù)的開啟與提交、回滾的處理。當(dāng)一個訂單創(chuàng)建時，首先事務(wù)協(xié)調(diào)者會向各服務(wù)下達(dá)“處理本地事務(wù)”的通知，所謂本地事務(wù)就是每個服務(wù)應(yīng)該做的事情，如訂單服務(wù)中負(fù)責(zé)創(chuàng)建新的訂單記錄；會員服務(wù)負(fù)責(zé)增加會員的積分；庫存服務(wù)負(fù)責(zé)減少庫存數(shù)量。在這個階段，被操作的所有數(shù)據(jù)都處于未提交（uncommit）的狀態(tài)，會被排它鎖鎖定。這個階段也是二階段提交中的第一階段（也稱之為預(yù)處理階段），如圖所示：

當(dāng)本地事務(wù)都處理完成后，會通知事務(wù)協(xié)調(diào)者“本地事務(wù)處理完畢”。當(dāng)事務(wù)協(xié)調(diào)者陸續(xù)收到訂單、會員、庫存服務(wù)的處理完畢通知后，便進(jìn)入“階段二：提交階段”。在提交階段，事務(wù)協(xié)調(diào)者會向每一個服務(wù)下達(dá)提交命令，每個服務(wù)收到提交命令后在本地事務(wù)中對階段一未提交的數(shù)據(jù)執(zhí)行 Commit 提交以完成數(shù)據(jù)最終的寫入，之后服務(wù)便向事務(wù)協(xié)調(diào)者上報“提交成功”的通知。當(dāng)事務(wù)協(xié)調(diào)者收到所有服務(wù)“提交成功”的通知后，就意味著一次分布式事務(wù)處理已完成。

這便是二階段提交的正常執(zhí)行過程，但假設(shè)在階段一有任何一個服務(wù)因某種原因向事務(wù)協(xié)調(diào)者上報“事務(wù)處理失敗”，就意味著整體業(yè)務(wù)處理出現(xiàn)問題，階段二的操作就自動改為回滾（Rollback）處理，將所有未提交的數(shù)據(jù)撤銷，使數(shù)據(jù)還原以保證完整性。

?分布式事務(wù)中二階段提交有什么缺陷？

????對于二階段提交來說，它有一個致命問題，當(dāng)階段二某個服務(wù)因為網(wǎng)絡(luò)原因無法收到協(xié)調(diào)者下達(dá)的提交命令，則未提交的數(shù)據(jù)就會被長時間阻塞，可能導(dǎo)致系統(tǒng)崩潰。

?????以上圖為例，假如在提交階段，庫存服務(wù)實例與事務(wù)協(xié)調(diào)者之間斷網(wǎng)。提交指令無法下達(dá)，這會導(dǎo)致商品庫存記錄會長期處于未提交的狀態(tài)，因為這條記錄被數(shù)據(jù)庫排他鎖長期獨占，之后再有其他線程要訪問庫存數(shù)據(jù)，該線程就會長期處于阻塞狀態(tài)，隨著阻塞線程的不斷增加，庫存服務(wù)會面臨崩潰的風(fēng)險。

????那這個問題要怎么解決呢？其實只要在服務(wù)這一側(cè)增加超時機(jī)制，過一段時間被鎖定的庫存數(shù)據(jù)因超時自動執(zhí)行提交操作，釋放鎖定資源。盡管這樣做會導(dǎo)致數(shù)據(jù)不一致，但也比線程積壓導(dǎo)致服務(wù)崩潰要好，出于此目的，三階段提交（3PC）便應(yīng)運而生。
分布式事務(wù)中的三階段提交？

????三階段提交實際上是將二階段中的提交階段拆分為“預(yù)提交階段”與“提交階段”，同時在服務(wù)端都引入超時機(jī)制，保證數(shù)據(jù)庫資源不會被長時間鎖定。下面是三階段提交的示意流程：

階段1：事務(wù)預(yù)處理階段，3PC 的事務(wù)預(yù)處理階段與 2PC 是一樣的，用于處理本地事務(wù)，鎖定數(shù)據(jù)庫資源，例如：

階段 2:當(dāng)所有服務(wù)返回成功后，進(jìn)入階段二。預(yù)提交階段只是一個詢問機(jī)制，以確認(rèn)所有服務(wù)都已準(zhǔn)備好，同時在此階段協(xié)調(diào)者和參與者都設(shè)置了超時時間以防止出現(xiàn)長時間資源鎖定。

當(dāng)階段二所有服務(wù)返回“可以提交”，進(jìn)入階段三“提交階段”。3PC 的提交階段與 2PC 的提交階段是一致的，在每一個數(shù)據(jù)庫中執(zhí)行提交實現(xiàn)數(shù)據(jù)的資源寫入，如果協(xié)調(diào)者與服務(wù)通信中斷導(dǎo)致無法提交，在服務(wù)端超時后在也會自動執(zhí)行提交操作來保證資源釋放。

三階段提交本質(zhì)上是二階段提交的優(yōu)化版本，主要通過加入預(yù)提交階段引入了超時機(jī)制，讓數(shù)據(jù)庫資源不會被長期鎖定，但這也會帶來一個新問題，數(shù)據(jù)一致性也很可能因為超時后的強(qiáng)制提交被破壞，對于這個問題各大軟件公司都在各顯神通，常見的做法有：增加異步的數(shù)據(jù)補(bǔ)償任務(wù)、更完善的業(yè)務(wù)數(shù)據(jù)完整性的校驗代碼、引入數(shù)據(jù)監(jiān)控及時通知人工補(bǔ)錄這些都是不錯的補(bǔ)救措施。

Seata 是什么

????Seata是Alibaba開源的一款分布式事務(wù)解決方案，致力于在微服務(wù)架構(gòu)下提供高性能和簡單易用的分布式事務(wù)服務(wù)。它的官網(wǎng)是http://seata.io/。

Seata 提供了哪些分布式事務(wù)方案？

1)???? AT 模式（是 Seata 主推的分布式事務(wù)解決方案，對業(yè)務(wù)無侵入，真正做到業(yè)務(wù)與事務(wù)分離）

2)???? TCC 模式（對業(yè)務(wù)代碼侵入性太強(qiáng)。沒有 AT 模式全局鎖，加鎖邏輯需要根據(jù)業(yè)務(wù)自行實現(xiàn)。因此 TCC 的性能會比 AT 模式更好）

3)???? SAGA 模式（Saga 模式的正向服務(wù)和補(bǔ)償服務(wù)都需要手動實現(xiàn)，因此有很強(qiáng)的侵入性。能保證隔離性，不容易進(jìn)行并發(fā)控制）

4)???? XA 模式 （利用事務(wù)資源實現(xiàn)對 XA 協(xié)議的支持，是傳統(tǒng)分布式強(qiáng)一致性的解決方案，性能較低，在實際業(yè)務(wù)中使用較少。）

什么是 AT 模式事務(wù)？

AT(Automatic Transaction) 全自動事務(wù)，是Seata提供的一種事務(wù)方案。采用了簡單易用且無侵入的事務(wù)處理機(jī)制，通過自動生成反向 SQL 實現(xiàn)事務(wù)回滾。

反向SQL如何理解？

insert into test(id,name) values (1,’Jason’);

delete from test where id=1;(可以將這樣的語句理解為上面SQL的反向SQL)

AT 模式事務(wù)有什么特點??

AT 模式是 Seata 獨創(chuàng)的模式，它是基于 2PC(兩階段提交) 的方案，核心理念是利用數(shù)據(jù)庫 JDBC 加上 Oracle、MySQL 自帶的事務(wù)方式來對我們分布式事務(wù)進(jìn)行管理。其主要特點如下：

1)???? 對業(yè)務(wù)無侵入，通過配置即可實現(xiàn)。

2)???? AT 事務(wù)使用一個數(shù)據(jù)源(DataSource)代理對象來實現(xiàn)自動化事務(wù)處理。

3)???? AT 事務(wù)執(zhí)行分兩個階段：第一階段：執(zhí)行本地事務(wù)。

第二階段：全局事務(wù)提交，或全局事務(wù)回滾。

AT 事務(wù)使用 undo_log 表保存回滾日志，事務(wù)執(zhí)行失敗時，會根據(jù)回滾日志表來回滾數(shù)據(jù)。

Seata 的三大組件是什么？

Seata有三個組成部分：

1)?? 第一個是事務(wù)協(xié)調(diào)者（TC），它的作用是維護(hù)全局和分支事務(wù)的狀態(tài)，驅(qū)動全局事務(wù)提交或者回滾，這正是前面所說 2PC 或者 3PC 方案時提到的事務(wù)協(xié)調(diào)者組件的具體實現(xiàn)，TC 由 SEATA 官方提供。

2)?? 第二個是事務(wù)管理器（TM），事務(wù)管理器用于定義全局事務(wù)的范圍，開始全局事務(wù)提交或者回滾全局事務(wù)都是由 TM 來決定。

3)?? 第三個是資源管理器（RM），他用于管理分支事務(wù)處理的資源，并且報告分支事務(wù)的狀態(tài)，并驅(qū)動分支事務(wù)提交或者回滾。

Seata 事務(wù)協(xié)調(diào)器(TC)的作用是什么？

協(xié)調(diào)各個模塊的執(zhí)行，例如：

-? 啟動全局事務(wù)。

-? 收集各模塊第一階段的運行狀態(tài)。

向各個模塊發(fā)送第二階段提交或回滾指令。

Seata 事務(wù)管理器(TM)的主要作用是什么？

????負(fù)責(zé)主要全局事務(wù)決策，例如： - 向協(xié)調(diào)器申請啟動全局事務(wù)。

-? 收集所有模塊第一階段的運行狀態(tài)，并對全局事務(wù)的成功或失敗進(jìn)行決策。

-? 將決策結(jié)果提交給事務(wù)協(xié)調(diào)器。

資源管理器(RM)的作用是什么？

在各個模塊中與協(xié)調(diào)器通信，并控制第二階段的執(zhí)行：

-? 在每個模塊中向協(xié)調(diào)器注冊分支事務(wù)。

-? 向協(xié)調(diào)器提交第一階段的執(zhí)行狀態(tài)。

-? 接收協(xié)調(diào)器第二階段的指令，控制執(zhí)行二階段的提交或回滾。

?AT 事務(wù)中數(shù)據(jù)源代理對象作用是什么？

自動保存事務(wù)回滾日志。

第二階段提交時，刪除回滾日志。

第二階段回滾時，執(zhí)行根據(jù)回滾日志回滾數(shù)據(jù)，并刪除日志。

說說 TCC 模式的事務(wù)？

CC 模式，全稱 Try-Confirm-Cancel，通過名稱也能看出來其流程主要有三個步驟：

1)???? 預(yù)處理 Try：實現(xiàn)業(yè)務(wù)檢查和資源預(yù)留

2)???? 確認(rèn)/提交 Confirm：業(yè)務(wù)確認(rèn)和提交

3)???? 撤銷/回滾 Cancel：業(yè)務(wù)回滾

?????TCC 模式本身就是二階段提交的一種改進(jìn)，不一樣的是，這次就沒有 AT 模式那么方便了，因為他需要我們自己寫代碼來實現(xiàn)了。Seata 中的 TCC 模式的實現(xiàn)關(guān)鍵在于拆分二階段，也就是如何把一步操作拆分為兩步，比如庫存扣減，本身就是一個 update 語句，但是 TCC 下卻需要我們拆分為先凍結(jié)庫存，然后再扣減這部分庫存

案例分析(重要)

交易系統(tǒng)服務(wù)拆分問題？

負(fù)責(zé)一個交易系統(tǒng)的實現(xiàn)，并將系統(tǒng)拆分成了報價系統(tǒng)、促銷系統(tǒng)、訂單系統(tǒng)。那現(xiàn)在的問題是，為什么要進(jìn)行系統(tǒng)拆分，而且拆分后帶來的其它復(fù)雜度，

答：

1） 從訂單系統(tǒng)層面來看，由于交易流程中的訂單系統(tǒng)相對來說業(yè)務(wù)穩(wěn)定，不存在很多的迭代需求，如果耦合到整個交易系統(tǒng)中，在其他功能發(fā)布上線的時候會影響訂單系統(tǒng)，比如訂單中心的穩(wěn)定性?；谶@樣的考慮，需要拆分出一個獨立的子系統(tǒng)。

2） 從促銷系統(tǒng)層面來看，由于促銷系統(tǒng)是交易流程中的非核心系統(tǒng)，出于保障交易流程穩(wěn)定性的考慮，將促銷系統(tǒng)單獨拆分出來，在發(fā)生異常的時候能讓促銷系統(tǒng)具有可降級的能力。

3） 從報價系統(tǒng)層面來看，報價是業(yè)務(wù)交易流程中最為復(fù)雜和靈活的系統(tǒng)，出于專業(yè)化和快速迭代的考慮，拆分出一個獨立的報價系統(tǒng)，目的就是為了快速響應(yīng)需求的變化。

????最后，從復(fù)雜度評估層面來看，系統(tǒng)拆分雖然會導(dǎo)致系統(tǒng)交互更加復(fù)雜，但在規(guī)范了API的格式定義和調(diào)用方式后，系統(tǒng)的復(fù)雜度可以維持在可控的范圍內(nèi)。

評系統(tǒng)邏輯設(shè)計是怎樣的？

????在電商中，當(dāng)用戶發(fā)表一條商品評論，后臺的邏輯是，點評系統(tǒng)會調(diào)用一系列的遠(yuǎn)程 API 接口，如調(diào)用風(fēng)控系統(tǒng)、廣告系統(tǒng)、圖片系統(tǒng)、消息系統(tǒng)等很多個外部系統(tǒng)接口，這樣的邏輯如何實現(xiàn)？

面對類似問題，我覺得應(yīng)該考慮這樣幾個層面？

第一：復(fù)雜度問題？（功能復(fù)雜度-耦合和非功能復(fù)雜度-高可用）

1)? 功能上假如這些系統(tǒng)之間的通訊是直接的RPC，那就意味著耦合可能會比較大，不利于擴(kuò)展。

2)? 非功能上(高性能-TPS/QPS、高可用)

?第二：有哪些可選解決方案？

1） 引入第三方消息隊列 （會帶來新的復(fù)雜度）

2） 基于Redis實現(xiàn)消息隊列

3） 基于內(nèi)存中數(shù)組實現(xiàn)消息隊列

?第三：你評估的標(biāo)準(zhǔn)是什么？

1） 功能復(fù)雜度

2） 非功能復(fù)雜度(無單點、可水平擴(kuò)展、可降級)

?第四：說一下你的技術(shù)實現(xiàn)？

?????當(dāng)你在確定了具體的架構(gòu)解決方案之后，需要進(jìn)一步說明你技術(shù)上的落地實現(xiàn)方式和原理，假如你最終選擇基于 Redis 來實現(xiàn)消息隊列，那么可以有幾種實現(xiàn)方式？各自的優(yōu)缺點有哪些？對于這些問題，要做到心里有數(shù)。比如，基于 Redis List 的 LPUSH 和 RPOP 的實現(xiàn)方式、基于 Redis 的訂閱或發(fā)布模式，或者基于 Redis 的有序集合（Sorted Set）的實現(xiàn)方式等等。