[[277794]]

 服務(wù)框架的核心

1. 大型服務(wù)框架的核心：RPC通信
2. 微服務(wù)的核心是遠(yuǎn)程通信和服務(wù)治理

• 遠(yuǎn)程通信提供了服務(wù)之間通信的橋梁，服務(wù)治理提供了服務(wù)的后勤保障

服務(wù)的拆分增加了通信的成本，因此遠(yuǎn)程通信很容易成為系統(tǒng)瓶頸

• 在滿足一定的服務(wù)治理需求的前提下，對(duì)遠(yuǎn)程通信的性能需求是技術(shù)選型的主要影響因素

很多微服務(wù)框架中的服務(wù)通信是基于RPC通信實(shí)現(xiàn)的

• 在沒(méi)有進(jìn)行組件擴(kuò)展的前提下，Spring Cloud是基于Feign組件實(shí)現(xiàn)RPC通信(基于HTTP+JSON序列化)
• Dubbo是基于SPI擴(kuò)展了很多RPC通信框架，包括RMI、Dubbo、Hessian等(默認(rèn)為Dubbo+Hessian序列化)

性能測(cè)試

基于Dubbo:2.6.4，單一TCP長(zhǎng)連接+Protobuf(響應(yīng)時(shí)間和吞吐量更優(yōu))，短連接的HTTP+JSON序列化

RPC通信

架構(gòu)演化

無(wú)論是微服務(wù)、SOA、還是RPC架構(gòu)，都是分布式服務(wù)架構(gòu)，都需要實(shí)現(xiàn)服務(wù)之間的互相通信，通常把這種通信統(tǒng)稱(chēng)為RPC通信

概念

1. RPC：Remote Process Call，遠(yuǎn)程服務(wù)調(diào)用，通過(guò)網(wǎng)絡(luò)請(qǐng)求遠(yuǎn)程計(jì)算機(jī)程序服務(wù)的通信技術(shù)
2. RPC框架封裝了底層網(wǎng)絡(luò)通信和序列化等技術(shù)
3. 只需要在項(xiàng)目中引入各個(gè)服務(wù)的接口包，就可以在代碼中調(diào)用RPC服務(wù)(如同調(diào)用本地方法一樣)

RMI

1. RMI：Remote Method Invocation
2. RMI是JDK自帶的RPC通信框架，已經(jīng)成熟地應(yīng)用于EJB和Spring，是純Java網(wǎng)絡(luò)分布式應(yīng)用系統(tǒng)的核心解決方案
3. RMI實(shí)現(xiàn)了一臺(tái)虛擬機(jī)應(yīng)用對(duì)遠(yuǎn)程方法的調(diào)用可以同對(duì)本地方法調(diào)用一樣，RMI封裝好了遠(yuǎn)程通信的具體細(xì)節(jié)

實(shí)現(xiàn)原理

RMI遠(yuǎn)程代理對(duì)象是RMI中最核心的組件，除了對(duì)象本身所在的虛擬機(jī)，其他虛擬機(jī)也可以調(diào)用此對(duì)象的方法

這些虛擬機(jī)可以分布在不同的主機(jī)上，通過(guò)遠(yuǎn)程代理對(duì)象，遠(yuǎn)程應(yīng)用可以用網(wǎng)絡(luò)協(xié)議和服務(wù)進(jìn)行通信

高并發(fā)下的性能瓶頸

Java默認(rèn)序列化

RMI的序列化方式采用的是Java默認(rèn)序列化，性能不好，而且不支持跨語(yǔ)言

TCP短連接

RMI是基于TCP短連接實(shí)現(xiàn)的，在高并發(fā)情況下，大量請(qǐng)求會(huì)帶來(lái)大量TCP連接的創(chuàng)建和銷(xiāo)毀，非常消耗性能

阻塞式網(wǎng)絡(luò)IO

Socket編程中使用傳統(tǒng)的IO模型，在高并發(fā)場(chǎng)景下基于短連接實(shí)現(xiàn)的網(wǎng)絡(luò)通信就很容易產(chǎn)生IO阻塞，性能將大打折扣

優(yōu)化路徑

TCP / UDP

網(wǎng)絡(luò)傳輸協(xié)議有TCP和UDP，兩個(gè)協(xié)議都是基于Socket編程

基于TCP協(xié)議實(shí)現(xiàn)的Socket通信是有連接的

傳輸數(shù)據(jù)要通過(guò)三次握手來(lái)實(shí)現(xiàn)數(shù)據(jù)傳輸?shù)目煽啃裕鴤鬏敂?shù)據(jù)是沒(méi)有邊界的，采用的是字節(jié)流模式

基于UDP協(xié)議實(shí)現(xiàn)的Socket通信，客戶(hù)端不需要建立連接，只需要?jiǎng)?chuàng)建一個(gè)套接字發(fā)送數(shù)據(jù)給服務(wù)端

基于UDP協(xié)議實(shí)現(xiàn)的Socket通信具有不可靠性

UDP發(fā)送的數(shù)據(jù)采用的是數(shù)據(jù)報(bào)模式，每個(gè)UDP的數(shù)據(jù)報(bào)都有一個(gè)長(zhǎng)度，該長(zhǎng)度與數(shù)據(jù)一起發(fā)送到服務(wù)端

為了保證數(shù)據(jù)傳輸?shù)目煽啃裕ǔＧ闆r下會(huì)采用TCP協(xié)議

在局域網(wǎng)且對(duì)數(shù)據(jù)傳輸?shù)目煽啃詻](méi)有要求的情況下，可以考慮使用UDP協(xié)議，UDP協(xié)議的效率比TCP協(xié)議高

長(zhǎng)連接

服務(wù)之間的通信不同于客戶(hù)端與服務(wù)端之間的通信

由于客戶(hù)端數(shù)量眾多，基于短連接實(shí)現(xiàn)請(qǐng)求，可以避免長(zhǎng)時(shí)間地占用連接，導(dǎo)致系統(tǒng)資源浪費(fèi)

服務(wù)之間的通信，連接的消費(fèi)端不會(huì)像客戶(hù)端那么多，但消費(fèi)端向服務(wù)端請(qǐng)求的數(shù)量卻一樣多

基于長(zhǎng)連接實(shí)現(xiàn)，可以省去大量建立TCP連接和關(guān)閉TCP連接的操作，從而減少系統(tǒng)的性能消耗，節(jié)省時(shí)間

優(yōu)化Socket通信

傳統(tǒng)的Socket通信主要存在IO阻塞，線程模型缺陷以及內(nèi)存拷貝等問(wèn)題，Netty4對(duì)Socket通信編程做了很多方面的優(yōu)化

實(shí)現(xiàn)非阻塞IO：多路復(fù)用器Selector實(shí)現(xiàn)了非阻塞IO通信

高效的Reactor線程模型

Netty使用了主從Reactor多線程模型

主線程：用于客戶(hù)端的連接請(qǐng)求操作，一旦連接建立成功，將會(huì)監(jiān)聽(tīng)I(yíng)O事件，監(jiān)聽(tīng)到事件后會(huì)創(chuàng)建一個(gè)鏈路請(qǐng)求

鏈路請(qǐng)求將會(huì)注冊(cè)到負(fù)責(zé)IO操作的IO工作線程上，由IO工作線程負(fù)責(zé)后續(xù)的IO操作

Reactor線程模型解決了在高并發(fā)的情況下，由于單個(gè)NIO線程無(wú)法監(jiān)聽(tīng)海量客戶(hù)端和滿足大量IO操作造成的問(wèn)題

4.串行設(shè)計(jì)

服務(wù)端在接收消息之后，存在著編碼、解碼、讀取和發(fā)送等鏈路操作

如果這些操作基于并行實(shí)現(xiàn)，無(wú)疑會(huì)導(dǎo)致嚴(yán)重的鎖競(jìng)爭(zhēng)，進(jìn)而導(dǎo)致系統(tǒng)的性能下降

為了提升性能，Netty采用串行無(wú)鎖化完成鏈路操作，提供了Pipeline，實(shí)現(xiàn)鏈路的各個(gè)操作在運(yùn)行期間不會(huì)切換線程

5.零拷貝

數(shù)據(jù)從內(nèi)存發(fā)到網(wǎng)絡(luò)中，存在兩次拷貝，先是從用戶(hù)空間拷貝到內(nèi)核空間，再?gòu)膬?nèi)核空間拷貝到網(wǎng)絡(luò)IO

NIO提供的ByteBuffer可以使用Direct Buffer模式

直接開(kāi)辟一個(gè)非堆物理內(nèi)存，不需要進(jìn)行字節(jié)緩沖區(qū)的二次拷貝，可以直接將數(shù)據(jù)寫(xiě)入到內(nèi)核空間

6.優(yōu)化TCP參數(shù)配置，提高網(wǎng)絡(luò)吞吐量，Netty可以基于ChannelOption來(lái)設(shè)置

• TCP_NODELAY：用于控制是否開(kāi)啟Nagle算法
• Nagle算法通過(guò)緩存的方式將小的數(shù)據(jù)包組成一個(gè)大的數(shù)據(jù)包，從而避免大量發(fā)送小的數(shù)據(jù)包，導(dǎo)致網(wǎng)絡(luò)阻塞
• 在對(duì)時(shí)延敏感的應(yīng)用場(chǎng)景，可以選擇關(guān)閉該算法
• SO_RCVBUF / SO_SNDBUF：Socket接收緩沖區(qū)和發(fā)送緩沖區(qū)的大小
• SO_BACKLOG：指定客戶(hù)端連接請(qǐng)求緩沖隊(duì)列的大小
• 服務(wù)端處理客戶(hù)端連接請(qǐng)求是按順序處理的，同一時(shí)間只能處理一個(gè)客戶(hù)端連接
• 當(dāng)有多個(gè)客戶(hù)端進(jìn)來(lái)的時(shí)候，服務(wù)端將不能處理的客戶(hù)端連接請(qǐng)求放在隊(duì)列中等待處理
• SO_KEEPALIVE
• 連接會(huì)檢查長(zhǎng)時(shí)間沒(méi)有發(fā)送數(shù)據(jù)的客戶(hù)端的連接狀態(tài)，檢測(cè)到客戶(hù)端斷開(kāi)連接后，服務(wù)端將回收該連接
• 將該值設(shè)置得小一些，可以提高回收連接的效率

定制報(bào)文格式

設(shè)計(jì)一套報(bào)文，用于描述具體的校驗(yàn)、操作、傳輸數(shù)據(jù)等內(nèi)容

為了提高傳輸效率，可以根據(jù)實(shí)際情況來(lái)設(shè)計(jì)，盡量實(shí)現(xiàn)報(bào)體小，滿足功能，易解析等特性

字段長(zhǎng)度(字節(jié))備注魔數(shù)4協(xié)議的標(biāo)識(shí)，類(lèi)似于字節(jié)碼的魔數(shù)，通常為固定數(shù)字版本號(hào)1序列化算法1Protobuf / Thrift指令1類(lèi)似于HTTP中的增刪改查數(shù)據(jù)長(zhǎng)度4數(shù)據(jù)N

編解碼

實(shí)現(xiàn)一個(gè)通信協(xié)議，需要兼容優(yōu)秀的序列化框架

如果只是單純的數(shù)據(jù)對(duì)象傳輸，可以選擇性能相對(duì)較好的Protobuf序列化，有利于提高網(wǎng)絡(luò)通信的性能

Linux的TCP參數(shù)設(shè)置

三次握手

四次揮手

配置項(xiàng)

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默認(rèn)單個(gè)進(jìn)程可以打開(kāi)的文件數(shù)量上限為1024，Socket也是文件

2.與Netty的SO_KEEPALIVE配置項(xiàng)的作用一致

3.SYN隊(duì)列的長(zhǎng)度，加大隊(duì)列長(zhǎng)度，可以容納更多等待連接的網(wǎng)絡(luò)連接數(shù)

4.客戶(hù)端連接服務(wù)器時(shí)，需要?jiǎng)討B(tài)分配源端口號(hào)，該配置項(xiàng)表示向外連接的端口范圍

5. 當(dāng)一個(gè)連接關(guān)閉時(shí)，TCP會(huì)通過(guò)四次揮手來(lái)完成一次關(guān)閉連接操作，在請(qǐng)求量比較大的情況下，消費(fèi)端會(huì)有大量TIME_WAIT狀態(tài)的連接,該參數(shù)可以限制TIME_WAIT狀態(tài)的連接數(shù)量，如果TIME_WAIT的連接數(shù)量超過(guò)該值，TIME_WAIT將會(huì)立即被清除掉并打印警告信息

6.客戶(hù)端每次連接服務(wù)器時(shí)，都會(huì)獲得一個(gè)新的源端口以實(shí)現(xiàn)連接的唯一性，在TIME_WAIT狀態(tài)的連接數(shù)量過(guò)大的情況下，會(huì)增加端口號(hào)的占用時(shí)間,由于處于TIME_WAIT狀態(tài)的連接屬于關(guān)閉連接，所以新創(chuàng)建的連接可以復(fù)用該端口號(hào)