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 更強(qiáng)大。

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ū)的強(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)用剿配，也就是說兩臺服務(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 是如何通訊的

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

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

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

3.當(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ù)器

4.B 服務(wù)器收到請求后算墨，需要對參數(shù)進(jìn)行反序列化（序列化的逆操作），恢復(fù)為內(nèi)存中的表達(dá)方式汁雷，然后找到對應(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

就是無法在一個進(jìn)程內(nèi)熬苍，甚至一個計算機(jī)內(nèi)通過本地調(diào)用的方式完成的需求，比如比如不同的系統(tǒng)間的通訊袁翁，甚至不同的組織間的通訊柴底。由于計算能力需要橫向擴(kuò)展，需要在多臺機(jī)器組成的集群上部署應(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)用一樣。如何做到呢绰沥？

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

2.要有對網(wǎng)絡(luò)通信的封裝，要對調(diào)用方來說通信細(xì)節(jié)是完全不可見的秃臣，網(wǎng)絡(luò)通信要做的就是將調(diào)用方法的屬性通過一定的協(xié)議（簡單來說就是消息格式）傳遞到服務(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ù)場合中我們只說 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 理論的延伸，核心思想是即使無法做到強(qiáng)一致性（Strong Consistency呀忧，CAP 的一致性就是強(qiáng)一致性）师痕，但應(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)。弱一致性和強(qiáng)一致性相反肌幽，最終一致性是弱一致性的一種特殊情況

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 工程師不需要像律師画机、教師那樣冶伞，需要得到某些機(jī)構(gòu)的認(rèn)可才能更好的開展工作，這一方面意味著門檻的降低步氏，另一方面也意味著更多的概念沒有一個權(quán)威的聲音來對它進(jìn)行定義响禽，使得每個人可以根據(jù)自己的需求做出不同的調(diào)整

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

一般情況下，每個微服務(wù)之間是獨立的荚醒，如果某個服務(wù)宕機(jī)芋类，只會影響到當(dāng)前服務(wù)，而不會對整個業(yè)務(wù)系統(tǒng)產(chǎn)生影響界阁。但是侯繁，服務(wù)端可能會在多個微服務(wù)之間產(chǎn)生一條鏈?zhǔn)秸{(diào)用，并把整合后的信息返回給客戶端泡躯。在調(diào)用過程中贮竟，如果某個服務(wù)宕機(jī)或者網(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)

分享就到這里啦！喜歡的朋友們點贊幔妨，收藏鹦赎，加關(guān)注哦！領(lǐng)取資料后臺私聊小編：即可免費領(lǐng)任蟊ぁ古话！