👉🏻👉🏻👉🏻👉🏻上文：深造分布式 打敗面試官 招式二
👉🏻👉🏻👉🏻👉🏻分布式系列訂閱：分布式系列
👏🏻👏🏻👏🏻👏🏻：可關(guān)注 評論 及時交流反饋 不斷努力 一起加油 可留下你的👣
👉🏻👉🏻👉🏻👉🏻個人主頁： 個人主頁
👉🏻👉🏻👉🏻👉🏻個人介紹：開發(fā)小趴菜 拒絕加班的程序員 為了不加班 只能加油。頹廢又積極的矛盾體 😬

網(wǎng)絡(luò)通信：如何完成客戶端和服務(wù)端之間的高效通信？

• • 前言
  • • 網(wǎng)絡(luò)通信
    • 問題背景
    • 問題分析
  • 技術(shù)體系
  • • 網(wǎng)絡(luò)連接
    • IO 模型
    • 可靠性
    • 源碼解析
    • • Dubbo 服務(wù)器端通信原理
      • Dubbo 客戶端通信原理
  • 要點
  • • 小結(jié)
    • 結(jié)尾歌

前言

在上一文中，簡單的對構(gòu)建分布式服務(wù)所需要具備的技術(shù)組件進行了分析，并把這些技術(shù)組件分成三大類，即遠(yuǎn)程過程調(diào)用組件、微服務(wù)構(gòu)建組件以及通用技術(shù)組件 相信大家也會有一些get 到的地方 下面我們就要在進行細(xì)化的共同學(xué)習(xí) 一下 遠(yuǎn)程過程調(diào)用類組建的使用和討論 首先我們需要了解的是 網(wǎng)絡(luò)通信。

網(wǎng)絡(luò)通信

分布式系統(tǒng)的構(gòu)建依賴網(wǎng)絡(luò)通信。相比單塊系統(tǒng)的函數(shù)式調(diào)用，分布式環(huán)境下的請求和響應(yīng)過程涉及到客戶端和服務(wù)器端之間跨網(wǎng)絡(luò)的交互和協(xié)作。這個過程一方面要考慮到網(wǎng)絡(luò)的三特性（及時性、交互性、社交性），另一方面也需要考慮資源的利用效率。

那么，如何設(shè)計并實現(xiàn)高效的網(wǎng)絡(luò)通信機制？這是分布式服務(wù)框架的核心功能之一，也是我們進階的時候經(jīng)常遇到的問題。本文內(nèi)容將圍繞這一問題展開討論。

問題背景

在日常開發(fā)過程中，每一次分布式請求都會涉及到網(wǎng)絡(luò)通信。網(wǎng)絡(luò)通信表現(xiàn)為一個復(fù)雜且不可控的過程。然而，因為像 Dubbo、Spring Cloud 等主流的分布式服務(wù)框架都已經(jīng)幫我們封裝了網(wǎng)絡(luò)通信過程，使得遠(yuǎn)程過程調(diào)用就像是在使用本地方法調(diào)用一樣，導(dǎo)致了開發(fā)人員對網(wǎng)絡(luò)通信過程的底層設(shè)計思想和實現(xiàn)原理往往不甚了解, 這一點不知道大家有沒有感觸 有時候我們?nèi)ビ靡恍┨貏e便捷的框架 對于探究思想 就比較難 隨著技術(shù)的發(fā)展 我們所使用的技術(shù)也越來越成熟 但是不了解設(shè)計思想 就是底盤不穩(wěn)的。

另一方面，對于分布式服務(wù)構(gòu)建過程而言，網(wǎng)絡(luò)通信是一個基礎(chǔ)性、通用性的技術(shù)主題，涉及廣泛的技術(shù)體系，既有深度又有廣度，非常適合考查一個人的知識面

關(guān)于網(wǎng)絡(luò)通信有很多種具體的問法，有些側(cè)重于具體某一個知識點，有些則關(guān)注整個通信流程。當(dāng)然，因為日常開發(fā)中大家都是使用一些開源框架來開發(fā)分布式系統(tǒng)，因此關(guān)于開源框架中網(wǎng)絡(luò)通信具體實現(xiàn)過程和底層原理也是常見的考查方式。

這里我梳理了比較有代表性的一些話題，如下所示：

• 網(wǎng)絡(luò)的長連接和短連接分別指什么？它們分別有什么特點和優(yōu)勢？
• 常見網(wǎng)絡(luò) IO 模型有哪些？各有什么功能特性？
• 如果確保網(wǎng)絡(luò)通信過程的可靠性？
• 你認(rèn)為網(wǎng)絡(luò)通信包含的核心技術(shù)組件有哪些？
• 如果讓你來設(shè)計網(wǎng)絡(luò)傳輸協(xié)議，你有什么樣的一些思考？
• 你能描述 Dubbo 框架中客戶端和服務(wù)器端的網(wǎng)絡(luò)通信實現(xiàn)過程嗎？
• Dubbo 框架對網(wǎng)絡(luò)通信過程采用了什么樣的分層設(shè)計思想？

問題分析

網(wǎng)絡(luò)通信的實現(xiàn)方式實際上有很多種，但因為網(wǎng)絡(luò)通信過程復(fù)雜且不可控，因此如何使這個過程的代價降到用戶可以接受的層次是分布式系統(tǒng)設(shè)計的重要目標(biāo)。

我們知道客戶端和服務(wù)器端之間需要完成跨網(wǎng)絡(luò)的交互過程，也就意味著兩者之間需要建立網(wǎng)絡(luò)連接。網(wǎng)絡(luò)連接的創(chuàng)建和維護方式?jīng)Q定了通信過程的效率。同時，我們知道任何網(wǎng)絡(luò)請求的處理過程都涉及到 IO 操作，而不同類似的 IO 操作方式對性能的影響巨大。在網(wǎng)絡(luò)通信過程中，我們需要選擇合適的 IO 模型。

關(guān)于網(wǎng)絡(luò)通信，可靠性是一個不得不提的話題**。網(wǎng)絡(luò)狀態(tài)是不穩(wěn)定的，網(wǎng)絡(luò)之間的通信過程必須在發(fā)生問題時能夠快速感知并修復(fù)**。

我們把上述分析點整理成一張圖，如下所示：

上圖構(gòu)成啦這類問題的基本思路。

技術(shù)體系

在本文內(nèi)容中，讓我們來對上圖中所展示的各項技術(shù)體系展開討論。

網(wǎng)絡(luò)連接

關(guān)于網(wǎng)絡(luò)連接，我們要討論的主要是長連接和短連接的概念。當(dāng)客戶端在向服務(wù)端發(fā)送請求并獲取響應(yīng)結(jié)果之后，這兩種連接方式的區(qū)別在于對連接本身的處理方式。

所謂短連接，是指一旦請求響應(yīng)過程結(jié)束，連接自動關(guān)閉。

而長連接則不同，客戶端可以利用這個連接持續(xù)地發(fā)送請求并獲取響應(yīng)結(jié)果。

顯然，采用何種連接方式?jīng)]有統(tǒng)一的標(biāo)準(zhǔn)，而是要看具體的應(yīng)用場景。有時候，考慮到性能和服務(wù)治理等因素，我們也會把短連接和長連接組合起來使用。

IO 模型

任何網(wǎng)絡(luò)請求處理過程都涉及到 IO 操作。

最基本的 IO 操作模型就是阻塞式 IO（Blocking IO，BIO），該模型要求服務(wù)器端針對每次客戶端請求都生成一個處理線程，因此對服務(wù)器端的資源消耗要求很高。

非阻塞 IO（Non-Blocking IO，NIO）和 IO 復(fù)用（IO Multiplexing）技術(shù)實際上也會在 IO 上形成阻塞，真正在 IO 上沒有形成阻塞的是異步 IO（Asynchronous，AIO）。

各個 IO 模型效果如下圖所示：

可靠性

因為網(wǎng)絡(luò)狀態(tài)是不穩(wěn)定的，所以誕生了一系列手段來確保網(wǎng)絡(luò)通信的可靠性。

首先，我們需要對網(wǎng)絡(luò)的通信鏈路進行有效性的檢測，這方面最常見的實現(xiàn)機制就是心跳檢測。我們可以在網(wǎng)絡(luò)協(xié)議的 TCP 層發(fā)送心跳包，也可以在應(yīng)用層協(xié)議上傳遞包含一定業(yè)務(wù)數(shù)據(jù)的心跳信息。

另一方面，一旦檢測到網(wǎng)絡(luò)通信出現(xiàn)問題，那么就需要采取一定措施來恢復(fù)網(wǎng)絡(luò)狀態(tài)。這方面主流的做法就是斷線重連。針對不同場景，我們可以采用不同的重連次數(shù)和頻率，直到網(wǎng)絡(luò)重連成功或者超時。

看到這里，我們需要注意，上述關(guān)于網(wǎng)絡(luò)通信相關(guān)技術(shù)體系的討論都是相對抽象的內(nèi)容。我們還需要更加具體的依靠，就需要依托一定的開源框架。只有通過這些開源框架，我們才能了解網(wǎng)絡(luò)通信的底層原理。

在接下來的內(nèi)容中，我們將基于目前主流的分布式服務(wù)框架 Dubbo 來分析該框架針對網(wǎng)絡(luò)通信采用了什么樣的設(shè)計思想和實現(xiàn)過程。

源碼解析

在 Dubbo 框架中，存在一個獨立的 Remoting 模塊，封裝了對整個網(wǎng)絡(luò)通信的實現(xiàn)過程
Remoting :
在Remoting中是通過通道（channel）來實現(xiàn)兩個應(yīng)用程序和域之間對象的通信的。首先，客戶端通過Remoting，訪問通道以獲得服務(wù)端對象，再通過代理解析為客戶端對象。這就提供一種可能性，即以服務(wù)的方式來發(fā)布服務(wù)器對象。遠(yuǎn)程對象代碼可以運行在服務(wù)器上（如服務(wù)器激活的對象和客戶端激活的對象），然后客戶端再通過Remoting連接服務(wù)器，獲得該服務(wù)對象并通過序列化在客戶端運行。
在Remoting中，對于要傳遞的對象，設(shè)計者除了需要了解通道的類型和端口號之外，無需再了解數(shù)據(jù)包的格式。這既保證了客戶端和服務(wù)器端有關(guān)對象的松散耦合，同時也優(yōu)化了通信的性能。

該模塊的組成結(jié)構(gòu)如下圖所示：

從組成結(jié)構(gòu)上講，Remoting 模塊主要包含三個組件。

Exchange 組件。 信息交換層，用來封裝請求-響應(yīng)過程。
Transport 組件。 網(wǎng)絡(luò)傳輸層，基于 Netty 等框架抽象統(tǒng)一的網(wǎng)絡(luò)通信接口。
Serialize 組件。 序列化層，主要完成數(shù)據(jù)的序列化和反序列化過程。

而從技術(shù)分層上講，Remoting 模塊處于整個 Dubbo 框架的底層，是我們后續(xù)要介紹的服務(wù)發(fā)布和服務(wù)消費的基礎(chǔ)。顯然，Remoting 模塊的組件呈現(xiàn)的是一種對稱結(jié)構(gòu)，即 Dubbo 的生產(chǎn)者和消費者都依賴于底層的網(wǎng)絡(luò)通信。所以，我們也將分別從服務(wù)器端和客戶端兩個角度出發(fā)分析 Dubbo 中具體的網(wǎng)絡(luò)通信過程。

然后，在 Dubbo 中**，真正實現(xiàn)網(wǎng)絡(luò)通信的過程委托給了第三方組件。Dubbo 通過 SPI 的方式提供了與 Netty、Mina 等多種通信框架的集成方式。這部分內(nèi)容相當(dāng)于是對上圖中 Remoting 模塊的補充，從層次上講應(yīng)該屬于 Dubbo 框架的最底層**。

Dubbo 服務(wù)器端通信原理

我們首先介紹 Dubbo 服務(wù)器端的網(wǎng)絡(luò)通信過程。請記住，Dubbo 中服務(wù)器端通信的目的就是集成并綁定 Netty 服務(wù)從而啟動服務(wù)監(jiān)聽。我們關(guān)注 Exchange 信息交換層和 Transport 網(wǎng)絡(luò)傳輸層這兩個核心層之間的交互和協(xié)作過程，如下圖所示：

上圖中涉及了 ExchangeServer、HeaderExchange、NettyTransport 和 NettyServer 等一系列核心對象。顯然，通過這些對象從命名上就可以很明確地將它們劃分到 Exchange 和 Transport 這兩個層。

在 Dubbo 中存在一個 Protocol 接口，該接口是 Dubbo 中最基本的遠(yuǎn)程過程調(diào)用實現(xiàn)接口，完成了服務(wù)的發(fā)布和調(diào)用功能。而在 Protocol 接口中存在 export 和 refer 這兩個核心方法，其中前者用于對外暴露服務(wù)，后者則用來對遠(yuǎn)程服務(wù)進行引用。針對 Protocol 接口，Dubbo 提供了一組實現(xiàn)類，其中最重要的就是 DubboProtocol。

我們從 DubboProtocol 中的 export 方法進行切入，該方法會根據(jù)傳入的 URL 對象創(chuàng)建一個 Exchange 服務(wù)器，如下所示：

private void openServer(URL url) {String key = url.getAddress();boolean isServer = url.getParameter(Constants.IS_SERVER_KEY, true);if (isServer) {ExchangeServer server = serverMap.get(key);if (server == null) {serverMap.put(key, createServer(url));} else {server.reset(url);}} }

我們來看 Exchange 服務(wù)器的創(chuàng)建過程，對應(yīng)的 createServer 方法如下所示：

private ExchangeServer createServer(URL url) {// 省略其他代碼ExchangeServer server;try {server = Exchangers.bind(url, requestHandler);} return server; }

可以看到這里的關(guān)鍵代碼就是通過 Exchangers 的 bind 方法創(chuàng)建了 ExchangeServer，這個過程依賴于一個 Exchanger 接口。那么這個 Exchanger 接口是做什么用的呢？該接口定義如下所示：

@SPI(HeaderExchanger.NAME) public interface Exchanger {@Adaptive({Constants.EXCHANGER_KEY})ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException;@Adaptive({Constants.EXCHANGER_KEY})ExchangeClient connect(URL url, ExchangeHandler handler) throws RemotingException; }

Exchanger 接口只有兩個方法，一個是面向服務(wù)器端的 bind 方法，一個是面向客戶端的 connect 方法。在 Dubbo 中，Exchanger 的實現(xiàn)類只有一個，即 HeaderExchanger，如下所示：

public class HeaderExchanger implements Exchanger {public static final String NAME = "header";public ExchangeClient connect(URL url, ExchangeHandler handler) throws RemotingException {return new HeaderExchangeClient(Transporters.connect(url, new DecodeHandler(new HeaderExchangeHandler(handler))), true);}public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {return new HeaderExchangeServer(Transporters.bind(url, new DecodeHandler(new HeaderExchangeHandler(handler))));} }

請注意，上述 HeaderExchanger 在創(chuàng)建 HeaderExchangeServer 的同時也加入心跳檢測功能，如下所示：

private void startHeatbeatTimer() {stopHeartbeatTimer();if (heartbeat > 0) {heatbeatTimer = scheduled.scheduleWithFixedDelay(new HeartBeatTask(new HeartBeatTask.ChannelProvider() {public Collection<Channel> getChannels() {return Collections.unmodifiableCollection(HeaderExchangeServer.this.getChannels());}}, heartbeat, heartbeatTimeout),heartbeat, heartbeat, TimeUnit.MILLISECONDS);} }

在 HeartBeatTask 的 run 方法中，我們根據(jù)所配置的 heartbeat、heartbeatTimeout 等相關(guān)心跳屬性，執(zhí)行 channel.reconnect、channel.close 等方法。這也是心跳檢測機制的一種常見實現(xiàn)方式。

注意到，我們在 HeaderExchangeServer 中終于看到了屬于 Transport 層的對象 Transporters，接下來我們來看服務(wù)器端 Transport 相關(guān)的組件。

站在服務(wù)器的角度，網(wǎng)絡(luò)通信過程的目的只有一個，就是裝配服務(wù)并啟動監(jiān)聽，從而接收來自服務(wù)消費者的訪問。而對于服務(wù)消費者而言，通信過程的目的無非是對遠(yuǎn)程服務(wù)進行連接、發(fā)送請求并獲取響應(yīng)。因此，在 Dubbo 中存在一個 Transporter 接口，該接口提供了 bind 和 connect 方法分別對這兩個基本操作進行封裝，如下所示：

@SPI("netty") public interface Transporter {@Adaptive({Constants.SERVER_KEY, Constants.TRANSPORTER_KEY})Server bind(URL url, ChannelHandler handler) throws RemotingException;@Adaptive({Constants.CLIENT_KEY, Constants.TRANSPORTER_KEY})Client connect(URL url, ChannelHandler handler) throws RemotingException; }

我們發(fā)現(xiàn) Transporter 接口的定義與 Exchanger 接口非常類似，兩者同時提供了 bind 和 connect 這兩個方法。區(qū)別在于 Exchanger 中用到的 ExchangeHandler，而 Transporter 中用到的是 ChannelHandler，顯然 ChannelHandler 面向消息通信的通道，提供了比 ExchangeHandler 更底層的操作語義。

與 HeaderExchanger 不同，Dubbo 中針對 Transporter 接口提供了一批實現(xiàn)類，包括 GrizzlyTransporter、MinaTransporter 以及兩個 NettyTransporter。系統(tǒng)默認(rèn)會加載 org.apache.dubbo.remoting.transport.netty 包下的 NettyTransporter，該類如下所示：

public class NettyTransporter implements Transporter {public static final String NAME = "netty4";public Server bind(URL url, ChannelHandler listener) throws RemotingException {return new NettyServer(url, listener);}public Client connect(URL url, ChannelHandler listener) throws RemotingException {return new NettyClient(url, listener);} }

這里看到了真正實現(xiàn)網(wǎng)絡(luò)通信的 NettyServer 類，NettyServer 實現(xiàn)了 Server 接口并擴展了 AbstractServer 類。在 AbstractServer 中，Dubbo 提供了對網(wǎng)絡(luò)服務(wù)端的通用抽象，即抽象出 open、close、send 等一組面向網(wǎng)絡(luò)通信的通用方法。而 NettyServer 作為 AbstractServer 的子類，它的啟動監(jiān)聽實現(xiàn)代碼如下所示：

protected void doOpen() throws Throwable {...bootstrap = new ServerBootstrap(channelFactory);final NettyHandler nettyHandler = new NettyHandler(getUrl(), this);channels = nettyHandler.getChannels();bootstrap.setOption("child.tcpNoDelay", true);bootstrap.setPipelineFactory(new ChannelPipelineFactory() {public ChannelPipeline getPipeline() {NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyServer.this);ChannelPipeline pipeline = Channels.pipeline();pipeline.addLast("decoder", adapter.getDecoder());pipeline.addLast("encoder", adapter.getEncoder());pipeline.addLast("handler", nettyHandler);return pipeline;}});channel = bootstrap.bind(getBindAddress()); }

熟悉 Netty 框架的開發(fā)人員對上述代碼一定不會陌生，這里使用 Netty 的 ServerBootstrap 完成服務(wù)啟動監(jiān)聽，同時構(gòu)建了 NettyHandler 作為其網(wǎng)絡(luò)事件的處理器。然后 NettyServer 的 doClose 方法基于 Netty 的 boostrap 和 channel 對象完成了網(wǎng)絡(luò)資源釋放。

這樣我們對 Dubbo 中與網(wǎng)絡(luò)通信相關(guān)的服務(wù)監(jiān)聽啟動和關(guān)閉，以及發(fā)送消息的過程就有了整體的了解。

Dubbo 客戶端通信原理

有了對前面服務(wù)器端各個技術(shù)組件的介紹，理解 Dubbo 客戶端通信原理就會容易很多。我們在介紹服務(wù)器端時所引入的 Transporter 接口同時包含了對客戶端方法的定義，而 Transporter 的實現(xiàn)類 NettyTransporter 也同時提供了 NettyClient 類，如下所示：

public class NettyTransporter implements Transporter {public static final String NAME = "netty";public Server bind(URL url, ChannelHandler listener) throws RemotingException {return new NettyServer(url, listener);}public Client connect(URL url, ChannelHandler listener) throws RemotingException {return new NettyClient(url, listener);} }

與 NettyTransporter 相關(guān)的這些核心類之間的關(guān)系下圖所示：

上圖中的很多類我們都已經(jīng)明確了，因此在介紹 Dubbo 的客戶端通信原理時，不會像服務(wù)端那樣做全面展開，而是更多關(guān)注于客戶端本身的特性，所以我們的思路先從底層的 NettyClient 類進行切入。

與 NettyServer 類類似，NettyClient 也存在一個抽象的父類 AbstractClient。作為網(wǎng)絡(luò)客戶端的通用抽象，AbstractClient 這個模板類一共提供了 doOpen、doConnect、doDisconnect、doClose、getChannel 這 5 個模板方法。與服務(wù)器端所提供的 3 個方法相比，客戶端還需要實現(xiàn)與 Connect 這一操作相關(guān)的兩個方法。

NettyClient 中的 doOpen 方法如下所示，這里創(chuàng)建了 ClientBootstrap 并完成初始化參數(shù)設(shè)置。

@Override protected void doOpen() throws Throwable {...bootstrap = new ClientBootstrap(channelFactory); final NettyHandler nettyHandler = new NettyHandler(getUrl(), this);bootstrap.setPipelineFactory(new ChannelPipelineFactory() {public ChannelPipeline getPipeline() {NettyCodecAdapter adapter = new NettyCodecAdapter(getCodec(), getUrl(), NettyClient.this);ChannelPipeline pipeline = Channels.pipeline();pipeline.addLast("decoder", adapter.getDecoder());pipeline.addLast("encoder", adapter.getEncoder());pipeline.addLast("handler", nettyHandler);return pipeline;}}); }

和 NettyServer 一樣，NettyClient 同樣完成了對 Netty 框架的封裝。在 NettyClient 的 doConnect 方法中，同樣使用 ClientBootstrap 完成與服務(wù)端的連接和事件監(jiān)聽。而 doDisconnect 方法則用于移除當(dāng)前已經(jīng)斷開連接的 Channel。然后，和 HeaderExchangeServer 類類似，在 HeaderExchangeClient 類中也添加了定時心跳收發(fā)及心跳超時監(jiān)測機制。

要點

對于遠(yuǎn)程過程調(diào)用而言，網(wǎng)絡(luò)通信還是一個偏向于概念的技術(shù)。因此，了解這類型的知識，第一步需要針對網(wǎng)絡(luò)通信這個話題本身給出一些說明和描述，這屬于理論知識體系，是需要死記硬背的基礎(chǔ)內(nèi)容。基于對這一話題的了解，通常我們就可以引出一些自己比較熟悉的點，圍繞這些點來進行展開和引導(dǎo)即可。例如，對于網(wǎng)絡(luò)傳輸協(xié)議，如果你了解 ISO/OSI 模型，那就可以基于這個模型來對類似“消息頭”這種自己比較熟悉的點進行發(fā)散。

第二個要點是對網(wǎng)絡(luò)通信實現(xiàn)過程進行抽象化、系統(tǒng)化的闡述。在目前主流的分布式服務(wù)框架中，對于網(wǎng)絡(luò)通信模塊都會有自己的一些抽象和提煉，其內(nèi)部結(jié)構(gòu)往往比較復(fù)雜。以本講中介紹的 Dubbo 框架為例，就采用了明確的分層架構(gòu)。每一層中都包含了一些核心的接口，這些接口之間的繼承關(guān)系以及所處于的層次如下圖所示：

針對網(wǎng)絡(luò)通信，我們要明確 Dubbo 框架集成了很多第三方工具，這部分工具只關(guān)注于底層的具體網(wǎng)絡(luò)通信過程。Dubbo 把這一過程抽象成一個 Transport 層，即網(wǎng)絡(luò)傳輸層。而 Dubbo 又提供了一個 Exchange 層，用于封裝請求和響應(yīng)，稱為信息交換層。從功能職責(zé)上講，Exchange 偏向于 Dubbo 對自身通信過程的抽象和封裝，跟具體的網(wǎng)絡(luò)通信關(guān)系不大，具體的網(wǎng)絡(luò)傳輸工作都是由 Transport 層負(fù)責(zé)完成。理解 Dubbo 框架的這種設(shè)計思想和實現(xiàn)方式，一方面有助于提升面試內(nèi)容的豐富程度，另一方面對于更好地理解框架實現(xiàn)原理也很有幫助。

小結(jié)

本講介紹了分布式系統(tǒng)遠(yuǎn)程過程調(diào)用部分的第一個技術(shù)組件，即網(wǎng)絡(luò)通信?？梢哉f網(wǎng)絡(luò)通信是一切分布式系統(tǒng)的基礎(chǔ)，我們從網(wǎng)絡(luò)連接、IO 模型等角度討論了與網(wǎng)絡(luò)通信相關(guān)的一些基本概念。

結(jié)尾歌

我喚醒大海
喚醒山脈
我喚醒沙漠
處處充滿色彩
美麗的地方
開心往前飛
就算有億萬公里
一噸行李
我們不放棄
前進需要勇氣
一直往前飛
最重要開心就好
忘記煩惱宇宙很大
任飛翔
滿載歡樂
回航
闖一闖
讓我們闖一闖
我們志氣要比天還高
云啊
輕輕飄過來
夢中輪廓一點點透露出來
飛吧飛吧
飛過黎明和夜晚
啦啦啦啦
風(fēng)啊
輕輕吹過來
夢想翅膀流星天空中劃過
穿越時空
回到那夢想的地方

總結(jié)

以上是生活随笔為你收集整理的深造分布式 打败面试官 招式三 直捣黄龙的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。