一、 什麼是微服務架構
1、 一組小的服務
2、 獨立的進程
3、 輕量級通信
4、 基於業務能力
5、 獨立部署
6、 無集中式管理
二、 利與弊
利：
1、 強模塊化邊界
2、 可獨立部署
3、 技術多樣性
弊：
1、 分佈式複雜性
2、 最終一致性
3、 運維複雜性
4、 測試複雜性
三、康威法則和微服務——微服務的理論基礎就是康威法則
康威法則：設計系統的組織以及產生的架構等價於組織的組織架構。或者說：設計系統的組織以及產生的設計等價於組織的溝通結構。
https://www.jianshu.com/p/aca81cbf861b
原文：Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
翻譯：設計系統的組織，其產生的設計等同於組織之內、組織之間的溝通結構。
第一定律
Communication dictates design 組織溝通方式會通過系統設計表達出來
第二定律
There is never enough time to do something right, but there is always enough time to do it over.
時間再多一件事情也不可能做的完美，但總有時間做完一件事情
第三定律
There is a homomorphism from the linear graph of a system to the linear graph of its design organization
線型系統和線型組織架構間有潛在的異質同態特性
第四定律
The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems
大的系統組織總是比小系統更傾向於分解
說白了，康威法則的真正含義就在於，在項目達到一定規模後，團隊規模和單個項目複雜度之間產生矛盾，生產力低下。多個團隊維護同一個項目，在集成時往往需要各個團隊的相互配合，而如果將一個項目拆分成多個小項目後，每個團隊只負責該一個小項目，就能避免許多不必要的麻煩。——所以說架構師不僅僅是要關心技術架構還要關心組織架構（人員）。
四、企業應該在什麼時候開始考慮引入微服務？
一般的，團隊規模達到百人時，就必須要引入微服務了。
在初始階段要單塊應用優先，隨着功能的複雜性變大，一塊一塊的將不斷變複雜的模塊拆分出來成爲微服務。
五、什麼樣的組織架構更適合微服務
跨職能微服務產品團隊：團隊內部能夠形成閉環，更快的響應需求，產品迭代。
Neflix前總監：微服務架構本質上是組織架構的重組。
六、如何理解阿里巴巴提出的微服務中臺戰略？
阿里巴巴提出的理念：大中臺，輕(小)前臺。這就是中臺戰略，說直白點就是：讓前段的業務更小更靈活，根據市場的變化用戶的需求快速的、不斷的演化出新的應用，當下面的中臺（包括業務中臺和技術中臺）做的非常完善時，對上層應用的支撐能力就越強，目標就是賦能業務的創新，快速響應市場的需求。
Paas層就是微服務的基礎設施層。
七、如何給出一個清晰簡潔的服務分層方式
BFF其實是Backend for Frontend的簡稱，中文翻譯是爲前端而開發的後端，它主要由前端團隊開發（後端微服務一般由後端團隊開發）。BFF可以認爲是一種適配服務，將後端的微服務進行適配（主要包括聚合裁剪和格式適配等邏輯），向無線端設備暴露友好和統一的API，方便無線設備接入訪問後端服務。https://www.sohu.com/a/236506677_673711
八、微服務總體技術架構體系是怎樣設計的
九、微服務最經典的三種服務發現機制
1、傳統基於LB的模式
單獨的LB（F5、Nginx），配置域名執行後臺多個服務，這個LB往往存在單點問題；另外消費者調用提供者時會有性能損耗。
2、進程內LB模式
3、主機獨立LB模式
十、微服務 API 服務網關
1、 原理
網關前需要增加一層負載均衡器，因爲負載均衡的存在，網關就成爲無狀態的。無狀態的好處就在於網關可以部署很多，無單點問題，增強系統的穩定性和可用性。
網關的主要功能：反向路由、認證安全、限流熔斷、日誌監控。
2、開源網關 Zuul
Zuul的總體流程架構：
Zuul網關的核心就是一個Servlet。
ZuulFilter Runner：管理了所有的過濾器，這些過濾器分爲三個層次——前置路由過濾器(Pre routing filters)、路由過濾器(routing filters)、後置路由過濾器(Post routing filters)
前置路由過濾器：日誌處理、轉發後臺請求等；
路由過濾器：找到後臺服務調用請求等；
後置路由過濾器：日誌處理、統計、審計等
Neflix在設計網關時，考慮到網關的流量大、重要性高，不能經常更新，但又要滿足經常變動的需求，所以實現了動態插拔的過濾器功能，過濾器是Groovy腳本過濾器。並實現了靈活的上傳加載機制：
Filter publishFilter Persistence(DB)—>後臺有個Filter puller(定期pullDB，將新的filter上傳到Filter目錄中)—>Filter Directory——>Filter Manager定期掃描這個目錄——>Filter Loader將掃描到新的Filter加載到Filter Runner中生效
如果要在各個Filter之間共享一些信息，那麼可以通過Request Context組件。
網關總體的流程和調用鏈如下圖：
十一、 Netflix微服務路由發現體系
服務註冊中心：Netflix開源組件Eureka（開源的還有Consul等）
網關：Netflix開源組件Zuul
這兩大組件，支撐了整個Netflix的服務路由發現體系；基礎服務層也即中間層服務；聚合服務層也叫邊界服務層。
十二、集中式配置中心的作用和原理是什麼？
爲了使得配置標準化、格式統一化，縮短上線週期，快速響應變化，通過審計功能可以追溯問題，所以提出了集中式配置中心。
數據庫連接字符串、緩存連接字符串、消息隊列的連接字符串、動態調整的參數（客戶端的超時、限流的閾值）、業務的開關配置等。
實時更新，方式有兩種：push和pull。pull保證能夠拿到最新配置，push則不一定，因爲如果因爲網絡原因，push沒成功，則可能丟失最新配置。
常用的產品：百度分佈式配置管理平臺-Disconf；Spring cloud config；攜程的Apollo配置中心等等。
特色：在客戶端本地有緩存，實現高可用。
https://github.com/ctripcorp/apollo
十三、微服務通訊方式 RPC vs REST
十四、微服務框架需要考慮哪些治理環節？
1、 配置集成
2、 後天服務集成DB、MQ、Cache
3、 服務註冊發現
4、 軟負載路由——用以支持灰度發佈、藍綠髮布等
5、 日誌
6、 Metrics——對服務的調用量、延遲、出錯量等監控。
7、 調用鏈監控
8、 限流熔斷
9、 安全&訪問控制 —— 黑名單、權限限制等
10、REST/RPC —— 框架最好支持這兩種
11、序列化 XML/JSON/二進制 —— 最好都支持
12、代碼生成 —— 大規模開發時，推崇一種契約驅動的開發方式：定義好契約後利用代碼生成的方式自動生成客戶端和服務端代碼。
13、統一異常處理 —— 異常標準化
14、文檔
微服務框架就是要把上面的這些功能沉澱下來，變成平臺的一部分，開發人員只專注於業務的實現。
可以參考阿里巴巴的Dubbo是如何融合這些功能的。
十五、微服務監控系統分層和監控架構
十六、微服務的調用鏈監控該如何選型？
十七、微服務的容錯限流是如何工作的？
引用：
http://www.uml.org.cn/wfw/201906063.asp?artid=22057
通過hystrix可以解決雪崩效應問題，它提供了資源隔離、降級機制、融斷、緩存等功能。
- 資源隔離：包括線程池隔離和信號量隔離，限制調用分佈式服務的資源使用，某一個調用的服務出現問題不會影響其他服務調用。
- 降級機制：超時降級、資源不足時(線程或信號量)降級，降級後可以配合降級接口返回託底數據。
- 融斷：當失敗率達到閥值自動觸發降級(如因網絡故障/超時造成的失敗率高)，熔斷器觸發的快速失敗會進行快速恢復。
- 緩存：返回結果緩存，後續請求可以直接走緩存。
- 請求合併：可以實現將一段時間內的請求（一般是對同一個接口的請求）合併，然後只對服務提供者發送一次請求。
十八、Docker 容器部署技術 & 持續交付流水線
十九、容器集羣調度和基於容器的發佈體系
