1.說說前后端分離是如何做的

在前后端分離架構(gòu)中，后端只需要負(fù)責(zé)按照約定的數(shù)據(jù)格式向前端提供可調(diào)用的 API 服務(wù)即可。前后端之間通過 HTTP 請(qǐng)求進(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 是一個(gè) W3C 標(biāo)準(zhǔn)，全稱是"跨域資源共享"（Cross-origin resource sharing）。它允許

瀏覽器向跨源服務(wù)器，發(fā)出 XMLHttpRequest 請(qǐng)求，從而克服了 AJAX 只能同源使用的限制。

CORS 需要瀏覽器和服務(wù)器同時(shí)支持。目前，所有瀏覽器都支持該功能，IE 瀏覽器不能低于 IE10

整個(gè) CORS 通信過程，都是瀏覽器自動(dòng)完成，不需要用戶參與。對(duì)于開發(fā)者來說，CORS 通信與同源的 AJAX 通信沒有差別，代碼完全一樣。瀏覽器一旦發(fā)現(xiàn) AJAX 請(qǐng)求跨源，就會(huì)自動(dòng)添加一些附加的頭信息，有時(shí)還會(huì)多出一次附加的請(qǐng)求，但用戶不會(huì)有感覺

因此，實(shí)現(xiàn) CORS 通信的關(guān)鍵是服務(wù)器。只要服務(wù)器實(shí)現(xiàn)了 CORS 接口，就可以跨源通信

CORS 與 JSONP 的比較

CORS 與 JSONP 的使用目的相同，但是比 JSONP 更強(qiáng)大。

JSONP 只支持 GET 請(qǐng)求，CORS 支持所有類型的 HTTP 請(qǐng)求。JSONP 的優(yōu)勢(shì)在于支持老式瀏覽器，以及可以向不支持 CORS 的網(wǎng)站請(qǐng)求數(shù)據(jù)

3.微服務(wù)哪些框架

Dubbo

是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于阿里巴巴集團(tuán)的各成員站點(diǎn)。阿里巴巴近幾年對(duì)開源社區(qū)的貢獻(xiàn)不論在國內(nèi)還是國外都是引人注目的，比如：JStorm 捐贈(zèng)給 Apache 并加入 Apache 基金會(huì)等，為中國互聯(lián)網(wǎng)人爭(zhēng)足了面子，使得阿里巴巴在國人眼里已經(jīng)從電商升級(jí)為一家科技公司了

Spring Cloud

從命名我們就可以知道，它是 Spring Source 的產(chǎn)物，Spring 社區(qū)的強(qiáng)大背書可以說是 Java 企業(yè)界最有影響力的組織了，除了 Spring Source 之外，還有 Pivotal 和 Netflix 是其強(qiáng)大的后盾與技術(shù)輸出。其中 Netflix 開源的整套微服務(wù)架構(gòu)套件是 Spring Cloud 的核心

4.你怎么理解 RPC 框架

首先我們要知道什么是 RPC

RPC 是指遠(yuǎn)程過程調(diào)用，也就是說兩臺(tái)服務(wù)器 A，B 一個(gè)應(yīng)用部署在 A 服務(wù)器上，想要調(diào)

B 服務(wù)器上應(yīng)用提供的函數(shù)或方法，由于不在一個(gè)內(nèi)存空間，不能直接調(diào)用，需要通過網(wǎng)絡(luò)來表達(dá)調(diào)用的語義和傳達(dá)調(diào)用的數(shù)據(jù)

RPC 是如何通訊的

1.要解決通訊的問題，主要是通過在客戶端和服務(wù)器之間建立 TCP 連接，遠(yuǎn)程過程調(diào)用的所有交換的數(shù)據(jù)都在這個(gè)連接里傳輸。連接可以是按需連接，調(diào)用結(jié)束后就斷掉，也可以是長(zhǎng)連接，多個(gè)遠(yuǎn)程過程調(diào)用共享同一個(gè)連接

2.要解決尋址的問題，也就是說，A 服務(wù)器上的應(yīng)用怎么告訴底層的 RPC 框架，如何連接

B 服務(wù)器（如主機(jī)或 IP 地址）以及特定的端口，方法的名稱是什么，這樣才能完成調(diào)用。比如基于 Web 服務(wù)協(xié)議棧的 RPC，就要提供一個(gè) endpoint URI，或者是從 UDDI 服務(wù)上查找。如果是 RMI 調(diào)用的話，還需要一個(gè) RMI Registry 來注冊(cè)服務(wù)的地址

3.當(dāng) A 服務(wù)器上的應(yīng)用發(fā)起遠(yuǎn)程過程調(diào)用時(shí)，方法的參數(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ù)器

4.B 服務(wù)器收到請(qǐng)求后，需要對(duì)參數(shù)進(jìn)行反序列化（序列化的逆操作），恢復(fù)為內(nèi)存中的表達(dá)方式，然后找到對(duì)應(yīng)的方法（尋址的一部分）進(jìn)行本地調(diào)用，然后得到返回值

5.返回值還要發(fā)送回服務(wù)器 A 上的應(yīng)用，也要經(jīng)過序列化的方式發(fā)送，服務(wù)器 A 接到后，

再反序列化，恢復(fù)為內(nèi)存中的表達(dá)方式，交給 A 服務(wù)器上的應(yīng)用

為什么要用 RPC

就是無法在一個(gè)進(jìn)程內(nèi)，甚至一個(gè)計(jì)算機(jī)內(nèi)通過本地調(diào)用的方式完成的需求，比如比如不同的系統(tǒng)間的通訊，甚至不同的組織間的通訊。由于計(jì)算能力需要橫向擴(kuò)展，需要在多臺(tái)機(jī)器組成的集群上部署應(yīng)用

5.說說 RPC 的實(shí)現(xiàn)原理

首先需要有處理網(wǎng)絡(luò)連接通訊的模塊，負(fù)責(zé)連接建立、管理和消息的傳輸。其次需要有編解碼的模塊，因?yàn)榫W(wǎng)絡(luò)通訊都是傳輸?shù)淖止?jié)碼，需要將我們使用的對(duì)象序列化和反序列化。剩下的就是客戶端和服務(wù)器端的部分，服務(wù)器端暴露要開放的服務(wù)接口，客戶調(diào)用服務(wù)接口的一個(gè)代理實(shí)現(xiàn)，這個(gè)代理實(shí)現(xiàn)負(fù)責(zé)收集數(shù)據(jù)、編碼并傳輸給服務(wù)器然后等待結(jié)果返回

6.說說 Dubbo 的實(shí)現(xiàn)原理

Dubbo 作為 RPC 框架，實(shí)現(xiàn)的效果就是調(diào)用遠(yuǎn)程的方法就像在本地調(diào)用一樣。如何做到呢？

1.本地有對(duì)遠(yuǎn)程方法的描述，包括方法名、參數(shù)、返回值，在 Dubbo 中是遠(yuǎn)程和本地使用同樣的接口

2.要有對(duì)網(wǎng)絡(luò)通信的封裝，要對(duì)調(diào)用方來說通信細(xì)節(jié)是完全不可見的，網(wǎng)絡(luò)通信要做的就是將調(diào)用方法的屬性通過一定的協(xié)議（簡(jiǎn)單來說就是消息格式）傳遞到服務(wù)端

3.服務(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ù)場(chǎng)合中我們只說 REST 或者 RESTful。Fielding 在論文中將 REST 定位為“分布式超媒體應(yīng)用（Distributed Hypermedia System）”的架構(gòu)風(fēng)格，它在文中提到一個(gè)名為“HATEOAS（Hypermedia as the engine of application state）”的概念。

我們利用一個(gè)面向最終用戶的 Web 應(yīng)用來對(duì)這個(gè)概念進(jìn)行簡(jiǎn)單闡述：這里所謂的應(yīng)用狀態(tài)（Application State）表示 Web 應(yīng)用的客戶端的狀態(tài)，簡(jiǎn)單起見可以理解為會(huì)話狀態(tài)。資源在瀏覽器中以超媒體的形式呈現(xiàn)，通過點(diǎn)擊超媒體中的鏈接可以獲取其它相關(guān)的資源或者對(duì)當(dāng)前資源進(jìn)行相應(yīng)的處理，獲取的資源或者針對(duì)資源處理的響應(yīng)同樣以超媒體的形式再次呈現(xiàn)在瀏覽器上。由此可見，超媒體成為了驅(qū)動(dòng)客戶端會(huì)話狀態(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 會(huì)議上提出 CAP 猜想。2 年后，麻省理工學(xué)院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了 CAP。之后，CAP理論正式成為分布式計(jì)算領(lǐng)域的公認(rèn)定理。

CAP 理論為：一個(gè)分布式系統(tǒng)最多只能同時(shí)滿足一致性（Consistency）、可用性（Availability）和分區(qū)容錯(cuò)性（Partition tolerance）這三項(xiàng)中的兩項(xiàng)

一致性（Consistency）

一致性指 “all nodes see the same data at the same time”，即更新操作成功并返回客戶端完成后，所有節(jié)點(diǎn)在同一時(shí)間的數(shù)據(jù)完全一致

可用性（Availability）

可用性指“Reads and writes always succeed”，即服務(wù)一直可用，而且是正常響應(yīng)時(shí)間

分區(qū)容錯(cuò)性（Partition tolerance）

分區(qū)容錯(cuò)性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系統(tǒng)在遇到某節(jié)點(diǎn)或網(wǎng)絡(luò)分區(qū)故障的時(shí)候，仍然能夠?qū)ν馓峁M

足一致性和可用性的服務(wù)

BASE 理論

eBay 的架構(gòu)師 Dan Pritchett 源于對(duì)大規(guī)模分布式系統(tǒng)的實(shí)踐總結(jié)，在 ACM 上發(fā)表文章提

BASE 理論，BASE 理論是對(duì) CAP 理論的延伸，核心思想是即使無法做到強(qiáng)一致性（Strong Consistency，CAP 的一致性就是強(qiáng)一致性），但應(yīng)用可以采用適合的方式達(dá)到最終一致性（Eventual Consitency）

基本可用（Basically Available）

基本可用是指分布式系統(tǒng)在出現(xiàn)故障的時(shí)候，允許損失部分可用性，即保證核心可用。

電商大促時(shí)，為了應(yīng)對(duì)訪問量激增，部分用戶可能會(huì)被引導(dǎo)到降級(jí)頁面，服務(wù)層也可能只提供降級(jí)服務(wù)。這就是損失部分可用性的體現(xiàn)

軟狀態(tài)（Soft State）

軟狀態(tài)是指允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會(huì)影響系統(tǒng)整體可用性。分布式存儲(chǔ)中一般一份數(shù)據(jù)至少會(huì)有三個(gè)副本，允許不同節(jié)點(diǎn)間副本同步的延時(shí)就是軟狀態(tài)的體現(xiàn)。mysql replication 的異步復(fù)制也是一種體現(xiàn)

最終一致性（Eventual Consistency）

最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時(shí)間后，最終能夠達(dá)到一致的狀態(tài)。弱一致性和強(qiáng)一致性相反，最終一致性是弱一致性的一種特殊情況

9.說說微服務(wù)與 SOA 的區(qū)別

微服務(wù)是 SOA 發(fā)展出來的產(chǎn)物，它是一種比較現(xiàn)代化的細(xì)粒度的 SOA 實(shí)現(xiàn)方式。

較早實(shí)踐微服務(wù)的公司 Netflix 就曾經(jīng)稱他們構(gòu)建的架構(gòu)是「細(xì)粒度的 SOA」。

討論「微服務(wù)和 SOA 的差別」的意義遠(yuǎn)不如討論「微服務(wù)和單體系統(tǒng)的差別」更大，因?yàn)樗麄兊膮^(qū)別實(shí)在有點(diǎn)微妙。此外，互聯(lián)網(wǎng)近些年的發(fā)展，越來越朝去中心化的方向前進(jìn)了，就像今天的 IT 工程師不需要像律師、教師那樣，需要得到某些機(jī)構(gòu)的認(rèn)可才能更好的開展工作，這一方面意味著門檻的降低，另一方面也意味著更多的概念沒有一個(gè)權(quán)威的聲音來對(duì)它進(jìn)行定義，使得每個(gè)人可以根據(jù)自己的需求做出不同的調(diào)整

10.如何應(yīng)對(duì)微服務(wù)的鏈?zhǔn)秸{(diào)用異常

一般情況下，每個(gè)微服務(wù)之間是獨(dú)立的，如果某個(gè)服務(wù)宕機(jī)，只會(huì)影響到當(dāng)前服務(wù)，而不會(huì)對(duì)整個(gè)業(yè)務(wù)系統(tǒng)產(chǎn)生影響。但是，服務(wù)端可能會(huì)在多個(gè)微服務(wù)之間產(chǎn)生一條鏈?zhǔn)秸{(diào)用，并把整合后的信息返回給客戶端。在調(diào)用過程中，如果某個(gè)服務(wù)宕機(jī)或者網(wǎng)絡(luò)不穩(wěn)定可能造成整個(gè)請(qǐng)求失敗。因此，為了應(yīng)對(duì)微服務(wù)的鏈?zhǔn)秸{(diào)用異常，我們需要在設(shè)計(jì)微服務(wù)調(diào)用鏈時(shí)不宜過長(zhǎng)，以免客戶端長(zhǎng)時(shí)間等待，以及中間環(huán)節(jié)出現(xiàn)錯(cuò)誤造成整個(gè)請(qǐng)求失敗。此外，可以考慮使用消息隊(duì)列進(jìn)行業(yè)務(wù)解耦，并且使用緩存避免微服務(wù)的鏈?zhǔn)秸{(diào)用從而提高該接口的可用性

11.微服務(wù)的安全

OAuth 是一個(gè)關(guān)于授權(quán)的開放網(wǎng)絡(luò)標(biāo)準(zhǔn)，它允許第三方網(wǎng)站在用戶授權(quán)的前提下訪問用戶在服務(wù)商那里存儲(chǔ)的各種信息。實(shí)際上，OAuth 2.0 允許用戶提供一個(gè)令牌給第三方網(wǎng)站，一個(gè)令牌對(duì)應(yīng)一個(gè)特定的第三方網(wǎng)站，同時(shí)該令牌只能在特定的時(shí)間內(nèi)訪問特定的資源。用戶在客戶端使用用戶名和密碼在用戶中心獲得授權(quán)，然后客戶端在訪問應(yīng)用是附上 Token 令牌。此時(shí)，應(yīng)用接收到客戶端的 Token 令牌到用戶中心進(jìn)行認(rèn)證

一般情況下，access token 會(huì)添加到 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)

分享就到這里啦！喜歡的朋友們點(diǎn)贊，收藏，加關(guān)注哦！領(lǐng)取資料后臺(tái)私聊小編：即可免費(fèi)領(lǐng)??！