前言
微服務(wù)對于JAVA程序員來說大家一定不陌生晶姊，面試大廠必定會問的問題同時也是目前比較流行的技術(shù)扒接，不管你學(xué)沒學(xué)都得知道點其中技術(shù)點，下面我花費一星期整理了微服務(wù)資料有需要的可以在文末領(lǐng)取文檔資料们衙，希望給正在學(xué)習(xí)的你有所幫助钾怔，廢話不多說！
上干貨蒙挑！
1.說說前后端分離是如何做的
在前后端分離架構(gòu)中宗侦，后端只需要負(fù)責(zé)按照約定的數(shù)據(jù)格式向前端提供可調(diào)用的 API 服務(wù)即可。前后端之間通過 HTTP 請求進(jìn)行交互忆蚀，前端獲取到數(shù)據(jù)后矾利，進(jìn)行頁面的組裝和渲染姑裂，最終返回給瀏覽器
2.如何解決跨域
跨域，指的是瀏覽器不能執(zhí)行其他網(wǎng)站的腳本男旗。它是由瀏覽器的同源策略造成的舶斧，是瀏覽器對JavaScript 施加的安全限制
什么是同源？
所謂同源是指察皇，域名茴厉，協(xié)議，端口均相同
http://www.baidu.com --> http://admin.baidu.com 跨域
http://www.baidu.com --> http://www.baidu.com 非跨域
http://www.baidu.com --> http://www.baidu.com:8080 跨域
http://www.baidu.com --> https://www.baidu.com 跨域
使用 CORS（跨資源共享）解決跨域問題
CORS 是一個 W3C 標(biāo)準(zhǔn)什荣，全稱是"跨域資源共享"（Cross-origin resource sharing）矾缓。它允許瀏覽器向跨源服務(wù)器，發(fā)出 XMLHttpRequest 請求稻爬，從而克服了 AJAX 只能同源使用的限制嗜闻。
CORS 需要瀏覽器和服務(wù)器同時支持。目前桅锄，所有瀏覽器都支持該功能泞辐，IE 瀏覽器不能低于 IE10
整個 CORS 通信過程，都是瀏覽器自動完成竞滓，不需要用戶參與咐吼。對于開發(fā)者來說，CORS 通信與同源的 AJAX 通信沒有差別商佑，代碼完全一樣锯茄。瀏覽器一旦發(fā)現(xiàn) AJAX 請求跨源，就會自動添加一些附加的頭信息茶没，有時還會多出一次附加的請求肌幽，但用戶不會有感覺
因此，實現(xiàn) CORS 通信的關(guān)鍵是服務(wù)器抓半。只要服務(wù)器實現(xiàn)了 CORS 接口喂急，就可以跨源通信
CORS 與 JSONP 的比較
CORS 與 JSONP 的使用目的相同，但是比 JSONP 更強大笛求。
JSONP 只支持 GET 請求廊移，CORS 支持所有類型的 HTTP 請求。JSONP 的優(yōu)勢在于支持老式瀏覽器探入，以及可以向不支持 CORS 的網(wǎng)站請求數(shù)據(jù)
3.微服務(wù)哪些框架
Dubbo
是阿里巴巴服務(wù)化治理的核心框架狡孔，并被廣泛應(yīng)用于阿里巴巴集團(tuán)的各成員站點。阿里巴巴近幾年對開源社區(qū)的貢獻(xiàn)不論在國內(nèi)還是國外都是引人注目的蜂嗽，比如：JStorm 捐贈給 Apache 并加入 Apache 基金會等苗膝，為中國互聯(lián)網(wǎng)人爭足了面子，使得阿里巴巴在國人眼里已經(jīng)從電商升級為一家科技公司了
Spring Cloud
從命名我們就可以知道植旧，它是 Spring Source 的產(chǎn)物辱揭，Spring 社區(qū)的強大背書可以說是 Java 企業(yè)界最有影響力的組織了离唐，除了 Spring Source 之外，還有 Pivotal 和 Netflix 是其強大的后盾與技術(shù)輸出问窃。其中 Netflix 開源的整套微服務(wù)架構(gòu)套件是 Spring Cloud 的核心
4.你怎么理解 RPC 框架
首先我們要知道什么是 RPC
RPC 是指遠(yuǎn)程過程調(diào)用亥鬓，也就是說兩臺服務(wù)器 A，B 一個應(yīng)用部署在 A 服務(wù)器上泡躯，想要調(diào)用B 服務(wù)器上應(yīng)用提供的函數(shù)或方法贮竟，由于不在一個內(nèi)存空間丽焊，不能直接調(diào)用较剃，需要通過網(wǎng)絡(luò)來表達(dá)調(diào)用的語義和傳達(dá)調(diào)用的數(shù)據(jù)
RPC 是如何通訊的
要解決通訊的問題，主要是通過在客戶端和服務(wù)器之間建立 TCP 連接技健，遠(yuǎn)程過程調(diào)用的所有交換的數(shù)據(jù)都在這個連接里傳輸写穴。連接可以是按需連接，調(diào)用結(jié)束后就斷掉雌贱，也可以是長連接啊送，多個遠(yuǎn)程過程調(diào)用共享同一個連接
要解決尋址的問題，也就是說欣孤，A 服務(wù)器上的應(yīng)用怎么告訴底層的 RPC 框架馋没，如何連接到B 服務(wù)器（如主機或 IP 地址）以及特定的端口，方法的名稱是什么降传，這樣才能完成調(diào)用。比如基于 Web 服務(wù)協(xié)議棧的 RPC，就要提供一個 endpoint URI郊艘，或者是從 UDDI 服務(wù)上查找谐鼎。如果是 RMI 調(diào)用的話，還需要一個 RMI Registry 來注冊服務(wù)的地址
當(dāng) A 服務(wù)器上的應(yīng)用發(fā)起遠(yuǎn)程過程調(diào)用時段只，方法的參數(shù)需要通過底層的網(wǎng)絡(luò)協(xié)議如 TCP 傳遞到 B 服務(wù)器腮猖，由于網(wǎng)絡(luò)協(xié)議是基于二進(jìn)制的，內(nèi)存中的參數(shù)的值要序列化成二進(jìn)制的形式赞枕，也就是序列化（Serialize）或編組（marshal）澈缺，通過尋址和傳輸將序列化的二進(jìn)制發(fā)送給 B 服務(wù)器
B 服務(wù)器收到請求后，需要對參數(shù)進(jìn)行反序列化（序列化的逆操作）炕婶，恢復(fù)為內(nèi)存中的表達(dá)方式谍椅，然后找到對應(yīng)的方法（尋址的一部分）進(jìn)行本地調(diào)用，然后得到返回值
返回值還要發(fā)送回服務(wù)器 A 上的應(yīng)用古话，也要經(jīng)過序列化的方式發(fā)送雏吭，服務(wù)器 A 接到后，再反序列化陪踩，恢復(fù)為內(nèi)存中的表達(dá)方式杖们，交給 A 服務(wù)器上的應(yīng)用
為什么要用 RPC
就是無法在一個進(jìn)程內(nèi)悉抵，甚至一個計算機內(nèi)通過本地調(diào)用的方式完成的需求，比如比如不同的系統(tǒng)間的通訊摘完，甚至不同的組織間的通訊姥饰。由于計算能力需要橫向擴(kuò)展，需要在多臺機器組成的集群上部署應(yīng)用
5.說說 RPC 的實現(xiàn)原理
首先需要有處理網(wǎng)絡(luò)連接通訊的模塊孝治，負(fù)責(zé)連接建立列粪、管理和消息的傳輸。其次需要有編解碼的模塊谈飒，因為網(wǎng)絡(luò)通訊都是傳輸?shù)淖止?jié)碼岂座，需要將我們使用的對象序列化和反序列化。剩下的就是客戶端和服務(wù)器端的部分杭措，服務(wù)器端暴露要開放的服務(wù)接口费什，客戶調(diào)用服務(wù)接口的一個代理實現(xiàn)，這個代理實現(xiàn)負(fù)責(zé)收集數(shù)據(jù)手素、編碼并傳輸給服務(wù)器然后等待結(jié)果返回
6.說說 Dubbo 的實現(xiàn)原理
Dubbo 作為 RPC 框架鸳址，實現(xiàn)的效果就是調(diào)用遠(yuǎn)程的方法就像在本地調(diào)用一樣。如何做到呢泉懦？
本地有對遠(yuǎn)程方法的描述稿黍，包括方法名、參數(shù)崩哩、返回值巡球，在 Dubbo 中是遠(yuǎn)程和本地使用同樣的接口
要有對網(wǎng)絡(luò)通信的封裝，要對調(diào)用方來說通信細(xì)節(jié)是完全不可見的琢锋，網(wǎng)絡(luò)通信要做的就是將調(diào)用方法的屬性通過一定的協(xié)議（簡單來說就是消息格式）傳遞到服務(wù)端
服務(wù)端按照協(xié)議解析出調(diào)用的信息辕漂；執(zhí)行相應(yīng)的方法；在將方法的返回值通過協(xié)議傳遞給客戶端吴超；客戶端再解析钉嘹；在調(diào)用方式上又可以分為同步調(diào)用和異步調(diào)用
7.你怎么理解 RESTful
2000 年，Roy Thomas Fielding 博士在他那篇著名的博士論文《Architectural Styles and the Design of Network-based Software Architectures》中提出了幾種軟件應(yīng)用的架構(gòu)風(fēng)格鲸阻，REST 作為其中的一種架構(gòu)風(fēng)格在這篇論文的第 5 章中進(jìn)行了概括性的介紹跋涣。
REST 是“REpresentational State Transfer”的縮寫，可以翻譯成“表現(xiàn)狀態(tài)轉(zhuǎn)換”鸟悴，但是在絕大多數(shù)場合中我們只說 REST 或者 RESTful陈辱。Fielding 在論文中將 REST 定位為“分布式超媒體應(yīng)用（Distributed Hypermedia System）”的架構(gòu)風(fēng)格，它在文中提到一個名為“HATEOAS（Hypermedia as the engine of application state）”的概念细诸。
我們利用一個面向最終用戶的 Web 應(yīng)用來對這個概念進(jìn)行簡單闡述：這里所謂的應(yīng)用狀態(tài)（Application State）表示 Web 應(yīng)用的客戶端的狀態(tài)沛贪，簡單起見可以理解為會話狀態(tài)。資源在瀏覽器中以超媒體的形式呈現(xiàn)，通過點擊超媒體中的鏈接可以獲取其它相關(guān)的資源或者對當(dāng)前資源進(jìn)行相應(yīng)的處理利赋，獲取的資源或者針對資源處理的響應(yīng)同樣以超媒體的形式再次呈現(xiàn)在瀏覽器上水评。由此可見，超媒體成為了驅(qū)動客戶端會話狀態(tài)的轉(zhuǎn)換的引擎媚送。
借助于超媒體這種特殊的資源呈現(xiàn)方式中燥，應(yīng)用狀態(tài)的轉(zhuǎn)換體現(xiàn)為瀏覽器中呈現(xiàn)資源的轉(zhuǎn)換。
如果將超媒體進(jìn)一步抽象成一般意義上的資源呈現(xiàn)（Representation ）方式塘偎，那么應(yīng)用狀態(tài)變成了可被呈現(xiàn)的狀態(tài)（REpresentational State）疗涉。應(yīng)用狀態(tài)之間的轉(zhuǎn)換就成了可被呈現(xiàn)的狀態(tài)裝換（REpresentational State Transfer），這就是 REST
REST 是一種很籠統(tǒng)的概念吟秩，它代表一種架構(gòu)風(fēng)格
8.說說 CAP 定理咱扣、 BASE 理論
CAP 定理
2000 年 7 月，加州大學(xué)伯克利分校的 Eric Brewer 教授在 ACM PODC 會議上提出 CAP 猜想峰尝。2 年后偏窝，麻省理工學(xué)院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了 CAP收恢。之后武学，CAP理論正式成為分布式計算領(lǐng)域的公認(rèn)定理。
CAP 理論為：一個分布式系統(tǒng)最多只能同時滿足一致性（Consistency）伦意、可用性（Availability）和分區(qū)容錯性（Partition tolerance）這三項中的兩項
一致性（Consistency）
一致性指 “all nodes see the same data at the same time”火窒，即更新操作成功并返回客戶端完成后，所有節(jié)點在同一時間的數(shù)據(jù)完全一致
可用性（Availability）
可用性指“Reads and writes always succeed”驮肉，即服務(wù)一直可用熏矿，而且是正常響應(yīng)時間
分區(qū)容錯性（Partition tolerance）
分區(qū)容錯性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系統(tǒng)在遇到某節(jié)點或網(wǎng)絡(luò)分區(qū)故障的時候离钝，仍然能夠?qū)ν馓峁M
足一致性和可用性的服務(wù)
BASE 理論
eBay 的架構(gòu)師 Dan Pritchett 源于對大規(guī)模分布式系統(tǒng)的實踐總結(jié)票编，在 ACM 上發(fā)表文章提
BASE 理論，BASE 理論是對 CAP 理論的延伸卵渴，核心思想是即使無法做到強一致性（Strong Consistency慧域，CAP 的一致性就是強一致性），但應(yīng)用可以采用適合的方式達(dá)到最終一致性（Eventual Consitency）
基本可用（Basically Available）
基本可用是指分布式系統(tǒng)在出現(xiàn)故障的時候浪读，允許損失部分可用性昔榴，即保證核心可用。
電商大促時碘橘，為了應(yīng)對訪問量激增互订，部分用戶可能會被引導(dǎo)到降級頁面，服務(wù)層也可能只提供降級服務(wù)痘拆。這就是損失部分可用性的體現(xiàn)
軟狀態(tài)（Soft State）
軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)仰禽，而該中間狀態(tài)不會影響系統(tǒng)整體可用性。分布式存儲中一般一份數(shù)據(jù)至少會有三個副本，允許不同節(jié)點間副本同步的延時就是軟狀態(tài)的體現(xiàn)吐葵。mysql replication 的異步復(fù)制也是一種體現(xiàn)
最終一致性（Eventual Consistency）
最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時間后勇边，最終能夠達(dá)到一致的狀態(tài)。弱一致性和強一致性相反折联，最終一致性是弱一致性的一種特殊情況
9.說說微服務(wù)與 SOA 的區(qū)別
微服務(wù)是 SOA 發(fā)展出來的產(chǎn)物粒褒，它是一種比較現(xiàn)代化的細(xì)粒度的 SOA 實現(xiàn)方式。
較早實踐微服務(wù)的公司 Netflix 就曾經(jīng)稱他們構(gòu)建的架構(gòu)是「細(xì)粒度的 SOA」诚镰。
討論「微服務(wù)和 SOA 的差別」的意義遠(yuǎn)不如討論「微服務(wù)和單體系統(tǒng)的差別」更大奕坟，因為他們的區(qū)別實在有點微妙。此外清笨，互聯(lián)網(wǎng)近些年的發(fā)展月杉，越來越朝去中心化的方向前進(jìn)了，就像今天的 IT 工程師不需要像律師抠艾、教師那樣苛萎，需要得到某些機構(gòu)的認(rèn)可才能更好的開展工作，這一方面意味著門檻的降低检号，另一方面也意味著更多的概念沒有一個權(quán)威的聲音來對它進(jìn)行定義腌歉，使得每個人可以根據(jù)自己的需求做出不同的調(diào)整
10.如何應(yīng)對微服務(wù)的鏈?zhǔn)秸{(diào)用異常
一般情況下，每個微服務(wù)之間是獨立的齐苛，如果某個服務(wù)宕機翘盖，只會影響到當(dāng)前服務(wù)，而不會對整個業(yè)務(wù)系統(tǒng)產(chǎn)生影響凹蜂。但是馍驯，服務(wù)端可能會在多個微服務(wù)之間產(chǎn)生一條鏈?zhǔn)秸{(diào)用，并把整合后的信息返回給客戶端玛痊。在調(diào)用過程中汰瘫，如果某個服務(wù)宕機或者網(wǎng)絡(luò)不穩(wěn)定可能造成整個請求失敗。因此擂煞，為了應(yīng)對微服務(wù)的鏈?zhǔn)秸{(diào)用異常混弥，我們需要在設(shè)計微服務(wù)調(diào)用鏈時不宜過長，以免客戶端長時間等待颈娜，以及中間環(huán)節(jié)出現(xiàn)錯誤造成整個請求失敗剑逃。此外，可以考慮使用消息隊列進(jìn)行業(yè)務(wù)解耦官辽，并且使用緩存避免微服務(wù)的鏈?zhǔn)秸{(diào)用從而提高該接口的可用性
11.微服務(wù)的安全
OAuth 是一個關(guān)于授權(quán)的開放網(wǎng)絡(luò)標(biāo)準(zhǔn)蛹磺，它允許第三方網(wǎng)站在用戶授權(quán)的前提下訪問用戶在服務(wù)商那里存儲的各種信息。實際上同仆，OAuth 2.0 允許用戶提供一個令牌給第三方網(wǎng)站萤捆，一個令牌對應(yīng)一個特定的第三方網(wǎng)站，同時該令牌只能在特定的時間內(nèi)訪問特定的資源。用戶在客戶端使用用戶名和密碼在用戶中心獲得授權(quán)俗或，然后客戶端在訪問應(yīng)用是附上 Token 令牌市怎。此時，應(yīng)用接收到客戶端的 Token 令牌到用戶中心進(jìn)行認(rèn)證
一般情況下辛慰，access token 會添加到 HTTP Header 的 Authorization 參數(shù)中使用区匠，其中經(jīng)常使用到的是 Bearer Token 與 Mac Token。其中帅腌，Bearer Token 適用于安全的網(wǎng)絡(luò)下 API 授權(quán)驰弄。MAC Token 適用于不安全的網(wǎng)絡(luò)下 API 授權(quán)。
