Java面試總結匯總，整理了包括Java基礎知識，集合容器，併發編程，JVM，常用開源框架Spring，MyBatis，數據庫，中間件等，包含了作爲一個Java工程師在面試中需要用到或者可能用到的絕大部分知識。歡迎大家閱讀文章持續更新中…
基礎知識
爲什麼要用 Dubbo？
隨着服務化的進一步發展，服務越來越多，服務之間的調用和依賴關係也越來越複雜，誕生了面向服務的架構體系(SOA)，也因此衍生出了一系列相應的技術，如對服務提供、服務調用、連接處理、通信協議、序列化方式、服務發現、服務路由、日誌輸出等行爲進行封裝的服務框架。就這樣爲分佈式系統的服務治理框架就出現了，Dubbo 也就這樣產生了。
Dubbo 是什麼？
Dubbo 是一款高性能、輕量級的開源 RPC 框架，提供服務自動註冊、自動發現等高效服務治理方案， 可以和 Spring 框架無縫集成。
.
Dubbo 的使用場景有哪些？
- 透明化的遠程方法調用：就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。
- 軟負載均衡及容錯機制：可在內網替代 F5 等硬件負載均衡器，降低成本，減少單點。
- 服務自動註冊與發現：不再需要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。
Dubbo 核心功能有哪些？
- Remoting：網絡通信框架，提供對多種NIO框架抽象封裝，包括“同步轉異步”和“請求-響應”模式的信息交換方式。
- Cluster：服務框架，提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。
- Registry：服務註冊，基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
架構設計
Dubbo 核心組件有哪些？![]()
- Provider：暴露服務的服務提供方
- Consumer：調用遠程服務消費方
- Registry：服務註冊與發現註冊中心
- Monitor：監控中心和訪問調用統計
- Container：服務運行容器
Dubbo 服務器註冊與發現的流程？
服務容器Container負責啓動，加載，運行服務提供者。
服務提供者Provider在啓動時，向註冊中心註冊自己提供的服務。
服務消費者Consumer在啓動時，向註冊中心訂閱自己所需的服務。
註冊中心Registry返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
服務消費者Consumer，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
服務消費者Consumer和提供者Provider，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心Monitor。
Dubbo 的整體架構設計有哪些分層?
接口服務層（Service）：該層與業務邏輯相關，根據 provider 和 consumer 的業務設計對應的接口和實現
配置層（Config）：對外配置接口，以 ServiceConfig 和 ReferenceConfig 爲中心
服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端 Stub 和 服務端的 Skeleton，以 ServiceProxy 爲中心，擴展接口爲 ProxyFactory
服務註冊層（Registry）：封裝服務地址的註冊和發現，以服務 URL 爲中心，擴展接口爲 RegistryFactory、Registry、RegistryService
路由層（Cluster）：封裝多個提供者的路由和負載均衡，並橋接註冊中心，以Invoker 爲中心，擴展接口爲 Cluster、Directory、Router 和 LoadBlancce
監控層（Monitor）：RPC 調用次數和調用時間監控，以 Statistics 爲中心，擴展接口爲 MonitorFactory、Monitor 和 MonitorService
遠程調用層（Protocal）：封裝 RPC 調用，以 Invocation 和 Result 爲中心，擴展接口爲 Protocal、Invoker 和 Exporter
信息交換層（Exchange）：封裝請求響應模式，同步轉異步。以 Request 和Response 爲中心，擴展接口爲 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer
網絡 傳輸 層（Transport）：抽象 mina 和 netty 爲統一接口，以 Message 爲中心，擴展接口爲 Channel、Transporter、Client、Server 和 Codec
數據序列化層（Serialize）：可複用的一些工具，擴展接口爲 Serialization、ObjectInput、ObjectOutput 和 ThreadPool
Dubbo Monitor 實現原理？
Consumer 端在發起調用之前會先走 filter 鏈；provider 端在接收到請求時也是先走 filter 鏈，然後才進行真正的業務邏輯處理。默認情況下，在 consumer 和 provider 的 filter 鏈中都會有 Monitorfilter。
1、MonitorFilter 向 DubboMonitor 發送數據
2、DubboMonitor 將數據進行聚合後（默認聚合 1min 中的統計數據）暫存到ConcurrentMap<Statistics, AtomicReference> statisticsMap，然後使用一個含有 3 個線程（線程名字：DubboMonitorSendTimer）的線程池每隔 1min 鍾，調用 SimpleMonitorService 遍歷發送 statisticsMap 中的統計數據，每發送完畢一個，就重置當前的 Statistics 的 AtomicReference
3、SimpleMonitorService 將這些聚合數據塞入 BlockingQueue queue 中（隊列大寫爲 100000）
4、SimpleMonitorService 使用一個後臺線程（線程名爲：DubboMonitorAsyncWriteLogThread）將 queue 中的數據寫入文件（該線程以死循環的形式來寫）
5、SimpleMonitorService 還會使用一個含有 1 個線程（線程名字：DubboMonitorTimer）的線程池每隔 5min 鍾，將文件中的統計數據畫成圖表
分佈式框架
Dubbo 類似的分佈式框架還有哪些？
比較著名的就是 Spring Cloud。
Dubbo 和 Spring Cloud 有什麼關係？
Dubbo 是 SOA 時代的產物，它的關注點主要在於服務的調用，流量分發、流量監控和熔斷。而 Spring Cloud 誕生於微服務架構時代，考慮的是微服務治理的方方面面，另外由於依託了 Spring、Spring Boot 的優勢之上，兩個框架在開始目標就不一致，Dubbo 定位服務治理、Spring Cloud 是打造一個生態。
Dubbo 和 Spring Cloud 有什麼哪些區別？
Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基於 TCP 協議傳輸的，配合以 Hession 序列化完成 RPC 通信。
Spring Cloud 是基於 Http 協議 Rest 接口調用遠程過程的通信，相對來說 Http 請求會有更大的報文，佔的帶寬也會更多。但是 REST 相比 RPC 更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更爲合適，至於注重通信速度還是方便靈活性，具體情況具體考慮。
Dubbo 和 Dubbox 之間的區別？
Dubbox 是繼 Dubbo 停止維護後，噹噹網基於 Dubbo 做的一個擴展項目，如加了服務可 Restful 調用，更新了開源組件等。
註冊中心
Dubbo 有哪些註冊中心？
Multicast 註冊中心：Multicast 註冊中心不需要任何中心節點，只要廣播地址，就能進行服務註冊和發現,基於網絡中組播傳輸實現。
Zookeeper 註冊中心：基於分佈式協調系統 Zookeeper 實現，採用 Zookeeper 的 watch 機制實現數據變更。
Redis 註冊中心：基於 Redis 實現，採用 key/map 存儲，key 存儲服務名和類型，map 中 key 存儲服務 url，value 服務過期時間。基於 Redis 的發佈/訂閱模式通知數據變更。
Simple 註冊中心。
推薦使用 Zookeeper 作爲註冊中心
Dubbo 的註冊中心集羣掛掉，發佈者和訂閱者之間還能通信麼？
可以通訊。啓動 Dubbo 時，消費者會從 Zookeeper 拉取註冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用。
集羣
Dubbo集羣提供了哪些負載均衡策略？
- Random LoadBalance: 隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，調用次數越多，分佈越均勻。
- RoundRobin LoadBalance: 輪循選取提供者策略，平均分佈，但是存在請求累積的問題。
- LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收更少的請求。
- ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數請求總是發到同一提供者，一臺機器宕機，可以基於虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動。
默認爲 Random 隨機調用。
Dubbo的集羣容錯方案有哪些？
- Failover Cluster：失敗自動切換，當出現失敗，重試其它服務器。通常用於讀操作，但重試會帶來更長延遲。
- Failfast Cluster：快速失敗，只發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
- Failsafe Cluster：失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。
- Failback Cluster：失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於消息通知操作。
- Forking Cluster：並行調用多個服務器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks=”2″ 來設置最大並行數。
- Broadcast Cluster：廣播調用所有提供者，逐個調用，任意一臺報錯則報錯 。通常用於通知所有提供者更新緩存或日誌等本地資源信息。
默認的容錯方案是 Failover Cluster。
配置
Dubbo 配置文件是如何加載到 Spring 中的？
Spring 容器在啓動的時候，會讀取到 Spring 默認的一些 schema 以及 Dubbo 自定義的 schema，每個 schema 都會對應一個自己的 NamespaceHandler，NamespaceHandler 裏面通過 BeanDefinitionParser 來解析配置信息並轉化爲需要加載的 bean 對象！
說說核心的配置有哪些？
Dubbo 超時設置有哪些方式？
Dubbo 超時設置有兩種方式：
- 服務提供者端設置超時時間，在Dubbo的用戶文檔中，推薦如果能在服務端多配置就儘量多配置，因爲服務提供者比消費者更清楚自己提供的服務特性。
- 服務消費者端設置超時時間，如果在消費者端設置了超時時間，以消費者端爲主，即優先級更高。因爲服務調用方設置超時時間控制性更靈活。如果消費方超時，服務端線程不會定製，會產生警告。
服務調用超時會怎麼樣？
dubbo 在調用服務不成功時，默認是會重試兩次。
通信協議
Dubbo 使用的是什麼通信框架?
默認使用 Netty 作爲通訊框架。
Dubbo 支持哪些協議，它們的優缺點有哪些？
- Dubbo： 單一長連接和 NIO 異步通訊，適合大併發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議 TCP，異步 Hessian 序列化。Dubbo推薦使用dubbo協議。
- RMI： 採用 JDK 標準的 RMI 協議實現，傳輸參數和返回參數對象需要實現 Serializable 接口，使用 Java 標準序列化機制，使用阻塞式短連接，傳輸數據包大小混合，消費者和提供者個數差不多，可傳文件，傳輸協議 TCP。 多個短連接 TCP 協議傳輸，同步傳輸，適用常規的遠程服務調用和 RMI 互操作。在依賴低版本的 Common-Collections 包，Java 序列化存在安全漏洞。
- WebService：基於 WebService 的遠程調用協議，集成 CXF 實現，提供和原生 WebService 的互操作。多個短連接，基於 HTTP 傳輸，同步傳輸，適用系統集成和跨語言調用。
- HTTP： 基於 Http 表單提交的遠程調用協議，使用 Spring 的 HttpInvoke 實現。多個短連接，傳輸協議 HTTP，傳入參數大小混合，提供者個數多於消費者，需要給應用程序和瀏覽器 JS 調用。
- Hessian：集成 Hessian 服務，基於 HTTP 通訊，採用 Servlet 暴露服務，Dubbo 內嵌 Jetty 作爲服務器時默認實現，提供與 Hession 服務互操作。多個短連接，同步 HTTP 傳輸，Hessian 序列化，傳入參數較大，提供者大於消費者，提供者壓力較大，可傳文件。
- Memcache：基於 Memcache實現的 RPC 協議。
- Redis：基於 Redis 實現的RPC協議。
設計模式
Dubbo 用到哪些設計模式？
Dubbo 框架在初始化和通信過程中使用了多種設計模式，可靈活控制類加載、權限控制等功能。
工廠模式
Provider 在 export 服務時，會調用 ServiceConfig 的 export 方法。ServiceConfig中有個字段：
- private static final Protocol protocol =
- ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi
- on();
Dubbo 裏有很多這種代碼。這也是一種工廠模式，只是實現類的獲取採用了 JDKSPI 的機制。這麼實現的優點是可擴展性強，想要擴展實現，只需要在 classpath下增加個文件就可以了，代碼零侵入。另外，像上面的 Adaptive 實現，可以做到調用時動態決定調用哪個實現，但是由於這種實現採用了動態代理，會造成代碼調試比較麻煩，需要分析出實際調用的實現類。
裝飾器模式
Dubbo 在啓動和調用階段都大量使用了裝飾器模式。以 Provider 提供的調用鏈爲例，具體的調用鏈代碼是在 ProtocolFilterWrapper 的 buildInvokerChain 完成的，具體是將註解中含有 group=provider 的 Filter 實現，按照 order 排序，最後的調用順序是：
- EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter ->
- ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter ->
- ExceptionFilter
更確切地說，這裏是裝飾器和責任鏈模式的混合使用。例如，EchoFilter 的作用是判斷是否是回聲測試請求，是的話直接返回內容，這是一種責任鏈的體現。而像ClassLoaderFilter 則只是在主功能上添加了功能，更改當前線程的 ClassLoader，這是典型的裝飾器模式。
觀察者模式
Dubbo 的 Provider 啓動時，需要與註冊中心交互，先註冊自己的服務，再訂閱自己的服務，訂閱時，採用了觀察者模式，開啓一個 listener。註冊中心會每 5 秒定時檢查是否有服務更新，如果有更新，向該服務的提供者發送一個 notify 消息，provider 接受到 notify 消息後，運行 NotifyListener 的 notify 方法，執行監聽器方法。
動態代理模式
Dubbo 擴展 JDK SPI 的類 ExtensionLoader 的 Adaptive 實現是典型的動態代理實現。Dubbo 需要靈活地控制實現類，即在調用階段動態地根據參數決定調用哪個實現類，所以採用先生成代理類的方法，能夠做到靈活的調用。生成代理類的代碼是 ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理類主要邏輯是，獲取 URL 參數中指定參數的值作爲獲取實現類的 key。
運維管理
服務上線怎麼兼容舊版本？
可以用版本號（version）過渡，多個不同版本的服務註冊到註冊中心，版本號不同的服務相互間不引用。這個和服務分組的概念有一點類似。
Dubbo telnet 命令能做什麼？
dubbo 服務發佈之後，我們可以利用 telnet 命令進行調試、管理。Dubbo2.0.5 以上版本服務提供端口支持 telnet 命令
Dubbo 支持服務降級嗎？
以通過 dubbo:reference 中設置 mock=“return null”。mock 的值也可以修改爲 true，然後再跟接口同一個路徑下實現一個 Mock 類，命名規則是 “接口名稱+Mock” 後綴。然後在 Mock 類裏實現自己的降級邏輯
Dubbo 如何優雅停機？
Dubbo 是通過 JDK 的 ShutdownHook 來完成優雅停機的，所以如果使用kill -9 PID 等強制關閉指令，是不會執行優雅停機的，只有通過 kill PID 時，纔會執行。
SPI
Dubbo SPI 和 Java SPI 區別？
JDK SPI：
JDK 標準的 SPI 會一次性加載所有的擴展實現，如果有的擴展很耗時，但也沒用上，很浪費資源。所以只希望加載某個的實現，就不現實了
DUBBO SPI：
1、對 Dubbo 進行擴展，不需要改動 Dubbo 的源碼
2、延遲加載，可以一次只加載自己想要加載的擴展實現。
3、增加了對擴展點 IOC 和 AOP 的支持，一個擴展點可以直接 setter 注入其
它擴展點。4、Dubbo 的擴展機制能很好的支持第三方 IoC 容器，默認支持 Spring Bean。
其他
Dubbo 支持分佈式事務嗎？
目前暫時不支持，可與通過 tcc-transaction 框架實現
介紹：tcc-transaction 是開源的 TCC 補償性分佈式事務框架
TCC-Transaction 通過 Dubbo 隱式傳參的功能，避免自己對業務代碼的入侵。
Dubbo 可以對結果進行緩存嗎？
爲了提高數據訪問的速度。Dubbo 提供了聲明式緩存，以減少用戶加緩存的工作量<dubbo:reference cache=“true” />
其實比普通的配置文件就多了一個標籤 cache=“true”
Dubbo 必須依賴的包有哪些？
Dubbo 必須依賴 JDK，其他爲可選。
Dubbo 支持哪些序列化方式？
默認使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列化。
Dubbo 在安全方面有哪些措施？
- Dubbo 通過 Token 令牌防止用戶繞過註冊中心直連，然後在註冊中心上管理授權。
- Dubbo 還提供服務黑白名單，來控制服務所允許的調用方。
服務調用是阻塞的嗎？
默認是阻塞的，可以異步調用，沒有返回值的可以這麼做。Dubbo 是基於 NIO 的非阻塞實現並行調用，客戶端不需要啓動多線程即可完成並行調用多個遠程服務，相對多線程開銷較小，異步調用會返回一個 Future 對象。
服務提供者能實現失效踢出是什麼原理？
服務失效踢出基於 zookeeper 的臨時節點原理。
同一個服務多個註冊的情況下可以直連某一個服務嗎？
可以點對點直連，修改配置即可，也可以通過 telnet 直接某個服務。
Dubbo 服務降級，失敗重試怎麼做？
可以通過 dubbo:reference 中設置 mock=“return null”。mock 的值也可以修改爲 true，然後再跟接口同一個路徑下實現一個 Mock 類，命名規則是 “接口名稱+Mock” 後綴。然後在 Mock 類裏實現自己的降級邏輯
Dubbo 使用過程中都遇到了些什麼問題？
在註冊中心找不到對應的服務,檢查 service 實現類是否添加了@service 註解無法連接到註冊中心,檢查配置文件中的對應的測試 ip 是否正確
RPC
爲什麼要有RPC
http接口是在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。但是如果是一個大型的網站，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像http一樣去3次握手什麼的，減少了網絡開銷；其次就是RPC框架一般都有註冊中心，有豐富的監控管理；發佈、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。第三個來說就是安全性。最後就是最近流行的服務化架構、服務化治理，RPC框架是一個強力的支撐。
socket只是一個簡單的網絡通信方式，只是創建通信雙方的通信通道，而要實現rpc的功能，還需要對其進行封裝，以實現更多的功能。
RPC一般配合netty框架、spring自定義註解來編寫輕量級框架，其實netty內部是封裝了socket的，較新的jdk的IO一般是NIO，即非阻塞IO，在高併發網站中，RPC的優勢會很明顯
什麼是RPC
RPC（Remote Procedure Call Protocol）遠程過程調用協議，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。簡言之，RPC使得程序能夠像訪問本地系統資源一樣，去訪問遠端系統資源。比較關鍵的一些方面包括：通訊協議、序列化、資源（接口）描述、服務框架、性能、語言支持等。
簡單的說，RPC就是從一臺機器(客戶端)上通過參數傳遞的方式調用另一臺機器(服務器)上的一個函數或方法(可以統稱爲服務)並得到返回的結果。
PRC架構組件
一個基本的RPC架構裏面應該至少包含以下4個組件：
1、客戶端（Client）:服務調用方（服務消費者）
2、客戶端存根（Client Stub）:存放服務端地址信息，將客戶端的請求參數數據信息打包成網絡消息，再通過網絡傳輸發送給服務端
3、服務端存根（Server Stub）:接收客戶端發送過來的請求消息並進行解包，然後再調用本地服務進行處理
4、服務端（Server）:服務的真正提供者
具體調用過程：
1、服務消費者（client客戶端）通過調用本地服務的方式調用需要消費的服務；
2、客戶端存根（client stub）接收到調用請求後負責將方法、入參等信息序列化（組裝）成能夠進行網絡傳輸的消息體；
3、客戶端存根（client stub）找到遠程的服務地址，並且將消息通過網絡發送給服務端；
4、服務端存根（server stub）收到消息後進行解碼（反序列化操作）；
5、服務端存根（server stub）根據解碼結果調用本地的服務進行相關處理；
6、本地服務執行具體業務邏輯並將處理結果返回給服務端存根（server stub）；
7、服務端存根（server stub）將返回結果重新打包成消息（序列化）並通過網絡發送至消費方；
8、客戶端存根（client stub）接收到消息，並進行解碼（反序列化）；
9、服務消費方得到最終結果；
而RPC框架的實現目標則是將上面的第2-10步完好地封裝起來，也就是把調用、編碼/解碼的過程給封裝起來，讓用戶感覺上像調用本地服務一樣的調用遠程服務。
RPC和SOA、SOAP、REST的區別
1、REST
可以看着是HTTP協議的一種直接應用，默認基於JSON作爲傳輸格式,使用簡單,學習成本低效率高,但是安全性較低。
2、SOAP
SOAP是一種數據交換協議規範,是一種輕量的、簡單的、基於XML的協議的規範。而SOAP可以看着是一個重量級的協議，基於XML、SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規範組成了WS-Security來實現安全控制的,當前已經得到了各個廠商的支持 。
它有什麼優點？簡單總結爲：易用、靈活、跨語言、跨平臺。
3、SOA
面向服務架構，它可以根據需求通過網絡對鬆散耦合的粗粒度應用組件進行分佈式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟件代理交互的人爲依賴性。
SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、XML（標準通用標記語言的子集）/Web Service技術之後的自然延伸。
4、REST 和 SOAP、RPC 有何區別呢?
沒什麼太大區別，他們的本質都是提供可支持分佈式的基礎服務，最大的區別在於他們各自的的特點所帶來的不同應用場景 。
RPC框架需要解決的問題？
1、如何確定客戶端和服務端之間的通信協議？
2、如何更高效地進行網絡通信？
3、服務端提供的服務如何暴露給客戶端？
4、客戶端如何發現這些暴露的服務？
5、如何更高效地對請求對象和響應結果進行序列化和反序列化操作？
RPC的實現基礎？
1、需要有非常高效的網絡通信，比如一般選擇Netty作爲網絡通信框架；
2、需要有比較高效的序列化框架，比如谷歌的Protobuf序列化框架；
3、可靠的尋址方式（主要是提供服務的發現），比如可以使用Zookeeper來註冊服務等等；
4、如果是帶會話（狀態）的RPC調用，還需要有會話和狀態保持的功能；
RPC使用了哪些關鍵技術？
1、動態代理
生成Client Stub（客戶端存根）和Server Stub（服務端存根）的時候需要用到Java動態代理技術，可以使用JDK提供的原生的動態代理機制，也可以使用開源的：CGLib代理，Javassist字節碼生成技術。
2、序列化和反序列化
在網絡中，所有的數據都將會被轉化爲字節進行傳送，所以爲了能夠使參數對象在網絡中進行傳輸，需要對這些參數進行序列化和反序列化操作。
- 序列化：把對象轉換爲字節序列的過程稱爲對象的序列化，也就是編碼的過程。
- 反序列化：把字節序列恢復爲對象的過程稱爲對象的反序列化，也就是解碼的過程。
目前比較高效的開源序列化框架：如Kryo、FastJson和Protobuf等。
3、NIO通信
出於併發性能的考慮，傳統的阻塞式 IO 顯然不太合適，因此我們需要異步的 IO，即 NIO。Java 提供了 NIO 的解決方案，Java 7 也提供了更優秀的 NIO.2 支持。可以選擇Netty或者MINA來解決NIO數據傳輸的問題。
4、服務註冊中心
可選：Redis、Zookeeper、Consul 、Etcd。一般使用ZooKeeper提供服務註冊與發現功能，解決單點故障以及分佈式部署的問題(註冊中心)。
主流RPC框架有哪些
1、RMI
利用java.rmi包實現，基於Java遠程方法協議(Java Remote Method Protocol) 和java的原生序列化。
2、Hessian
是一個輕量級的remoting onhttp工具，使用簡單的方法提供了RMI的功能。 基於HTTP協議，採用二進制編解碼。
3、protobuf-rpc-pro
是一個Java類庫，提供了基於 Google 的 Protocol Buffers 協議的遠程方法調用的框架。基於 Netty 底層的 NIO 技術。支持 TCP 重用/ keep-alive、SSL加密、RPC 調用取消操作、嵌入式日誌等功能。
4、Thrift
是一種可伸縮的跨語言服務的軟件框架。它擁有功能強大的代碼生成引擎，無縫地支持C + +，C#，Java，Python和PHP和Ruby。thrift允許你定義一個描述文件，描述數據類型和服務接口。依據該文件，編譯器方便地生成RPC客戶端和服務器通信代碼。
最初由facebook開發用做系統內個語言之間的RPC通信，2007年由facebook貢獻到apache基金 ，現在是apache下的opensource之一 。支持多種語言之間的RPC方式的通信：php語言client可以構造一個對象，調用相應的服務方法來調用java語言的服務，跨越語言的C/S RPC調用。底層通訊基於SOCKET。
5、Avro
出自Hadoop之父Doug Cutting, 在Thrift已經相當流行的情況下推出Avro的目標不僅是提供一套類似Thrift的通訊中間件,更是要建立一個新的，標準性的雲計算的數據交換和存儲的Protocol。支持HTTP，TCP兩種協議。
6、Dubbo
Dubbo是 阿里巴巴公司開源的一個高性能優秀的服務框架，使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能，可以和 Spring框架無縫集成。
RPC的實現原理架構圖
PS：這張圖非常重點，是PRC的基本原理，請大家一定記住！
也就是說兩臺服務器A，B，一個應用部署在A服務器上，想要調用B服務器上應用提供的函數/方法，由於不在一個內存空間，不能直接調用，需要通過網絡來表達調用的語義和傳達調用的數據。
比如說，A服務器想調用B服務器上的一個方法：User getUserByName(String userName)
1、建立通信
首先要解決通訊的問題：即A機器想要調用B機器，首先得建立起通信連接。
主要是通過在客戶端和服務器之間建立TCP連接，遠程過程調用的所有交換的數據都在這個連接裏傳輸。連接可以是按需連接，調用結束後就斷掉，也可以是長連接，多個遠程過程調用共享同一個連接。
通常這個連接可以是按需連接（需要調用的時候就先建立連接，調用結束後就立馬斷掉），也可以是長連接（客戶端和服務器建立起連接之後保持長期持有，不管此時有無數據包的發送，可以配合心跳檢測機制定期檢測建立的連接是否存活有效），多個遠程過程調用共享同一個連接。
2、服務尋址
要解決尋址的問題，也就是說，A服務器上的應用怎麼告訴底層的RPC框架，如何連接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱名稱是什麼。
通常情況下我們需要提供B機器（主機名或IP地址）以及特定的端口，然後指定調用的方法或者函數的名稱以及入參出參等信息，這樣才能完成服務的一個調用。
可靠的尋址方式（主要是提供服務的發現）是RPC的實現基石，比如可以採用Redis或者Zookeeper來註冊服務等等。
2.1、從服務提供者的角度看：
當服務提供者啓動的時候，需要將自己提供的服務註冊到指定的註冊中心，以便服務消費者能夠通過服務註冊中心進行查找；
當服務提供者由於各種原因致使提供的服務停止時，需要向註冊中心註銷停止的服務；
服務的提供者需要定期向服務註冊中心發送心跳檢測，服務註冊中心如果一段時間未收到來自服務提供者的心跳後，認爲該服務提供者已經停止服務，則將該服務從註冊中心上去掉。
2.2、從調用者的角度看：
服務的調用者啓動的時候根據自己訂閱的服務向服務註冊中心查找服務提供者的地址等信息；
當服務調用者消費的服務上線或者下線的時候，註冊中心會告知該服務的調用者；
服務調用者下線的時候，則取消訂閱。
3、網絡傳輸
3.1、序列化當A機器上的應用發起一個RPC調用時，調用方法和其入參等信息需要通過底層的網絡協議如TCP傳輸到B機器，由於網絡協議是基於二進制的，所有我們傳輸的參數數據都需要先進行序列化（Serialize）或者編組（marshal）成二進制的形式才能在網絡中進行傳輸。然後通過尋址操作和網絡傳輸將序列化或者編組之後的二進制數據發送給B機器。
3.2、反序列化
當B機器接收到A機器的應用發來的請求之後，又需要對接收到的參數等信息進行反序列化操作（序列化的逆操作），即將二進制信息恢復爲內存中的表達方式，然後再找到對應的方法（尋址的一部分）進行本地調用（一般是通過生成代理Proxy去調用,
通常會有JDK動態代理、CGLIB動態代理、Javassist生成字節碼技術等），之後得到調用的返回值。
4、服務調用
B機器進行本地調用（通過代理Proxy和反射調用）之後得到了返回值，此時還需要再把返回值發送回A機器，同樣也需要經過序列化操作，然後再經過網絡傳輸將二進制數據發送回A機器，而當A機器接收到這些返回值之後，則再次進行反序列化操作，恢復爲內存中的表達方式，最後再交給A機器上的應用進行相關處理（一般是業務邏輯處理操作）。
通常，經過以上四個步驟之後，一次完整的RPC調用算是完成了，另外可能因爲網絡抖動等原因需要重試等。