【MCA】Java互聯網高級架構師【馬士兵教育】

時間 2021-08-12

標籤 html 前端 java git 程序員 web redis spring 數據庫編程欄目 Java 简体版

原文原文鏈接

愛分享愛生活加油 2021

提取碼：qhhv 前端

一、微服務的優缺點分別是什麼?說下你在項目開發中碰到的坑。
優勢：
1) 每個服務足夠內聚,代碼容易理解
2) 開發效率提升,一個服務只作一件事
3) 微服務可以被小團隊單獨開發
4) 微服務是鬆耦合的,是有功能意義的服務
5) 能夠用不一樣的語言開發,面向接口編程
6) 易於與第三方集成
7) 微服務只是業務邏輯的代碼,不會和HTML,CSS或者其餘界面組合
8) 開發中,兩種開發模式
9) 先後端分離
10) 全棧工程師
11) 能夠靈活搭配,鏈接公共庫/鏈接獨立庫
缺點：
1) 分佈式系統的負責性
2) 多服務運維難度,隨着服務的增長,運維的壓力也在增大
3) 系統部署依賴
4) 服務間通訊成本
5) 數據一致性
6) 系統集成測試
7) 性能監控java

二、什麼是Spring Cloud？
Spring cloud流應用程序啓動器是基於Spring Boot的Spring集成應用程序，提供與外部系統的集成。Spring cloud Task，一個生命週期短暫的微服務框架，用於快速構建執行有限數據處理的應用程序。git

三、SpringBoot和SpringCloud
1) SpringBoot專一於快速方便的開發單個個體的微服務
2) SpringCloud是關注全局的微服務協調整理治理框架,整合並管理各個微服務,爲各個微服務之間提供,配置管理,服務發現,斷路器,路由,事件總線等集成服務
3) SpringBoot不依賴於SpringCloud,SpringCloud依賴於SpringBoot,屬於依賴關係
4) SpringBoot專一於快速,方便的開發單個的微服務個體,SpringCloud關注全局的服務治理框架程序員

四、SpringCloud和Dubbo
1) 區別
a. 服務的調用方式Dubbo使用的是RPC遠程調用,而SpringCloud使用的是 Rest API,其實更符合微服務官方的定義
b. 服務的註冊中心來看,Dubbo使用了第三方的ZooKeeper做爲其底層的註冊中心,實現服務的註冊和發現,SpringCloud使用Spring Cloud Netflix Eureka實現註冊中心,固然SpringCloud也可使用ZooKeeper實現,但通常咱們不會這樣作
c. 服務網關,Dubbo並無自己的實現,只能經過其餘第三方技術的整合,而SpringCloud有Zuul路由網關,做爲路由服務器,進行消費者的請求分發,SpringCloud還支持斷路器,與git完美集成分佈式配置文件支持版本控制,事務總線實現配置文件的更新與服務自動裝配等等一系列的微服務架構要素
2) 技術選型
a. 目前國內的分佈式系統選型主要仍是Dubbo畢竟國產,並且國內工程師的技術熟練程度高,而且Dubbo在其餘維度上的缺陷能夠由其餘第三方框架進行集成進行彌補
b. 而SpringCloud目前是國外比較流行,固然我以爲國內的市場也會慢慢的偏向SpringCloud,就連劉軍做爲Dubbo重啓的負責人也發表過觀點,Dubbo的發展方向是積極適應SpringCloud生態,並非起衝突
3) Rest和RPC對比
其實若是仔細閱讀過微服務提出者馬丁福勒的論文的話能夠發現其定義的服務間通訊機制就是Http Rest。
RPC最主要的缺陷就是服務提供方和調用方式之間依賴太強,咱們須要爲每個微服務進行接口的定義,並經過持續繼承發佈,須要嚴格的版本控制纔不會出現服務提供和調用之間由於版本不一樣而產生的衝突
而REST是輕量級的接口,服務的提供和調用不存在代碼之間的耦合,只是經過一個約定進行規範,但也有可能出現文檔和接口不一致而致使的服務集成問題,但能夠經過swagger工具整合,是代碼和文檔一體化解決,因此REST在分佈式環境下比RPC更加靈活
這也是爲何當當網的DubboX在對Dubbo的加強中增長了對REST的支持的緣由web

文檔質量和社區活躍度
SpringCloud社區活躍度遠高於Dubbo,畢竟因爲梁飛團隊的緣由致使Dubbo中止更新迭代五年,而中小型公司沒法承擔技術開發的成本致使Dubbo社區嚴重低落,而SpringCloud異軍突起,迅速佔領了微服務的市場,背靠Spring混的風生水起
Dubbo通過多年的積累文檔至關成熟,對於微服務的架構體系各個公司也有穩定的現狀

五、你所知道的微服務技術棧有哪些?請列舉一二。維度(SpringCloud)
1) 服務開發：SpringBoot、Spring、SpringMVC
2) 服務配置與管理：Netfilx公司的Archaiusm,阿里的Diamond
3) 服務註冊與發現：Eureka,ZooKeeper
4) 服務調用：Rest,RPC,gRPC
5) 服務熔斷器：Hystrix
6) 服務負載均衡：Ribbon,Nginx
7) 服務接口調用：Feign
8) 消息隊列：Kafka,RabbitMq,ActiveMq
9) 服務配置中心管理：SpringCloudConfing
10) 服務路由(API網關)：Zuul
11) 事件消息總線：SpringCloud Busredis

六、負載平衡的意義什麼？
在計算中，負載平衡能夠改善跨計算機，計算機集羣，網絡連接，中央處理單元或磁盤驅動器等多種計算資源的工做負載分佈。負載平衡旨在優化資源使用，最大化吞吐量，最小化響應時間並避免任何單一資源的過載。使用多個組件進行負載平衡而不是單個組件可能會經過冗餘來提升可靠性和可用性。負載平衡一般涉及專用軟件或硬件，例如多層交換機或域名系統服務器進程。spring

七、微服務之間是如何獨立通信的
1) 遠程過程調用（Remote Procedure Invocation）
也就是咱們常說的服務的註冊與發現，直接經過遠程過程調用來訪問別的service。
優勢：
簡單，常見,由於沒有中間件代理，系統更簡單
缺點：
a. 只支持請求/響應的模式，不支持別的，好比通知、請求/異步響應、發佈/訂閱、發佈/異步響應；
b. 下降了可用性，由於客戶端和服務端在請求過程當中必須都是可用的
2) 消息
使用異步消息來作服務間通訊。服務間經過消息管道來交換消息，從而通訊。
優勢:
a. 把客戶端和服務端解耦，更鬆耦合
b. 提升可用性，由於消息中間件緩存了消息，直到消費者能夠消費
c. 支持不少通訊機制好比通知、請求/異步響應、發佈/訂閱、發佈/異步響應
缺點:
消息中間件有額外的複雜性數據庫

八、springcloud如何實現服務的註冊和發現
服務在發佈時指定對應的服務名（服務名包括了IP地址和端口）將服務註冊到註冊中心（eureka或者zookeeper）
這一過程是springcloud自動實現只須要在main方法添加@EnableDisscoveryClient 同一個服務修改端口就能夠啓動多個實例
調用方法：傳遞服務名稱經過註冊中心獲取全部的可用實例經過負載均衡策略調用（ribbon和feign）對應的服務編程

九、Eureka和ZooKeeper均可以提供服務註冊與發現的功能,請說說兩個的區別。
1) Eureka取CAP中的AP，注重可用性。Zookepper取CAP理論中的CP強調高的一致性。
ZooKeeper在選舉期間註冊服務癱瘓,雖然服務最終會恢復,可是選舉期間不可用的
Eureka各個節點是平等關係,只要有一臺Eureka就能夠保證服務可用,而查詢到的數據並非最新的自我保護機制會致使
Eureka再也不從註冊列表移除因長時間沒收到心跳而應該過時的服務
Eureka仍然可以接受新服務的註冊和查詢請求,可是不會被同步到其餘節點(高可用)
當網絡穩定時,當前實例新的註冊信息會被同步到其餘節點中(最終一致性)
Eureka能夠很好的應對因網絡故障致使部分節點失去聯繫的狀況,而不會像ZooKeeper同樣使得整個註冊系統癱瘓
2) ZooKeeper有Leader和Follower角色,Eureka各個節點平等
3) ZooKeeper採用過半數存活原則,Eureka採用自我保護機制解決分區問題
4) Eureka本質上是一個工程,而ZooKeeper只是一個進程

十、eureka自我保護機制
當 Eureka Server 節點在短期內丟失了過多實例的鏈接時（好比網絡故障或頻繁的啓動關閉客戶端），那麼這個節點就會進入自我保護模式，一旦進入到該模式，Eureka server 就會保護服務註冊表中的信息，再也不刪除服務註冊表中的數據（即不會註銷任何微服務），當網絡故障恢復後，該 Ereaka Server 節點就會自動退出自我保護模式（個人 Eureka Server 已經幾個月了，至今未自動退出該模式）

十一、什麼是服務熔斷?什麼是服務降級
在複雜的分佈式系統中,微服務之間的相互調用,有可能出現各類各樣的緣由致使服務的阻塞,在高併發場景下,服務的阻塞意味着線程的阻塞,致使當前線程不可用,服務器的線程所有阻塞,致使服務器崩潰,因爲服務之間的調用關係是同步的,會對整個微服務系統形成服務雪崩
爲了解決某個微服務的調用響應時間過長或者不可用進而佔用愈來愈多的系統資源引發雪崩效應就須要進行服務熔斷和服務降級處理。
所謂的服務熔斷指的是某個服務故障或異常一塊兒相似顯示世界中的「保險絲"當某個異常條件被觸發就直接熔斷整個服務，而不是一直等到此服務超時。
服務熔斷就是至關於咱們電閘的保險絲,一旦發生服務雪崩的,就會熔斷整個服務,經過維護一個本身的線程池,當線程達到閾值的時候就啓動服務降級,若是其餘請求繼續訪問就直接返回fallback的默認值

十二、如何使用Eureka
1) 添加pom依賴
2) 配置文件添加相關配置
3) 啓動類添加註解@EnableDiscoveryClient

1三、什麼是Ribbon?
ribbon是一個負載均衡客戶端，能夠很好的控制htt和tcp的一些行爲。Feign默認集成了ribbon。
使用：
1) 添加pom依賴
2) 配置文件添加相關配置
3) 啓動類添加註解@EnableEurekaServer
4) 向程序的ioc注入一個bean: restTemplate;並經過@LoadBalanced註解代表這個restRemplate開啓負載均衡的功能
5) 寫一個測試類HelloService，經過以前注入ioc容器的restTemplate來消費service-hi服務的「/hi」接口
源碼：
Ribbon的負載均衡，主要經過LoadBalancerClient來實現的，而LoadBalancerClient具體交給了ILoadBalancer來處理，ILoadBalancer經過配置IRule、IPing等信息，並向EurekaClient獲取註冊列表的信息，並默認10秒一次向EurekaClient發送「ping」,進而檢查是否更新服務列表，最後，獲得註冊列表後，ILoadBalancer根據IRule的策略進行負載均衡。
而RestTemplate 被@LoadBalance註解後，能過用負載均衡，主要是維護了一個被@LoadBalance註解的RestTemplate列表，並給列表中的RestTemplate添加攔截器，進而交給負載均衡器去處理。

1四、什麼是Feign？它的優勢是什麼？
Feign是一個聲明式的僞Http客戶端，它使得寫Http客戶端變得更簡單。使用Feign，只須要建立一個接口並註解。它具備可插拔的註解特性，可以使用Feign 註解和JAX-RS註解。Feign支持可插拔的編碼器和解碼器。Feign默認集成了Ribbon，並和Eureka結合，默認實現了負載均衡的效果。
簡而言之：
Feign 採用的是基於接口的註解
Feign 整合了ribbon，具備負載均衡的能力
整合了Hystrix，具備熔斷的能力
使用：
1) 添加pom依賴
2) 配置文件添加相關配置
3) 啓動類添加註解@EnableFeignClients
4) 定義一個接口，使用註解@ FeignClient（「服務名」），來指定調用哪一個服務

源碼實現過程：
首先經過@EnableFeignCleints註解開啓FeignCleint
根據Feign的規則實現接口，並加@FeignCleint註解
程序啓動後，會進行包掃描，掃描全部的@ FeignCleint的註解的類，並將這些信息注入到ioc容器中。
當接口的方法被調用，經過jdk的代理，來生成具體的RequesTemplate
RequesTemplate在生成Request
Request交給Client去處理，其中Client能夠是HttpUrlConnection、HttpClient也能夠是Okhttp
最後Client被封裝到LoadBalanceClient類，這個類結合類Ribbon作到了負載均衡。

1五、Ribbon和Feign的區別：
Ribbon和Feign都是用於調用其餘服務的，不過方式不一樣。
1.啓動類使用的註解不一樣，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。
2.服務的指定位置不一樣，Ribbon是在@RibbonClient註解上聲明，Feign則是在定義抽象方法的接口中使用@FeignClient聲明。
3.調用方式不一樣，Ribbon須要本身構建http請求，模擬http請求而後使用RestTemplate發送給其餘服務，步驟至關繁瑣。
Feign則是在Ribbon的基礎上進行了一次改進，採用接口的方式，將須要調用的其餘服務的方法定義成抽象方法便可，
不須要本身構建http請求。不過要注意的是抽象方法的註解、方法簽名要和提供服務的方法徹底一致。

1六、什麼是Spring Cloud Bus？
Spring Cloud Bus 將分佈式的節點用輕量的消息代理鏈接起來。它能夠用於廣播配置文件的更改或者服務之間的通信，也能夠用於監控。
若是修改了配置文件，發送一次請求，全部的客戶端便會從新讀取配置文件
使用：
一、添加依賴
二、配置rabbitmq

1七、什麼是zuul?
Zuul的主要功能是路由轉發和過濾器。路由功能是微服務的一部分，好比／api/user轉發到到user服務，/api/shop轉發到到shop服務。zuul默認和Ribbon結合實現了負載均衡的功能。
使用：
一、添加pom依賴
二、配置文件添加相關配置
三、啓動類添加註解@EnableZuulProxy

在zuul中， 整個請求的過程是這樣的，首先將請求給zuulservlet處理，zuulservlet中有一個zuulRunner對象，該對象中初始化了RequestContext：做爲存儲整個請求的一些數據，並被全部的zuulfilter共享。zuulRunner中還有 FilterProcessor，FilterProcessor做爲執行全部的zuulfilter的管理器。FilterProcessor從filterloader 中獲取zuulfilter，而zuulfilter是被filterFileManager所加載，並支持groovy熱加載，採用了輪詢的方式熱加載。有了這些filter以後，zuulservelet首先執行的Pre類型的過濾器，再執行route類型的過濾器，最後執行的是post 類型的過濾器，若是在執行這些過濾器有錯誤的時候則會執行error類型的過濾器。執行完這些過濾器，最終將請求的結果返回給客戶端。

1八、什麼是Hystrix？它如何實現容錯？
Hystrix是一個延遲和容錯庫，旨在隔離遠程系統，服務和第三方庫的訪問點，當出現故障是不可避免的故障時，中止級聯故障並在複雜的分佈式系統中實現彈性。
一般對於使用微服務架構開發的系統，涉及到許多微服務。這些微服務彼此協做。
使用：
一、添加pom依賴
二、啓動類使用註解@EnableHystrix
三、在Service方法上加上@HystrixCommand註解。該註解對該方法建立了熔斷器的功能，並指定了fallbackMethod熔斷方法

** 1九、springcloud斷路器的做用**
當一個服務調用另外一個服務因爲網絡緣由或者自身緣由出現問題時調用者就會等待被調用者的響應當更多的服務請求到這些資源時，致使更多的請求等待這樣就會發生連鎖效應（雪崩效應）斷路器就是解決這一問題。
斷路器有徹底打開狀態：必定時間內達到必定的次數沒法調用而且屢次檢測沒有恢復的跡象斷路器徹底打開，那麼下次請求就不會請求到該服務
半開：短期內有恢復跡象斷路器會將部分請求發給該服務當能正常調用時斷路器關閉
關閉：當服務一直處於正常狀態能正常調用斷路器關閉

20、Spring Cloud Config
在分佈式系統中，因爲服務數量巨多，爲了方便服務配置文件統一管理，實時更新，因此須要分佈式配置中心組件。在Spring Cloud中，有分佈式配置中心組件spring cloud config ，它支持配置服務放在配置服務的內存中（即本地），也支持放在遠程Git倉庫中。在spring cloud config 組件中，分兩個角色，一是config server，二是config client。
使用：
一、添加pom依賴
二、配置文件添加相關配置
三、啓動類添加註解@EnableConfigServer

2一、Spring Cloud Gateway
Spring Cloud Gateway是Spring Cloud官方推出的第二代網關框架，取代Zuul網關。網關做爲流量的，在微服務系統中有着很是做用，網關常見的功能有路由轉發、權限校驗、限流控制等做用。
使用了一個RouteLocatorBuilder的bean去建立路由，除了建立路由RouteLocatorBuilder可讓你添加各類predicates和filters，predicates斷言的意思，顧名思義就是根據具體的請求的規則，由具體的route去處理，filters是各類過濾器，用來對請求作各類判斷和修改。

2二、架構：
在微服務架構中，須要幾個基礎的服務治理組件，包括服務註冊與發現、服務消費、負載均衡、斷路器、智能路由、配置管理等，由這幾個基礎組件相互協做，共同組建了一個簡單的微服務系統
在Spring Cloud微服務系統中，一種常見的負載均衡方式是，客戶端的請求首先通過負載均衡（zuul、Ngnix），再到達服務網關（zuul集羣），而後再到具體的服。，服務統一註冊到高可用的服務註冊中心集羣，服務的全部的配置文件由配置服務管理，配置服務的配置文件放在git倉庫，方便開發人員隨時改配置。

一、什麼是springboot

用來簡化spring應用的初始搭建以及開發過程使用特定的方式來進行配置（properties或yml文件）
建立獨立的spring引用程序 main方法運行
嵌入的Tomcat 無需部署war文件
簡化maven配置

二、什麼是 JavaConfig？
Spring JavaConfig 是 Spring 社區的產品，它提供了配置 Spring IoC 容器的純 Java 方法。所以它有助於避免使用 XML 配置。
使用 JavaConfig 的優勢在於：
面向對象的配置。因爲配置被定義爲 JavaConfig 中的類，所以用戶能夠充分利用 Java 中的面向對象功能。一個配置類能夠繼承另外一個，重寫它的@Bean 方法等。
減小或消除 XML 配置。基於依賴注入原則的外化配置的好處已被證實。可是，許多開發人員不但願在 XML 和 Java 之間來回切換。 JavaConfig 爲開發人員提供了一種純 Java 方法來配置與 XML 配置概念類似的 Spring 容器。從技術角度來說，只使用 JavaConfig 配置類來配置容器是可行的，但實際上不少人認爲將 JavaConfig 與 XML 混合匹配是理想的。
類型安全和重構友好。 JavaConfig 提供了一種類型安全的方法來配置 Spring 容器。因爲Java 5.0 對泛型的支持，如今能夠按類型而不是按名稱檢索 bean，不須要任何強制轉換或基於字符串的查找。

三、Spring Boot有哪些優勢？
答：

快速建立獨立運行的spring項目與主流框架集成
使用嵌入式的servlet容器，應用無需打包成war包
starters自動依賴與版本控制
大量的自動配置，簡化開發，也可修改默認值
準生產環境的運行應用監控
與雲計算的自然集成

四、Spring Boot 提供了哪些核心功能？

獨立運行 Spring 項目
內嵌 Servlet 容器
Spring Boot 能夠選擇內嵌 Tomcat、Jetty 或者 Undertow，這樣咱們無須以 war 包形式部署項目。
提供 Starter 簡化 Maven 配置
例如，當你使用了 spring-boot-starter-web ，會自動加入以下依賴：spring-boot-starter-web 的 pom 文件
自動配置 Spring Bean
Spring Boot 檢測到特定類的存在，就會針對這個應用作必定的配置，進行自動配置 Bean ，這樣會極大地減小咱們要使用的配置。
準生產的應用監控
Spring Boot 提供基於 HTTP、JMX、SSH 對運行時的項目進行監控。
無代碼生成和 XML 配置
Spring Boot 沒有引入任何形式的代碼生成，它是使用的 Spring 4.0 的條件 @Condition 註解以實現根據條件進行配置。同時使用了 Maven /Gradle 的依賴傳遞解析機制來實現 Spring 應用裏面的自動配置。

五、如何從新加載Spring Boot上的更改，而無需從新啓動服務器？
這可使用DEV工具來實現。經過這種依賴關係，您能夠節省任何更改，嵌入式tomcat將從新啓動。
Spring Boot有一個開發工具（DevTools）模塊，它有助於提升開發人員的生產力。Java開發人員面臨的一個主要挑戰是將文件更改自動部署到服務器並自動重啓服務器。
開發人員能夠從新加載Spring Boot上的更改，而無需從新啓動服務器。這將消除每次手動部署更改的須要。Spring Boot在發佈它的第一個版本時沒有這個功能。
這是開發人員最須要的功能。DevTools模塊徹底知足開發人員的需求。該模塊將在生產環境中被禁用。它還提供H2數據庫控制檯以更好地測試應用程序。

六、建立一個 Spring Boot Project 的最簡單的方法是什麼？
Spring Initializer 是建立 Spring Boot Projects 的一個很好的工具

七、運行 Spring Boot 有哪幾種方式？

打包成 Fat Jar ，直接使用 java -jar 運行。目前主流的作法，推薦。
在 IDEA 或 Eclipse 中，直接運行應用的 Spring Boot 啓動類的 #main(String[] args) 啓動。適用於開發調試場景。
若是是 Web 項目，能夠打包成 War 包，使用外部 Tomcat 或 Jetty 等容器。

八、Spring Boot中的監視器是什麼？
Spring boot actuator是spring啓動框架中的重要功能之一。Spring boot監視器可幫助您訪問生產環境中正在運行的應用程序的當前狀態。
有幾個指標必須在生產環境中進行檢查和監控。即便一些外部應用程序可能正在使用這些服務來向相關人員觸發警報消息。監視器模塊公開了一組可直接做爲HTTP URL訪問的REST端點來檢查狀態。

九、什麼是starter?
Starter主要是用來簡化maven依賴

十、Spring Boot 經常使用的 Starter 有哪些？
spring-boot-starter-web ：提供 Spring MVC + 內嵌的 Tomcat 。
spring-boot-starter-data-jpa ：提供 Spring JPA + Hibernate 。
spring-boot-starter-data-redis ：提供 Redis 。
mybatis-spring-boot-starter ：提供 MyBatis 。

十一、什麼是YAML？
YAML是一種人類可讀的數據序列化語言。它一般用於配置文件。
與屬性文件相比，若是咱們想要在配置文件中添加複雜的屬性，YAML文件就更加結構化，並且更少混淆。能夠看出YAML具備分層配置數據。

十二、如何集成Spring Boot和ActiveMQ？
對於集成Spring Boot和ActiveMQ，咱們使用spring-boot-starter-activemq依賴關係。它只須要不多的配置，而且不須要樣板代碼。

1三、springboot經常使用的starter有哪些？
spring-boot-starter-web 嵌入tomcat和web開發須要servlet與jsp支持
spring-boot-starter-data-jpa 數據庫支持
spring-boot-starter-data-redis redis數據庫支持
spring-boot-starter-data-solr solr支持
mybatis-spring-boot-starter 第三方的mybatis集成starter

1四、springboot自動配置的原理
在spring程序main方法中添加@SpringBootApplication或者@EnableAutoConfiguration
會自動去maven中讀取每一個starter中的spring.factories文件該文件裏配置了全部須要被建立spring容器中的bean

1五、springboot讀取配置文件的方式
springboot默認讀取配置文件爲application.properties或者是application.yml

1六、Spring Boot 須要獨立的容器運行嗎？
能夠不須要，內置了 Tomcat/ Jetty 等容器。

1七、運行 Spring Boot 有哪幾種方式？
1）打包用命令或者者放到容器中運行
2）用 Maven/ Gradle 插件運行
3）直接執行 main 方法運行

1八、Spring Boot 的核心配置文件有哪幾個？它們的區別是什麼？
Spring Boot 的核心配置文件是 application 和 bootstrap 配置文件。
application 配置文件這個容易瞭解，主要用於 Spring Boot 項目的自動化配置。
bootstrap 配置文件有如下幾個應用場景。
使用 Spring Cloud Config 配置中心時，這時須要在 bootstrap 配置文件中增長鏈接到配置中心的配置屬性來加載外部配置中心的配置信息；
少許固定的不能被覆蓋的屬性；
少許加密/解密的場景；

1九、Spring Boot 的核心註解是哪一個？它主要由哪幾個註解組成的？
啓動類上面的註解是@SpringBootApplication，它也是 Spring Boot 的核心註解，主要組合包含了如下 3 個註解：
@SpringBootConfiguration：組合了 @Configuration 註解，實現配置文件的功能。
@EnableAutoConfiguration：打開自動配置的功能，也能夠關閉某個自動配置的選項，如關閉數據源自動配置功能： @SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })。
@ComponentScan：Spring組件掃描

20、爲何咱們須要 spring-boot-maven-plugin?
spring-boot-maven-plugin 提供了一些像 jar 同樣打包或者運行應用程序的命令。
spring-boot:run 運行你的 SpringBooty 應用程序。
spring-boot：repackage 從新打包你的 jar 包或者是 war 包使其可執行
spring-boot：start 和 spring-boot：stop 管理 Spring Boot 應用程序的生命週期（也能夠說是爲了集成測試）。
spring-boot:build-info 生成執行器可使用的構造信息。

2一、如何使用Spring Boot實現分頁和排序？
使用Spring Boot實現分頁很是簡單。使用Spring Data-JPA能夠實現將可分頁的
org.springframework.data.domain.Pageable
傳遞給存儲庫方法。

2二、什麼是Swagger？你用Spring Boot實現了它嗎？
Swagger普遍用於可視化API，使用Swagger UI爲前端開發人員提供在線沙箱。Swagger是用於生成RESTful Web服務的可視化表示的工具，規範和完整框架實現。它使文檔可以以與服務器相同的速度更新。當經過Swagger正肯定義時，消費者可使用最少許的實現邏輯來理解遠程服務並與其進行交互。所以，Swagger消除了調用服務時的猜想。

2三、什麼是Spring Profiles？
Spring Profiles容許用戶根據配置文件（dev，test，prod等）來註冊bean。所以，當應用程序在開發中運行時，只有某些bean能夠加載，而在PRODUCTION中，某些其餘bean能夠加載。假設咱們的要求是Swagger文檔僅適用於QA環境，而且禁用全部其餘文檔。這可使用配置文件來完成。Spring Boot使得使用配置文件很是簡單。

2四、什麼是Spring Batch？
Spring Boot Batch提供可重用的函數，這些函數在處理大量記錄時很是重要，包括日誌/跟蹤，事務管理，做業處理統計信息，做業從新啓動，跳過和資源管理。它還提供了更先進的技術服務和功能，經過優化和分區技術，能夠實現極高批量和高性能批處理做業。簡單以及複雜的大批量批處理做業能夠高度可擴展的方式利用框架處理重要大量的信息。

2五、什麼是FreeMarker模板？
FreeMarker是一個基於Java的模板引擎，最初專一於使用MVC軟件架構進行動態網頁生成。使用Freemarker的主要優勢是表示層和業務層的徹底分離。程序員能夠處理應用程序代碼，而設計人員能夠處理html頁面設計。最後使用freemarker能夠將這些結合起來，給出最終的輸出頁面。

2六、什麼是JavaConfig？
Spring JavaConfig是Spring社區的產品，它提供了配置Spring IoC容器的純Java方法。所以它有助於避免使用XML配置。使用JavaConfig的優勢在於：
面向對象的配置。因爲配置被定義爲JavaConfig中的類，所以用戶能夠充分利用Java中的面向對象功能。一個配置類能夠繼承另外一個，重寫它的@Bean方法等。
減小或消除XML配置。基於依賴注入原則的外化配置的好處已被證實。可是，許多開發人員不但願在XML和Java之間來回切換。
JavaConfig爲開發人員提供了一種純Java方法來配置與XML配置概念類似的Spring容器。
從技術角度來說，只使用JavaConfig配置類來配置容器是可行的，但實際上不少人認爲將JavaConfig與XML混合匹配是理想的。
類型安全和重構友好。JavaConfig提供了一種類型安全的方法來配置Spring容器。因爲Java 5.0對泛型的支持，如今能夠按類型而不是按名稱檢索bean，不須要任何強制轉換或基於字符串的查找

2七、啓動類註解：
@SpringBootConfiguration:Spring Boot的配置類; 標註在某個類上，表示這是一個Spring Boot的配置類; @Configuration:配置類上來標註這個註解;配置類 ----- 配置文件;配置類也是容器中的一個組件;@Component
@EnableAutoConfiguration:開啓自動配置功能;
之前咱們須要配置的東西，Spring Boot幫咱們自動配置;@EnableAutoConfiguration告訴SpringBoot開啓自動配置功能;這樣自動配置才能生效;
Spring Boot在啓動的時候從類路徑下的META-INF/spring.factories中獲取EnableAutoConfiguration指定的值，將這些值做爲自動配置類導入到容器中，自動配置類就失效，幫咱們進行自動配置工做

2八、配置文件的加載順序
由jar包外向jar包內進行尋找;
優先加載帶profile
jar包外部的application-{profile}.properties或application.yml(帶spring.profile)配置文件
jar包內部的application-{profile}.properties或application.yml(帶spring.profile)配置文件
再來加載不帶profile
jar包外部的application.properties或application.yml(不帶spring.profile)配置文件
jar包內部的application.properties或application.yml(不帶spring.profile)配置文件

2九、自動配置原理
1)、SpringBoot啓動的時候加載主配置類，開啓了自動配置功能 @EnableAutoConfiguration
2)、@EnableAutoConfiguration 做用:
將類路徑下 META-INF/spring.factories 裏面配置的全部EnableAutoConfiguration的值加入到了容器中;
每個這樣的 xxxAutoConfiguration類都是容器中的一個組件，都加入到容器中;用他們來作自動配置;
3)、每個自動配置類進行自動配置功能;
根據當前不一樣的條件判斷，決定這個配置類是否生效；
4)、一但這個配置類生效;這個配置類就會給容器中添加各類組件;這些組件的屬性是從對應的properties類中獲取的，這些類裏面的每個屬性又是和配置文件綁定的;
5)、全部在配置文件中能配置的屬性都是在xxxxProperties類中封裝者‘;配置文件能配置什麼就能夠參照某個功能對應的這個屬性類

30、怎麼用好自動配置，精髓:
1)、SpringBoot啓動會加載大量的自動配置類
2)、咱們看咱們須要的功能有沒有SpringBoot默認寫好的自動配置類;
3)、咱們再來看這個自動配置類中到底配置了哪些組件;(只要咱們要用的組件有，咱們就不須要再來配置了)
4)、給容器中自動配置類添加組件的時候，會從properties類中獲取某些屬性。咱們就能夠在配置文件中指定這些屬性的值;

3一、日誌框架：
SpringBoot選用 SLF4j和logback;
如何讓系統中全部的日誌都統一到slf4j;
一、將系統中其餘日誌框架先排除出去;
二、用中間包來替換原有的日誌框架;
三、咱們導入slf4j其餘的實現
SpringBoot能自動適配全部的日誌，並且底層使用slf4j+logback的方式記錄日誌

3二、Spring Boot、Spring MVC 和 Spring 有什麼區別
Spring 是一個「引擎」，
Spring MVC是基於Spring的一個 MVC 框架，
Spring Boot是基於 Spring的一套快速開發整合包

3三、咱們如何監視全部 Spring Boot 微服務？
Spring Boot 提供監視器端點以監控各個微服務的度量。這些端點對於獲取有關應用程序的信息（如它們是否已啓動）以及它們的組件（如數據庫等）是否正常運行頗有幫助。可是，使用監視器的一個主要缺點或困難是，咱們必須單獨打開應用程序的知識點以瞭解其狀態或健康情況。想象一下涉及 50 個應用程序的微服務，管理員將不得不擊中全部 50 個應用程序的執行終端。

1. Dubbo 支持哪些協議，每種協議的應用場景，優缺點？

dubbo：單一長鏈接和 NIO 異步通信，適合大併發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議 TCP，異步， Hessian 序列化；
rmi：採用 JDK 標準的 rmi 協議實現，傳輸參數和返回參數對象須要實現Serializable 接口，使用 java 標準序列化機制，使用阻塞式短鏈接，傳輸數據包大小混合，消費者和提供者個數差很少，可傳文件，傳輸協議 TCP。多個短鏈接， TCP 協議傳輸，同步傳輸，適用常規的遠程服務調用和 rmi 互操做。在依賴低版本的 Common-Collections 包， java 序列化存在安全漏洞；
http：基於 Http 表單提交的遠程調用協議，使用 Spring 的 HttpInvoke 實現。多個短鏈接，傳輸協議 HTTP，傳入參數大小混合，提供者個數多於消費者，須要給應用程序和瀏覽器 JS 調用；
webservice：基於 WebService 的遠程調用協議，集成 CXF 實現，提供和原生 WebService 的互操做。多個短鏈接，基於 HTTP 傳輸，同步傳輸，適用系統集成和跨語言調用；
** hessian**：集成 Hessian 服務，基於 HTTP 通信，採用 Servlet 暴露服務，Dubbo 內嵌 Jetty 做爲服務器時默認實現，提供與 Hession 服務互操做。多個短鏈接，同步 HTTP 傳輸， Hessian 序列化，傳入參數較大，提供者大於消費者，提供者壓力較大，可傳文件；
redis：基於 redis 實現的 RPC 協議

2. Dubbo 超時時間怎樣設置？
Dubbo 超時時間設置有兩種方式：

服務提供者端設置超時時間，在 Dubbo 的用戶文檔中，推薦若是能在服務端多配置就儘可能多配置，由於服務提供者比消費者更清楚本身提供的服務特性。

服務消費者端設置超時時間，若是在消費者端設置了超時時間，以消費者端爲主，即優先級更高。由於服務調用方設置超時時間控制性更靈活。若是消費方超時，服務端線程不會定製，會產生警告。

3. Dubbo 有些哪些註冊中心？

Multicast 註冊中心： Multicast 註冊中心不須要任何中心節點，只要廣播地址，就能進行服務註冊和發現。基於網絡中組播傳輸實現；
Zookeeper 註冊中心：基於分佈式協調系統 Zookeeper 實現，採用Zookeeper 的 watch 機制實現數據變動；
redis 註冊中心：基於 redis 實現，採用 key/Map 存儲，住 key 存儲服務名和類型， Map 中 key 存儲服務 URL， value 服務過時時間。基於 redis 的發佈/訂閱模式通知數據變動；
Simple 註冊中心

4. Dubbo 集羣的負載均衡有哪些策略?
Dubbo 提供了常見的集羣策略實現，並預擴展點予以自行實現。

Random LoadBalance: 隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，調用次數越多，分佈越均勻；
RoundRobin LoadBalance: 輪循選取提供者策略，平均分佈，可是存在請求累積的問題；
LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收更少的請求；
ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數請求老是發到同一提供者，一臺機器宕機，能夠基於虛擬節點，分攤至其餘提供者，避免引發提供者的劇烈變更；

5. Dubbo 是什麼？
Dubbo 是一個分佈式、高性能、透明化的 RPC 服務框架，提供服務自動註冊、自動發現等高效服務治理方案，能夠和Spring 框架無縫集成

6. Dubbo 的主要應用場景？

透明化的遠程方法調用，就像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何 API 侵入。
軟負載均衡及容錯機制，可在內網替代 F5 等硬件負載均衡器，下降成本，減小單點。
服務自動註冊與發現，再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的 IP 地址，而且可以平滑添加或刪除服務提供者。

7. Dubbo 的核心功能？
主要就是以下 3 個核心功能：

Remoting：網絡通訊框架，提供對多種 NIO 框架抽象封裝，包括「同步轉異步」和「請求-響應」模式的信息交換方式。
Cluster：服務框架，提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。
Registry：服務註冊，基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

8. Dubbo 服務註冊與發現的流程？

watermark,size_14,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_20,type_ZmFuZ3poZW5naGVpdGk=

file

流程說明：

Provider(提供者)綁定指定端口並啓動服務
指供者鏈接註冊中心，併發本機 IP、端口、應用信息和提供服務信息發送至註冊中心存儲
Consumer(消費者），鏈接註冊中心，併發送應用信息、所求服務信息至註冊中心
註冊中心根據消費者所求服務信息匹配對應的提供者列表發送至Consumer 應用緩存。
Consumer 在發起遠程調用時基於緩存的消費者列表擇其一發起調用。
Provider 狀態變動會實時通知註冊中心、在由註冊中心實時推送至Consumer
設計的緣由：
Consumer 與 Provider 解偶，雙方均可以橫向增減節點數。
註冊中心對自己可作對等集羣，可動態增減節點，而且任意一臺宕掉後，將自動切換到另外一臺
去中心化，雙方不直接依懶註冊中心，即便註冊中心所有宕機短期內也不會影響服務的調用
服務提供者無狀態，任意一臺宕掉後，不影響使用

9. Dubbo 的架構設計

file

Dubbo 框架設計一共劃分了 10 個層：

服務接口層（ Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。
配置層（ Config）：對外配置接口，以 ServiceConfig 和ReferenceConfig 爲中心。
服務代理層（ Proxy）：服務接口透明代理，生成服務的客戶端 Stub和服務器端 Skeleton
服務註冊層（ Registry）：封裝服務地址的註冊與發現，以服務 URL爲中心。
集羣層（ Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以 Invoker 爲中心。
監控層（ Monitor）： RPC 調用次數和調用時間監控。
遠程調用層（ Protocol）：封將 RPC 調用，以 Invocation 和 Result爲中心，擴展接口爲 Protocol、 Invoker 和 Exporter。
信息交換層（ Exchange）：封裝請求響應模式，同步轉異步，以Request 和 Response 爲中心。
網絡傳輸層（ Transport）：抽象 mina 和 netty 爲統一接口，以Message 爲中心。

10. Dubbo 的服務調用流程？

file

11. Dubbo 的核心組件？

file

12. Dubbo 支持哪些協議，每種協議的應用場景，優缺點？

dubbo：單一長鏈接和 NIO 異步通信，適合大併發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議 TCP，異步， Hessian 序列化；
rmi：採用 JDK 標準的 rmi 協議實現，傳輸參數和返回參數對象須要實現 Serializable 接口，使用 java 標準序列化機制，使用阻塞式短鏈接，傳輸數據包大小混合，消費者和提供者個數差很少，可傳文件，傳輸協議 TCP。多個短鏈接， TCP 協議傳輸，同步傳輸，適用常規的遠程服務調用和rmi 互操做。在依賴低版本的 Common-Collections包， java 序列化存在安全漏洞；
webservice：基於 WebService 的遠程調用協議，集成 CXF 實現，提供和原生 WebService 的互操做。多個短鏈接，基於 HTTP 傳輸，同步傳輸，適用系統集成和跨語言調用；
http：基於 Http 表單提交的遠程調用協議，使用 Spring 的HttpInvoke 實現。多個短鏈接，傳輸協議 HTTP，傳入參數大小混合，提供者個數多於消費者，須要給應用程序和瀏覽器 JS 調用；
hessian：集成 Hessian 服務，基於 HTTP 通信，採用 Servlet 暴露服務， Dubbo 內嵌 Jetty 做爲服務器時默認實現，提供與 Hession 服務互操做。多個短鏈接，同步 HTTP 傳輸， Hessian 序列化，傳入參數較大，提供者大於消費者，提供者壓力較大，可傳文件；
memcache：基於 memcached 實現的 RPC 協議
redis：基於 redis 實現的 RPC 協議

13. dubbo 推薦用什麼協議？
默認使用 dubbo 協議

14. Dubbo 有些哪些註冊中心？

Multicast 註冊中心： Multicast 註冊中心不須要任何中心節點，只要廣播地址，就能進行服務註冊和發現。基於網絡中組播傳輸實現； Zookeeper 註冊中心：基於分佈式協調系統 Zookeeper 實現，採用Zookeeper 的 watch 機制實現數據變動；
redis 註冊中心：基於 redis 實現，採用 key/Map 存儲，住 key 存儲服務名和類型， Map 中 key 存儲服務 URL， value 服務過時時間。基於 redis 的發佈/訂閱模式通知數據變動；
Simple 註冊中心

15. Dubbo 默認採用註冊中心？
採用 Zookeeper

16. 爲何須要服務治理？

file

過多的服務 URL 配置困難
負載均衡分配節點壓力過大的狀況下也須要部署集羣 服務依賴混亂，啓動順序不清晰
過多服務致使性能指標分析難度較大，須要監控

17. Dubbo 的註冊中心集羣掛掉，發佈者和訂閱者之間還能通訊麼？
能夠的，啓動 dubbo 時，消費者會從 zookeeper 拉取註冊的生產者的地址接口等數據，緩存在本地。
每次調用時，按照本地存儲的地址進行調用。

18. Dubbo 與 Spring 的關係？
Dubbo 採用全 Spring 配置方式，透明化接入應用，對應用沒有任何API 侵入，只需用 Spring 加載 Dubbo 的配置便可， Dubbo 基於Spring 的 Schema 擴展進行加載。

19. Dubbo 使用的是什麼通訊框架?
默認使用 NIO Netty 框架

20. Dubbo 集羣提供了哪些負載均衡策略？

Random LoadBalance: 隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，調用次數越多，分佈越均勻；
RoundRobin LoadBalance: 輪循選取提供者策略，平均分佈，可是存在請求累積的問題； LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收更少的請求；
ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數請求老是發到同一提供者，一臺機器宕機，能夠基於虛擬節點，分攤至其餘提供者，避免引發提供者的劇烈變更；
缺省時爲 Random 隨機調用

21. Dubbo 的集羣容錯方案有哪些？

Failover Cluster
失敗自動切換，當出現失敗，重試其它服務器。一般用於讀操做，但重試會帶來更長延遲。
Failfast Cluster
快速失敗，只發起一次調用，失敗當即報錯。一般用於非冪等性的寫操做，好比新增記錄。
Failsafe Cluster
失敗安全，出現異常時，直接忽略。一般用於寫入審計日誌等操做。
Failback Cluster
失敗自動恢復，後臺記錄失敗請求，定時重發。一般用於消息通知操做。
Forking Cluster
並行調用多個服務器，只要一個成功即返回。一般用於實時性要求較高的讀操做，但須要浪費更多服務資源。可經過 forks="2" 來設置最大並行數。
Broadcast Cluster
廣播調用全部提供者，逐個調用，任意一臺報錯則報錯。一般用於通知全部提供者更新緩存或日誌等本地資源信息

22. Dubbo 的默認集羣容錯方案？
Failover Cluster

23. Dubbo 支持哪些序列化方式？
默認使用 Hessian 序列化，還有 Duddo、 FastJson、 Java 自帶序列化。

24. Dubbo 超時時間怎樣設置？
Dubbo 超時時間設置有兩種方式：

服務提供者端設置超時時間，在 Dubbo 的用戶文檔中，推薦若是能在服務端多配置就儘可能多配置，由於服務提供者比消費者更清楚本身提供的服務特性。
服務消費者端設置超時時間，若是在消費者端設置了超時時間，以消費者端爲主，即優先級更高。由於服務調用方設置超時時間控制性更靈活。若是消費方超時，服務端線程不會定製，會產生警告。

25. 服務調用超時問題怎麼解決？
dubbo 在調用服務不成功時，默認是會重試兩次的。

26. Dubbo 在安全機制方面是如何解決？
Dubbo 經過 Token 令牌防止用戶繞過註冊中心直連，而後在註冊中心上管理受權。 Dubbo 還提供服務黑白名單，來控制服務所容許的調用方。

27. Dubbo 和 Dubbox 之間的區別？
dubbox 基於 dubbo 上作了一些擴展，如加了服務可 restful 調用，更新了開源組件等。

28. Dubbo 和 Spring Cloud 的關係？
Dubbo 是 SOA 時代的產物，它的關注點主要在於服務的調用，流量分發、流量監控和熔斷。而 Spring Cloud 誕生於微服務架構時代，考慮的是微服務治理的方方面面，另外因爲依託了 Spirng、Spirng Boot 的優點之上，兩個框架在開始目標就不一致， Dubbo定位服務治理、 Spirng Cloud 是一個生態。

29. Dubbo 和 Spring Cloud 的區別？

file

最大的區別： Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基於TCP 協議傳輸的，配合以 Hession 序列化完成 RPC 通訊。而 SpringCloud 是基於 Http 協議+Rest 接口調用遠程過程的通訊，相對來講， Http 請求會有更大的報文，佔的帶寬也會更多。可是REST 相比 RPC 更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴。