面試專題（分佈式系統微服務）

架構設計相關

0. 什麼是分佈式系統，什麼是微服務？

集羣：多機器作同一件事情；
分佈式系統： 一件事情，多系統協同完成；
微服務架構：構建分佈式系統的一種架構方式， 核心思路是：去中心化；
http://www.cnblogs.com/liuning8023/p/4493156.html
 

1. RPC和RPC框架

RPC是指遠程過程調用，實現遠程過程調用的方式有不少中，Dubbo，Rmi，Hessian等等；
RPC的核心過程包括了客戶端和服務端的通信協議，尋址，數據序列化/反序列化；
對上述過程進行了封裝，不須要開發人員本身去定義通信協議，去實現序列化的細節工做，
這樣的組件稱爲RPC框架；常見RPC框架有 thrift，gRpc，dubbo，motan

2. 序列化方式及做用

序列化：將java對象或者其餘內存中的數據，轉換爲一種特定格式的流，使之能夠在網絡中傳輸或者磁盤上存儲；
反序列化：將流以特定的格式轉爲java對象或者內存中其餘形式的數據；# json，jdk serializable, Hessian，Dubbo, Protobuf,
做用：壓縮；持久化存儲；跨網絡傳輸；

3. 分佈式系統中事務的處理

參考：https://wenku.baidu.com/view/be946bec0975f46527d3e104.html
          https://segmentfault.com/a/1190000004468442
事務相關必瞭解的概念：
ACID （Atomic原子性，Consistency一致性，Isolation隔離性，Durability持久性）
CAP （一致性Consistency，可用性Availability，分區容錯性Partitiontolerance），分佈式系統來講，P是不能放棄的
BASE （Basically Available（基本可用），Soft state（軟狀態），Eventuallyconsistent（最終一致性））
分佈式事務實現方式：
1.  XA （數據庫廠商實現）；2. 後臺任務按期校對數據；3. 經過消息隊列，實現最終一致(確保消息到達MQ，冪等性)；4. TCC機制(Try,Confirm,Cancel)
https://www.cnblogs.com/rainwang/p/7099648.html

 

4. 系統監控

# 鏈路監控
Spring‐Cloud‐Sleuth + Zipkin
Sleuth收集微服務之間的接口調用信息以及內部方法調用。經過採樣以後，將數據傳輸致
Zipkin，由Zipkin負責存儲和可視化查詢；
# 核心概念：Trace，Span。公開課有講過Sleuth；
# 日誌監控
ELK
1）ElasticSearch搜索服務器，提供了一個分佈式多用戶能力的全文搜索引擎，基於
RESTful web接口。
2）Logstash是能夠對日誌進行收集、過濾、分析，並將其存儲供之後使用;
3）Kibana 是Elasticsearch前端展現工具,能夠爲 Logstash 和 ElasticSearch 提供
的日誌分析友好的 Web 界面，能夠幫助您彙總、分析和搜索重要數據日誌
搭建方式參考資料: https://www.cnblogs.com/kevingrace/p/5919021.html
# 代碼性能監控
Metrics：度量；咱們須要爲某個系統某個服務作監控、作統計，就須要用到Metrics；
代碼執行的吞吐量，響應時間，併發量，瞬時狀態值。
# 這個須要經過代碼埋點實現，公開課有講過Metrics+Grafana構建性能監控平臺；

5. 高可用

服務的高可用能夠經過多實例，自檢測，自恢復，快速擴容機制來實現；
多實例：一個服務部署多個實例，經過負載均衡機制下降單實例的負載以及實現容錯；
自檢測：系統預留健康檢查接口，經過docker集羣模式的健康檢查機制來實現自動重啓和預警；
自恢復：對於網絡抖動的問題，須要程序有必定的容錯性，好比：熔斷機制，Eureka的自我保護措施；
快速擴容：互聯網應用的特殊性，在特定時候會出現高峯期的海量請求，此時，須要咱們的分佈式系統可以快速擴容。docker的服務編排就能夠實現已有硬件資源的狀況下秒級擴容；對於硬件資源，須要結合雲計算技術來實現；

6. 服務調用的負載均衡

# 服務端負載均衡：對客戶端屏蔽具體的接口地址，對外僅暴露負載均衡器，全部請求通過統一的負載服務；有硬件負載(f5,radware)和軟件負載(nginx,apache,lvs)
優點：統一管理，控制；對外部調用友好，屏蔽了微服務地址多變的複雜性；
劣勢：性能要求高，流量大對負載服務自己有很高的要求；管理複雜，大多數服務端負載器
須要手工配置服務實例信息；
# 客戶端負載均衡：由客戶端本身選擇目標服務器，直調對應的地址；dubbo(源碼參考com.alibaba.dubbo.rpc.cluster.LoadBalance)，springcloud(ribbon)都是客戶端負載均衡；
優點：性能好，能夠根據具體應用微調負載策略；易管理，服務實例信息自發現
劣勢：服務實例信息在多客戶端之間的不一樣步；一般是集羣內部使用；

7. 分佈式配置中心

相似產品有不少：360 Qconf，百度 Disconf，淘寶 Diamond
參考：https://www.cnblogs.com/zhangxh20/p/5464103.html
咱們着重講了springcloudconfig 分佈式配置中心，用來解決多配置的問題；
將配置文件統一存儲在gitlab，svn，filesystem，並支持敏感信息的加密存儲(configserver或者client都可解密)

8. 服務註冊與發現機制

這種機制目的是實現：服務提供者的自注冊，服務消費者的主動發現服務提供者；
服務註冊：服務提供者啓動實例時，將信息存儲到註冊中心；
註冊中心：保存服務提供者或者消費者的實例信息(服務名稱，IP,端口，方法地址等等)
服務發現：服務消費者，經過服務名在註冊中心的信息中查詢出具體的服務提供者實例信息。

9. 分佈式系統如何拆分？

業務線(訂單系統，積分系統，審計系統，支付系統，結算系統，推廣系統….)
技術棧（php，java，nodejs，go）

架構分層 (前臺，中臺，後臺； 存儲服務，緩存服務，MQ服務，搜索引擎服務….)

 

SpringCloud

1. 微服務是如何保護本身的

http://blueskykong.com/2017/10/19/security1/

信息加密

經過Https實現信息傳輸的加密(nginx，tomcat均可以配置https)；
對代碼侵入性很小。由於微服務集羣不直接對外提供服務，由統一的網關來提供業務API(zuul，nginx均可以的)。

權限校驗方案

· 單點登陸

# 每一個應用都必須接入單點登陸，大型系統中，須要集成單點登陸帶來的複雜工做和性能損耗；

· 分佈式session方案

流程： 客戶端 ‐> 獲取session ‐> 請求微服務 ‐> 查詢共享存儲中受權信息 ‐> 校驗權限 ‐> 提供服務 ‐> 給予響應
分佈式session保存方案，根據session去查找共享存儲中對應的權限信息來實現權限校驗；
# 共享存儲的高可用和安全性是個問題，相似直接redis，memcache來作；

· token方案

1. 客戶端 ‐> uaa認證 ‐> 獲取token
2. 客戶端 ‐> 微服務 ‐> 校驗token

token包含必要的受權信息，一次獲取，屢次使用，相對獨立，實現簡單，不須要cookie；長度有限，不能撤銷，須要設置過時時間；
# 能夠在網關層作；也能夠構建成通用的組件，放在每一個微服務上面去作；
# 根據不一樣的業務場景：token能夠發放一次，也能夠在每次請求的時候去申請，這樣可以實現分控須要的帳戶禁用，黑名單等功能

 

2. 微服務網關

zuul是springcloud提供的成熟的路由方案；根據請求的路徑不一樣，網關會定位到指定的微服務，並代理請求到不一樣的微服務接口；對外屏蔽了微服務接口調用的複雜性。
三個重要概念：動態路由表，路由定位，反向代理
反向代理：客戶端請求到網關，網關受理後，再對目標服務發起請求，拿到響應以後，再響應給客戶端；
動態路由表：zuul支持eureka路由，手動配置的路由，這兩種都支持動態更新；
路由定位：根據請求路徑，zuul有一套自身的服務定位規則以及路由匹配的表達式；
# 應用場景： 對外暴露，權限校驗，服務聚合，日誌審計

 

3. 各服務之間如何調用

服務對外以http接口形式暴露，因此調用有多種方式；
Fegin是cloud提供的一種服務調用客戶端；
Resttemplate也能夠快速的發起服務調用；
同時，也能夠手動獲取對應接口的具體地址，經過日常的httpclient進行調用；
# Feign和Resttemplate 均可以集成負載均衡，失敗重試，熔斷的功能；

 

4.如何保證服務健康的狀況
1. Spring Boot‐Actuator 能夠用來監控咱們的項目，能夠經過HealthEndPoint/health來查看應用的健康情況；
SpringBoot在集成不少組件時，都會實現一個健康檢查的接口，如ElasticsearchHealthIndicator，RedisHealthIndicator，RabbitHealthIndicator等。
2. 在微服務集羣中，咱們一般還會經過sleuth來進行服務調用的鏈路追蹤，能夠經過抽樣看到服務調用的異常狀況；
3. 日誌信息也是咱們監控服務監控狀況的一個重要手段，經常使用經過ELK實現日誌收集，分析和查看；
4. 在經過docker部署微服務時，咱們能夠利用docker的健康檢查機制，實現服務的自動重啓；

 

5. 容錯機制

# Ribbon 負載均衡&重試
經過服務名獲取實例信息，根據負載策略選擇合適的實例去訪問；
服務調用失敗時，能夠配置重試次數，以及實例切換的次數；
# Hystrix熔斷機制
限流，降級，熔斷；
限流：限制接口訪問併發量，限制緩衝區大小，超出限制，調用Fallback方法
熔斷：出錯率超過閾值，必定時間內再也不請求該接口。(超時、run方法拋出異常)
降級：凡是沒有正常的從接口中拿到數據，就會調用Fallback方法，獲取一個結果
# 經過命令模式的封裝，SpringCloud內部自動集成，且可做用於任意JAVA方法上，不關心方法的具體實現。表明着(http、redis、db操做均可以作熔斷)；

 

6. SpringCloud中的服務註冊與發現機制

兩個角色eurekaServer， eurekaClient
server提供httpapi服務，存儲服務實例的信息，而且具有主動剔除服務(心跳檢測)和server高可用的功能；
client集成在具體的微服務中，在服務啓動時，將服務實例信息post到server上；client也會定時同步server上面其餘service信息；
# eureka的工做大可能是後臺thread在定時工做，任務執行的間隔時間均可以經過配置文件進行配置；

 

7. SpringCloud的實施推廣

# 集成SpringMVC項目
微服務改造的過渡期，在傳統的SpringMvc項目中，引入部分SpringCloud的特性，便可經過微改造變成微服務；
# 其餘語言的項目加入SpringCloud微服務系統
Eureka提供HttpApi，使得非java語言加入到SpringCloud微服務集羣成爲可能；

 

Dubbo

http://dubbo.io/books/dubbo­user­book/ 
http://dubbo.io/books/dubbo­dev­book 
http://dubbo.io/books/dubbo­admin­book/

1. 若是註冊中心集羣都掛掉，發佈者和訂閱者之間還能通訊麼？

# 有緩存；
註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信
新的服務將沒法發現；服務下架後仍舊有被調用的可能；

2. dubbo鏈接註冊中心和直連的區別

註冊中心： 消費者動態發現服務提供者，實現軟負載均衡和集羣容錯;
直連：不能動態增減提供者；開發、測試環境可經過指定Url方式繞過註冊中心直連指定的服務地址，快速測試

3. dubbo服務的容錯機制

# http://dubbo.io/books/dubbo‐user‐book/demos/fault‐tolerent‐strategy.html
Failover Cluster：失敗自動切換，當出現失敗，重試其它服務器，默認兩次；
Failfast Cluster：失敗當即報錯
Failsafe Cluster：失敗安全，出現異常時，直接忽略
Failback Cluster：失敗自動恢復，後臺記錄失敗請求，定時重發
Forking Cluster：並行調用多個服務器，只要一個成功即返回。一般用於實時性要求較
高的讀操做，但須要浪費更多服務資源
Broadcast Cluster:播調用全部提供者，逐個調用，任意一臺報錯則報錯
# 要注意分佈式事務

4. 具體問題示例1：關於服務調用超時
# 超時是針對消費端仍是服務端？
dubbo的超時是爭對客戶端的，因爲是一種NIO模式，消費端發起請求後獲得一個ResponseFuture，而後消費端一直輪詢這個ResponseFuture直至超時或者收到服務端的返回結果
# 超時在哪設置，優先級是什麼？
http://dubbo.io/books/dubbo‐user‐book/configuration/xml.html
# 實現原理
消費端發起遠程請求後，線程不會阻塞等待服務端的返回，而是立刻獲得一個ResponseFuture（ReponseFuture的實現類：DefaultFuture），消費端經過不斷的輪詢機制判斷結果是否有返回。由於是經過輪詢，輪詢有個須要特別注要的就是避免死循環，因此爲了解決這個問題就引入了超時機制，只在必定時間範圍內作輪詢，若是超時時間就返回超時異常

5. 服務提供者能實現失效踢出是什麼原理

源碼參考  RegistryService， 文檔參考http://dubbo.io/books/dubbo‐user‐book/references/registry/introduction.html
# redis ‐ 髒數據由監控中心刪除
# zookeeper ‐ 的臨時節點

6. dubbo通信協議

# 什麼是通信協議
客戶端服務端之間進行數據流轉的一種約定，將數據按照標準格式來組裝；
# 協議內容
頭部信息（調用控制協議16B) + body(序列化)
head = 魔數(2） + 標識（1） + 響應狀態(1) + 消息ID（8） + 內容長度(4)
body = dubbo版本 + 服務接口路徑 + 服務版本號 + 服務方法名 + 參數描述符 + 參數值序列化 + 隱式參數

7. 大機率的問題

# dubbo文檔，仔細閱讀一遍，面試官可能隨便抽取一個。
# dubbo配置的方式和屬性
http://dubbo.io/books/dubbo‐user‐book/configuration/
# dubbo底層協議
http://dubbo.io/books/dubbo‐user‐book/references/protocol/introduction.html
# dubbo服務註冊與發現流程 http://dubbo.io/books/dubbo‐user‐book/references/registry/introduction.html