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