Java性能之優(yōu)化RPC網(wǎng)絡通信
服務框架的核心
- 大型服務框架的核心：RPC通信
- 微服務的核心是遠程通信和服務治理
- 遠程通信提供了服務之間通信的橋梁，服務治理提供了服務的后勤保障
服務的拆分增加了通信的成本，因此遠程通信很容易成為系統(tǒng)瓶頸
- 在滿足一定的服務治理需求的前提下，對遠程通信的性能需求是技術選型的主要影響因素
很多微服務框架中的服務通信是基于RPC通信實現(xiàn)的
- 在沒有進行組件擴展的前提下，Spring Cloud是基于Feign組件實現(xiàn)RPC通信(基于HTTP+JSON序列化)
- Dubbo是基于SPI擴展了很多RPC通信框架，包括RMI、Dubbo、Hessian等(默認為Dubbo+Hessian序列化)
性能測試
基于Dubbo:2.6.4，單一TCP長連接+Protobuf(響應時間和吞吐量更優(yōu))，短連接的HTTP+JSON序列化
RPC通信
架構演化
無論是微服務、SOA、還是RPC架構，都是分布式服務架構，都需要實現(xiàn)服務之間的互相通信，通常把這種通信統(tǒng)稱為RPC通信
概念
- RPC：Remote Process Call，遠程服務調用，通過網(wǎng)絡請求遠程計算機程序服務的通信技術
- RPC框架封裝了底層網(wǎng)絡通信和序列化等技術
- 只需要在項目中引入各個服務的接口包，就可以在代碼中調用RPC服務(如同調用本地方法一樣)
RMI
- RMI：Remote Method Invocation
- RMI是JDK自帶的RPC通信框架，已經成熟地應用于EJB和Spring，是純Java網(wǎng)絡分布式應用系統(tǒng)的核心解決方案
- RMI實現(xiàn)了一臺虛擬機應用對遠程方法的調用可以同對本地方法調用一樣，RMI封裝好了遠程通信的具體細節(jié)
實現(xiàn)原理
RMI遠程代理對象是RMI中最核心的組件，除了對象本身所在的虛擬機，其他虛擬機也可以調用此對象的方法
這些虛擬機可以分布在不同的主機上，通過遠程代理對象，遠程應用可以用網(wǎng)絡協(xié)議和服務進行通信
高并發(fā)下的性能瓶頸
Java默認序列化
RMI的序列化方式采用的是Java默認序列化，性能不好，而且不支持跨語言
TCP短連接
RMI是基于TCP短連接實現(xiàn)的，在高并發(fā)情況下，大量請求會帶來大量TCP連接的創(chuàng)建和銷毀，非常消耗性能
阻塞式網(wǎng)絡IO
Socket編程中使用傳統(tǒng)的IO模型，在高并發(fā)場景下基于短連接實現(xiàn)的網(wǎng)絡通信就很容易產生IO阻塞，性能將大打折扣
優(yōu)化路徑
TCP / UDP
網(wǎng)絡傳輸協(xié)議有TCP和UDP，兩個協(xié)議都是基于Socket編程
基于TCP協(xié)議實現(xiàn)的Socket通信是有連接的
傳輸數(shù)據(jù)要通過三次握手來實現(xiàn)數(shù)據(jù)傳輸?shù)目煽啃裕鴤鬏敂?shù)據(jù)是沒有邊界的，采用的是字節(jié)流模式
基于UDP協(xié)議實現(xiàn)的Socket通信，客戶端不需要建立連接，只需要創(chuàng)建一個套接字發(fā)送數(shù)據(jù)給服務端
基于UDP協(xié)議實現(xiàn)的Socket通信具有不可靠性
UDP發(fā)送的數(shù)據(jù)采用的是數(shù)據(jù)報模式，每個UDP的數(shù)據(jù)報都有一個長度，該長度與數(shù)據(jù)一起發(fā)送到服務端
為了保證數(shù)據(jù)傳輸?shù)目煽啃?，通常情況下會采用TCP協(xié)議
在局域網(wǎng)且對數(shù)據(jù)傳輸?shù)目煽啃詻]有要求的情況下，可以考慮使用UDP協(xié)議，UDP協(xié)議的效率比TCP協(xié)議高
長連接
服務之間的通信不同于客戶端與服務端之間的通信
由于客戶端數(shù)量眾多，基于短連接實現(xiàn)請求，可以避免長時間地占用連接，導致系統(tǒng)資源浪費
服務之間的通信，連接的消費端不會像客戶端那么多，但消費端向服務端請求的數(shù)量卻一樣多
基于長連接實現(xiàn)，可以省去大量建立TCP連接和關閉TCP連接的操作，從而減少系統(tǒng)的性能消耗，節(jié)省時間
優(yōu)化Socket通信
傳統(tǒng)的Socket通信主要存在IO阻塞，線程模型缺陷以及內存拷貝等問題，Netty4對Socket通信編程做了很多方面的優(yōu)化
實現(xiàn)非阻塞IO：多路復用器Selector實現(xiàn)了非阻塞IO通信
高效的Reactor線程模型
Netty使用了主從Reactor多線程模型
主線程：用于客戶端的連接請求操作，一旦連接建立成功，將會監(jiān)聽IO事件，監(jiān)聽到事件后會創(chuàng)建一個鏈路請求
鏈路請求將會注冊到負責IO操作的IO工作線程上，由IO工作線程負責后續(xù)的IO操作
Reactor線程模型解決了在高并發(fā)的情況下，由于單個NIO線程無法監(jiān)聽海量客戶端和滿足大量IO操作造成的問題
4.串行設計
服務端在接收消息之后，存在著編碼、解碼、讀取和發(fā)送等鏈路操作
如果這些操作基于并行實現(xiàn)，無疑會導致嚴重的鎖競爭，進而導致系統(tǒng)的性能下降
為了提升性能，Netty采用串行無鎖化完成鏈路操作，提供了Pipeline，實現(xiàn)鏈路的各個操作在運行期間不會切換線程
5.零拷貝
數(shù)據(jù)從內存發(fā)到網(wǎng)絡中，存在兩次拷貝，先是從用戶空間拷貝到內核空間，再從內核空間拷貝到網(wǎng)絡IO
NIO提供的ByteBuffer可以使用Direct Buffer模式
直接開辟一個非堆物理內存，不需要進行字節(jié)緩沖區(qū)的二次拷貝，可以直接將數(shù)據(jù)寫入到內核空間
6.優(yōu)化TCP參數(shù)配置，提高網(wǎng)絡吞吐量，Netty可以基于ChannelOption來設置
- TCP_NODELAY：用于控制是否開啟Nagle算法
- Nagle算法通過緩存的方式將小的數(shù)據(jù)包組成一個大的數(shù)據(jù)包，從而避免大量發(fā)送小的數(shù)據(jù)包，導致網(wǎng)絡阻塞
- 在對時延敏感的應用場景，可以選擇關閉該算法
- SO_RCVBUF / SO_SNDBUF：Socket接收緩沖區(qū)和發(fā)送緩沖區(qū)的大小
- SO_BACKLOG：指定客戶端連接請求緩沖隊列的大小
- 服務端處理客戶端連接請求是按順序處理的，同一時間只能處理一個客戶端連接
- 當有多個客戶端進來的時候，服務端將不能處理的客戶端連接請求放在隊列中等待處理
- SO_KEEPALIVE
- 連接會檢查長時間沒有發(fā)送數(shù)據(jù)的客戶端的連接狀態(tài)，檢測到客戶端斷開連接后，服務端將回收該連接
- 將該值設置得小一些，可以提高回收連接的效率
定制報文格式
設計一套報文，用于描述具體的校驗、操作、傳輸數(shù)據(jù)等內容
為了提高傳輸效率，可以根據(jù)實際情況來設計，盡量實現(xiàn)報體小，滿足功能，易解析等特性
字段長度(字節(jié))備注魔數(shù)4協(xié)議的標識，類似于字節(jié)碼的魔數(shù)，通常為固定數(shù)字版本號1序列化算法1Protobuf / Thrift指令1類似于HTTP中的增刪改查數(shù)據(jù)長度4數(shù)據(jù)N
編解碼
實現(xiàn)一個通信協(xié)議，需要兼容優(yōu)秀的序列化框架
如果只是單純的數(shù)據(jù)對象傳輸，可以選擇性能相對較好的Protobuf序列化，有利于提高網(wǎng)絡通信的性能
Linux的TCP參數(shù)設置
三次握手
四次揮手
配置項
1.fs.file-max = 194448 / ulimit
2.net.ipv4.tcp_keepalive_time
3.net.ipv4.tcp_max_syn_backlog
4.net.ipv4.ip_local_port_range
5.net.ipv4.tcp_max_tw_buckets
6.net.ipv4.tcp_tw_reuse
備注
1.Linux默認單個進程可以打開的文件數(shù)量上限為1024，Socket也是文件
2.與Netty的SO_KEEPALIVE配置項的作用一致
3.SYN隊列的長度，加大隊列長度，可以容納更多等待連接的網(wǎng)絡連接數(shù)
4.客戶端連接服務器時，需要動態(tài)分配源端口號，該配置項表示向外連接的端口范圍
5. 當一個連接關閉時，TCP會通過四次揮手來完成一次關閉連接操作，在請求量比較大的情況下，消費端會有大量TIME_WAIT狀態(tài)的連接,該參數(shù)可以限制TIME_WAIT狀態(tài)的連接數(shù)量，如果TIME_WAIT的連接數(shù)量超過該值，TIME_WAIT將會立即被清除掉并打印警告信息
6.客戶端每次連接服務器時，都會獲得一個新的源端口以實現(xiàn)連接的唯一性，在TIME_WAIT狀態(tài)的連接數(shù)量過大的情況下，會增加端口號的占用時間,由于處于TIME_WAIT狀態(tài)的連接屬于關閉連接，所以新創(chuàng)建的連接可以復用該端口號
