自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

要給Nacos的Udp通信功能點(diǎn)個(gè)贊

作者：二師兄
網(wǎng)絡(luò) 通信技術(shù)
Nacos在服務(wù)注冊功能中使用到了UDP的通信方式，主要功能就是用來輔助服務(wù)實(shí)例變化時(shí)對客戶端進(jìn)行通知。然而，對于大多數(shù)使用Nacos的程序員來說，可能還不知道這個(gè)功能，更別說靈活運(yùn)用了。

[[421857]]

本文轉(zhuǎn)載自微信公眾號「程序新視界」，作者二師兄。轉(zhuǎn)載本文請聯(lián)系程序新視界公眾號。

學(xué)習(xí)不用那么功利，二師兄帶你從更高維度輕松閱讀源碼～

Nacos在服務(wù)注冊功能中使用到了UDP的通信方式，主要功能就是用來輔助服務(wù)實(shí)例變化時(shí)對客戶端進(jìn)行通知。然而，對于大多數(shù)使用Nacos的程序員來說，可能還不知道這個(gè)功能，更別說靈活運(yùn)用了。

看完整個(gè)源碼的實(shí)現(xiàn)，還是要為這一功能點(diǎn)個(gè)贊的，可以說非常巧妙和實(shí)用。但在實(shí)現(xiàn)上有一些不足，文末會進(jìn)行指出。

本篇文章就帶大家從源碼層面來分析一下Nacos 2.0中是如何基于UDP協(xié)議來實(shí)現(xiàn)服務(wù)實(shí)例變更的通知。

UDP通知基本原理

在分析源碼之前，先來從整體上看一下Nacos中UDP的實(shí)現(xiàn)原理。

Nacos UDP基本原理

我們知道，UDP協(xié)議通信是雙向的，沒有所謂的客戶端和服務(wù)端，因此在客戶端和服務(wù)器端都會開啟UDP的監(jiān)聽。客戶端是單獨(dú)開啟一個(gè)線程來處理UDP消息的。當(dāng)采用HTTP協(xié)議與注冊中心通信時(shí)，，在客戶端調(diào)用服務(wù)訂閱接口時(shí)，會將客戶端的UPD信息(IP和端口)上送到注冊中心，注冊中心以PushClient對象來進(jìn)行封裝和存儲。

當(dāng)注冊中心有實(shí)例變化時(shí)，會發(fā)布一個(gè)ServiceChangeEvent事件，注冊中心監(jiān)聽到這個(gè)事件之后，會遍歷存儲的PushClient，基于UDP協(xié)議對客戶端進(jìn)行通知?？蛻舳私邮盏経DP通知，即可更新本地緩存的實(shí)例列表。

前面我們已經(jīng)知道，基于HTTP協(xié)議進(jìn)行服務(wù)注冊時(shí)，會有一個(gè)實(shí)例更新的時(shí)間差，因?yàn)槭峭ㄟ^客戶端定時(shí)拉取服務(wù)器中的實(shí)例列表。如果拉取太頻繁，注冊中心壓力比較大，如果拉取的周期比較長，實(shí)例的變化又沒辦法快速感知到。而UDP協(xié)議的通知，恰恰彌補(bǔ)了這一缺點(diǎn)，所以說，要為基于UDP通知這個(gè)功能點(diǎn)個(gè)贊。

下面就來看看源碼層面是如何實(shí)現(xiàn)的。

客戶端UDP通知監(jiān)聽與處理

客戶端在實(shí)例化NamingHttpClientProxy時(shí)，在其構(gòu)造方法中會初始化PushReceiver。

  1. public NamingHttpClientProxy(String namespaceId, SecurityProxy securityProxy, ServerListManager serverListManager, 
  2.         Properties properties, ServiceInfoHolder serviceInfoHolder) { 
  3.     // ... 
  4.     // 構(gòu)建BeatReactor 
  5.     this.beatReactor = new BeatReactor(this, properties); 
  6.     // 構(gòu)建UDP端口監(jiān)聽 
  7.     this.pushReceiver = new PushReceiver(serviceInfoHolder); 
  8.     // ... 
  9. } 

PushReceiver的構(gòu)造方法，如下：

  1. public PushReceiver(ServiceInfoHolder serviceInfoHolder) { 
  2.     try { 
  3.         // 持有ServiceInfoHolder引用 
  4.         this.serviceInfoHolder = serviceInfoHolder; 
  5.         // 獲取UDP端口 
  6.         String udpPort = getPushReceiverUdpPort(); 
  7.         // 根據(jù)端口情況，構(gòu)建DatagramSocket，如果未設(shè)置端口，則采用隨機(jī)端口 
  8.         if (StringUtils.isEmpty(udpPort)) { 
  9.             this.udpSocket = new DatagramSocket(); 
  10.         } else { 
  11.             this.udpSocket = new DatagramSocket(new InetSocketAddress(Integer.parseInt(udpPort))); 
  12.         } 
  13.         // 創(chuàng)建只有一個(gè)線程的ScheduledExecutorService 
  14.         this.executorService = new ScheduledThreadPoolExecutor(1, new ThreadFactory() { 
  15.             @Override 
  16.             public Thread newThread(Runnable r) { 
  17.                 Thread thread = new Thread(r); 
  18.                 thread.setDaemon(true); 
  19.                 thread.setName("com.alibaba.nacos.naming.push.receiver"); 
  20.                 return thread; 
  21.             } 
  22.         }); 
  23.  
  24.         // 執(zhí)行線程，PushReceiver實(shí)現(xiàn)了Runnable接口 
  25.         this.executorService.execute(this); 
  26.     } catch (Exception e) { 
  27.         NAMING_LOGGER.error("[NA] init udp socket failed", e); 
  28.     } 
  29. } 

PushReceiver的構(gòu)造方法做了以下操作：

  • 第一、持有ServiceInfoHolder對象引用;
  • 第二、獲取UDP端口;
  • 第三、實(shí)例化DatagramSocket對象，用于發(fā)送和接收Socket數(shù)據(jù);
  • 第四，創(chuàng)建線程池，并執(zhí)行PushReceiver(實(shí)現(xiàn)了Runnable接口);

既然PushReceiver實(shí)現(xiàn)了Runnable接口，run方法肯定是需要重新實(shí)現(xiàn)的：

  1. @Override 
  2. public void run() { 
  3.     while (!closed) { 
  4.         try { 
  5.              
  6.             // byte[] is initialized with 0 full filled by default 
  7.             byte[] buffer = new byte[UDP_MSS]; 
  8.             // 創(chuàng)建DatagramPacket用于存儲接收到的報(bào)文 
  9.             DatagramPacket packet = new DatagramPacket(buffer, buffer.length); 
  10.             // 接收報(bào)文，在未接收到報(bào)文時(shí)會進(jìn)行線程阻塞 
  11.             udpSocket.receive(packet); 
  12.             // 將報(bào)文轉(zhuǎn)換為json格式 
  13.             String json = new String(IoUtils.tryDecompress(packet.getData()), UTF_8).trim(); 
  14.             NAMING_LOGGER.info("received push data: " + json + " from " + packet.getAddress().toString()); 
  15.             // 將json格式的報(bào)文轉(zhuǎn)換為PushPacket對象 
  16.             PushPacket pushPacket = JacksonUtils.toObj(json, PushPacket.class); 
  17.             String ack; 
  18.             // 如果符合條件，則調(diào)用ServiceInfoHolder進(jìn)行接收報(bào)文處理，并返回應(yīng)答報(bào)文 
  19.             if (PUSH_PACKAGE_TYPE_DOM.equals(pushPacket.type) || PUSH_PACKAGE_TYPE_SERVICE.equals(pushPacket.type)) { 
  20.                 serviceInfoHolder.processServiceInfo(pushPacket.data); 
  21.                  
  22.                 // send ack to server 
  23.                 ack = "{\"type\": \"push-ack\"" + ", \"lastRefTime\":\"" + pushPacket.lastRefTime + "\", \"data\":" 
  24.                         + "\"\"}"; 
  25.             } else if (PUSH_PACKAGE_TYPE_DUMP.equals(pushPacket.type)) { 
  26.                 // dump data to server 
  27.                 ack = "{\"type\": \"dump-ack\"" + ", \"lastRefTime\": \"" + pushPacket.lastRefTime + "\", \"data\":" 
  28.                         + "\"" + StringUtils.escapeJavaScript(JacksonUtils.toJson(serviceInfoHolder.getServiceInfoMap())) 
  29.                         + "\"}"; 
  30.             } else { 
  31.                 // do nothing send ack only 
  32.                 ack = "{\"type\": \"unknown-ack\"" + ", \"lastRefTime\":\"" + pushPacket.lastRefTime 
  33.                         + "\", \"data\":" + "\"\"}"; 
  34.             } 
  35.             // 發(fā)送應(yīng)答報(bào)文 
  36.             udpSocket.send(new DatagramPacket(ack.getBytes(UTF_8), ack.getBytes(UTF_8).length, 
  37.                     packet.getSocketAddress())); 
  38.         } catch (Exception e) { 
  39.             if (closed) { 
  40.                 return; 
  41.             } 
  42.             NAMING_LOGGER.error("[NA] error while receiving push data", e); 
  43.         } 
  44.     } 
  45. } 

PushReceiver#run方法主要處理了以下操作：

  • 第一、構(gòu)建DatagramPacket用于接收報(bào)文數(shù)據(jù);
  • 第二、通過DatagramSocket#receive方法阻塞等待報(bào)文的到來;
  • 第三、DatagramSocket#receive接收到報(bào)文之后，方法繼續(xù)執(zhí)行;
  • 第四、解析JSON格式的報(bào)文為PushPacket對象;
  • 第五、判斷報(bào)文類型，調(diào)用ServiceInfoHolder#processServiceInfo處理接收到的報(bào)文信息，在該方法中會將PushPacket轉(zhuǎn)化為ServiceInfo對象;
  • 第六、封裝ACK信息(即應(yīng)答報(bào)文信息);
  • 第七、通過DatagramSocket發(fā)送應(yīng)答報(bào)文;

上面我們看到了Nacos客戶端是如何基于UDP進(jìn)行報(bào)文的監(jiān)聽和處理的，但并未找到客戶端是如何將UDP信息上送給注冊中心的。下面我們就來梳理一下，上送UDP信息的邏輯。

客戶端上送UDP信息

在NamingHttpClientProxy中存儲了UDP_PORT_PARAM，即UDP的端口參數(shù)信息。

UDP端口信息通過實(shí)例查詢類接口進(jìn)行傳遞，比如：查詢實(shí)例列表、查詢單個(gè)健康實(shí)例、查詢所有實(shí)例、訂閱接口、訂閱的更新任務(wù)UpdateTask等接口。在這些方法中都調(diào)用了NamingClientProxy#queryInstancesOfService方法。

NamingHttpClientProxy中的queryInstancesOfService方法實(shí)現(xiàn)：

  1. @Override 
  2. public ServiceInfo queryInstancesOfService(String serviceName, String groupName, String clusters, int udpPort, 
  3.         boolean healthyOnly) throws NacosException { 
  4.     final Map<String, String> params = new HashMap<String, String>(8); 
  5.     params.put(CommonParams.NAMESPACE_ID, namespaceId); 
  6.     params.put(CommonParams.SERVICE_NAME, NamingUtils.getGroupedName(serviceName, groupName)); 
  7.     params.put(CLUSTERS_PARAM, clusters); 
  8.     // 獲取UDP端口 
  9.     params.put(UDP_PORT_PARAM, String.valueOf(udpPort)); 
  10.     params.put(CLIENT_IP_PARAM, NetUtils.localIP()); 
  11.     params.put(HEALTHY_ONLY_PARAM, String.valueOf(healthyOnly)); 
  12.     String result = reqApi(UtilAndComs.nacosUrlBase + "/instance/list", params, HttpMethod.GET); 
  13.     if (StringUtils.isNotEmpty(result)) { 
  14.         return JacksonUtils.toObj(result, ServiceInfo.class); 
  15.     } 
  16.     return new ServiceInfo(NamingUtils.getGroupedName(serviceName, groupName), clusters); 
  17. } 

但查看源碼會發(fā)現(xiàn)，查詢實(shí)例列表、查詢單個(gè)健康實(shí)例、查詢所有實(shí)例、訂閱的更新任務(wù)UpdateTask中，UDP端口傳遞的參數(shù)值均為0。只有HTTP協(xié)議的訂閱接口取值為PushReceiver中的UDP端口號。

  1. @Override 
  2. public ServiceInfo subscribe(String serviceName, String groupName, String clusters) throws NacosException { 
  3.     return queryInstancesOfService(serviceName, groupName, clusters, pushReceiver.getUdpPort(), false); 
  4. } 

在上面的代碼中我們已經(jīng)知道PushReceiver中有一個(gè)getPushReceiverUdpPort的方法：

  1. public static String getPushReceiverUdpPort() { 
  2.     return System.getenv(PropertyKeyConst.PUSH_RECEIVER_UDP_PORT); 
  3. } 

很明顯，UDP的端口是通過環(huán)境變量設(shè)置的，對應(yīng)的key為“push.receiver.udp.port”。

而在1.4.2版本中，HostReactor中的NamingProxy成員變量的queryList方法也會傳遞UDP端口：

  1. public void updateService(String serviceName, String clusters) throws NacosException { 
  2.     ServiceInfo oldService = getServiceInfo0(serviceName, clusters); 
  3.     try { 
  4.         String result = serverProxy.queryList(serviceName, clusters, pushReceiver.getUdpPort(), false); 
  5.         if (StringUtils.isNotEmpty(result)) { 
  6.             processServiceJson(result); 
  7.         } 
  8.     } finally { 
  9.         // ... 
  10.     } 
  11. } 

關(guān)于1.4.2版本中的實(shí)現(xiàn)，大家自行看源碼即可，這里不再展開。

完成了客戶端UDP基本信息的傳遞，再來看看服務(wù)器端是如何接收和存儲這些信息的。

UDP服務(wù)存儲

服務(wù)器端在獲取實(shí)例列表的接口中，對UDP端口進(jìn)行了處理。

  1. @GetMapping("/list") 
  2. @Secured(parser = NamingResourceParser.class, action = ActionTypes.READ) 
  3. public Object list(HttpServletRequest request) throws Exception { 
  4.     // ... 
  5.     // 如果沒有獲得UDP端口信息，則默認(rèn)端口為0 
  6.     int udpPort = Integer.parseInt(WebUtils.optional(request, "udpPort", "0")); 
  7.     // ... 
  8.     // 客戶端的IP、UDP端口封裝到Subscriber對象中 
  9.     Subscriber subscriber = new Subscriber(clientIP + ":" + udpPort, agent, app, clientIP, namespaceId, serviceName, 
  10.             udpPort, clusters); 
  11.     return getInstanceOperator().listInstance(namespaceId, serviceName, subscriber, clusters, healthyOnly); 
  12. } 

在getInstanceOperator()方法中會獲得當(dāng)前采用的哪個(gè)協(xié)議，然后選擇對應(yīng)的處理類：

  1. /** 
  2.  * 判斷并返回采用V1版本或V2版本的操作服務(wù) 
  3.  * @return V1：Jraft協(xié)議（服務(wù)器端）；V2：gRpc協(xié)議（客戶端） 
  4.  */ 
  5. private InstanceOperator getInstanceOperator() { 
  6.     return upgradeJudgement.isUseGrpcFeatures() ? instanceServiceV2 : instanceServiceV1; 
  7. } 

這里具體的實(shí)現(xiàn)類為InstanceOperatorServiceImpl：

  1. @Override 
  2. public ServiceInfo listInstance(String namespaceId, String serviceName, Subscriber subscriber, String cluster, 
  3.         boolean healthOnly) throws Exception { 
  4.     ClientInfo clientInfo = new ClientInfo(subscriber.getAgent()); 
  5.     String clientIP = subscriber.getIp(); 
  6.     ServiceInfo result = new ServiceInfo(serviceName, cluster); 
  7.     Service service = serviceManager.getService(namespaceId, serviceName); 
  8.     long cacheMillis = switchDomain.getDefaultCacheMillis(); 
  9.     // now try to enable the push 
  10.     try { 
  11.         // 處理支持UDP協(xié)議的客戶端信息 
  12.         if (subscriber.getPort() > 0 && pushService.canEnablePush(subscriber.getAgent())) { 
  13.             subscriberServiceV1.addClient(namespaceId, serviceName, cluster, subscriber.getAgent(), 
  14.                     new InetSocketAddress(clientIP, subscriber.getPort()), pushDataSource, StringUtils.EMPTY, 
  15.                     StringUtils.EMPTY); 
  16.             cacheMillis = switchDomain.getPushCacheMillis(serviceName); 
  17.         } 
  18.     } catch (Exception e) { 
  19.         // ... 
  20.     } 
  21.     // ... 
  22. } 

當(dāng)UDP端口大于0，且agent參數(shù)定義的客戶端支持UDP，則將對應(yīng)的客戶端信息封裝到InetSocketAddress對象中，然后放入NamingSubscriberServiceV1Impl中(該類已經(jīng)被廢棄，看后續(xù)如何調(diào)整該方法實(shí)現(xiàn))。

在NamingSubscriberServiceV1Impl中，會將對應(yīng)的參數(shù)封裝為PushClient，存放在Map當(dāng)中。

  1. public void addClient(String namespaceId, String serviceName, String clusters, String agent, 
  2.         InetSocketAddress socketAddr, DataSource dataSource, String tenant, String app) { 
  3.      
  4.     PushClient client = new PushClient(namespaceId, serviceName, clusters, agent, socketAddr, dataSource, tenant, 
  5.             app); 
  6.     addClient(client); 
  7. } 

addClient方法會將PushClient信息存放到ConcurrentMap

  1. private final ConcurrentMap<String, ConcurrentMap<String, PushClient>> clientMap = new ConcurrentHashMap<>(); 
  2.  
  3. public void addClient(PushClient client) { 
  4.         // client is stored by key 'serviceName' because notify event is driven by serviceName change 
  5.         String serviceKey = UtilsAndCommons.assembleFullServiceName(client.getNamespaceId(), client.getServiceName()); 
  6.         ConcurrentMap<String, PushClient> clients = clientMap.get(serviceKey); 
  7.         if (clients == null) { 
  8.             clientMap.putIfAbsent(serviceKey, new ConcurrentHashMap<>(1024)); 
  9.             clients = clientMap.get(serviceKey); 
  10.         } 
  11.          
  12.         PushClient oldClient = clients.get(client.toString()); 
  13.         if (oldClient != null) { 
  14.             oldClient.refresh(); 
  15.         } else { 
  16.             PushClient res = clients.putIfAbsent(client.toString(), client); 
  17.            // ... 
  18.         } 
  19.     } 

此時(shí)，UDP的IP、端口信息已經(jīng)封裝到PushClient當(dāng)中，并存儲在NamingSubscriberServiceV1Impl的成員變量當(dāng)中。

注冊中心的UDP通知

當(dāng)服務(wù)端發(fā)現(xiàn)某個(gè)實(shí)例發(fā)生了變化，比如主動注銷了，會發(fā)布一個(gè)ServiceChangeEvent事件，UdpPushService會監(jiān)聽到該事件，并進(jìn)行業(yè)務(wù)處理。

在UdpPushService的onApplicationEvent方法中，會根據(jù)PushClient的具體情況進(jìn)行移除或發(fā)送UDP通知。onApplicationEvent中核心邏輯代碼如下：

  1. ConcurrentMap<String, PushClient> clients = subscriberServiceV1.getClientMap() 
  2.         .get(UtilsAndCommons.assembleFullServiceName(namespaceId, serviceName)); 
  3. if (MapUtils.isEmpty(clients)) { 
  4.     return; 
  5. } 
  6.  
  7. Map<String, Object> cache = new HashMap<>(16); 
  8. long lastRefTime = System.nanoTime(); 
  9. for (PushClient client : clients.values()) { 
  10.     // 移除僵尸客戶端 
  11.     if (client.zombie()) { 
  12.         Loggers.PUSH.debug("client is zombie: " + client); 
  13.         clients.remove(client.toString()); 
  14.         Loggers.PUSH.debug("client is zombie: " + client); 
  15.         continue; 
  16.     } 
  17.      
  18.     AckEntry ackEntry; 
  19.     String key = getPushCacheKey(serviceName, client.getIp(), client.getAgent()); 
  20.     byte[] compressData = null; 
  21.     Map<String, Object> data = null; 
  22.     if (switchDomain.getDefaultPushCacheMillis() >= 20000 && cache.containsKey(key)) { 
  23.         org.javatuples.Pair pair = (org.javatuples.Pair) cache.get(key); 
  24.         compressData = (byte[]) (pair.getValue0()); 
  25.         data = (Map<String, Object>) pair.getValue1(); 
  26.     } 
  27.      
  28.     // 封裝AckEntry對象 
  29.     if (compressData != null) { 
  30.         ackEntry = prepareAckEntry(client, compressData, data, lastRefTime); 
  31.     } else { 
  32.         ackEntry = prepareAckEntry(client, prepareHostsData(client), lastRefTime); 
  33.         if (ackEntry != null) { 
  34.             cache.put(key, new org.javatuples.Pair<>(ackEntry.getOrigin().getData(), ackEntry.getData())); 
  35.         } 
  36.     } 
  37.     // 通過UDP通知其他客戶端 
  38.     udpPush(ackEntry); 
  39. } 

事件處理的核心邏輯是就是先判斷PushClient的狀態(tài)信息，如果已經(jīng)是僵尸客戶端，則移除。然后將發(fā)送UDP的報(bào)文信息和接收客戶端的信息封裝為AckEntry對象，然后調(diào)用udpPush方法，進(jìn)行UDP消息的發(fā)送。

注冊中心的UDP接收

在看客戶端源碼的時(shí)候，我們看到客戶端不僅會接收UDP請求，而且還會進(jìn)行應(yīng)答。那么注冊中心怎么接收應(yīng)答呢?也在UdpPushService類中，該類內(nèi)部的靜態(tài)代碼塊初始化一個(gè)UDP的DatagramSocket，用來接收消息：

  1. static { 
  2.     try { 
  3.         udpSocket = new DatagramSocket(); 
  4.         Receiver receiver = new Receiver(); 
  5.         Thread inThread = new Thread(receiver); 
  6.         inThread.setDaemon(true); 
  7.         inThread.setName("com.alibaba.nacos.naming.push.receiver"); 
  8.         inThread.start(); 
  9.     } catch (SocketException e) { 
  10.         Loggers.SRV_LOG.error("[NACOS-PUSH] failed to init push service"); 
  11.     } 
  12. } 

Receiver是一個(gè)內(nèi)部類，實(shí)現(xiàn)了Runnable接口，在其run方法中主要就是接收報(bào)文信息，然后進(jìn)行報(bào)文消息的判斷，根據(jù)判斷結(jié)果，操作本地Map中數(shù)據(jù)。

UDP設(shè)計(jì)不足

文章最開始就寫到，UDP的設(shè)計(jì)非常棒，即彌補(bǔ)了HTTP定時(shí)拉取的不足，又不至于太影響性能。但目前Nacos在UDP方面有一些不足，也可能是個(gè)人的吹毛求疵吧。

第一，文檔中沒有明確說明UDP的功能如何使用，這導(dǎo)致很多使用者在使用時(shí)并不知道UDP功能的存在，以及使用的限制條件。

第二，對云服務(wù)不友好?？蛻舳说腢DP端口可以自定義，但服務(wù)器端的UDP端口是隨機(jī)獲取到。在云服務(wù)中，即便是內(nèi)網(wǎng)服務(wù)，UDP端口也是被防火墻限制的。如果服務(wù)端的UDP端口是隨機(jī)獲取(客戶端默認(rèn)也是)，那么UDP的通信將直接被防火墻攔截掉，而用戶根本看不到任何異常(UDP協(xié)議不關(guān)注客戶端是否收到消息)。

至于這兩點(diǎn)，說起來算是瑕不掩瑜，讀完源碼或讀過我這篇文章的朋友大概已經(jīng)知道怎么用了。后續(xù)可以給官方提一個(gè)Issue，看看是否可以改進(jìn)。

小結(jié)

本文重點(diǎn)從三個(gè)方面講解的Nacos基于UDP的服務(wù)實(shí)例變更通知：

第一，客戶端監(jiān)聽UDP端口，當(dāng)接收注冊中心發(fā)來的服務(wù)實(shí)例變化，可以及時(shí)的更新本地的實(shí)例緩存;

第二，客戶端通過訂閱接口，將自身的UDP信息發(fā)送給注冊中心，注冊中心進(jìn)行存儲;

第三，注冊中心中實(shí)例發(fā)生了變化，通過事件機(jī)制，將變更信息通過UDP協(xié)議發(fā)送給客戶端。

 

經(jīng)過本篇文章，想必你不僅了解了Nacos中UDP協(xié)議的通知機(jī)制。同時(shí)，也開拓了一個(gè)新的思路，即如何使用UDP，在什么場景下使用UDP，以及在云服務(wù)中使用UDP可能會存在的問題。如果這篇文章對你有幫助，關(guān)注或點(diǎn)贊都可以。

 

責(zé)任編輯：武曉燕 來源： 程序新視界
NacosUdp通信
相關(guān)推薦

2016-12-02 15:23:42

銳捷互聯(lián)網(wǎng)技術(shù)核心交換機(jī)

2010-06-21 17:51:50

UDP協(xié)議

2010-07-06 15:10:05

UDP協(xié)議

2021-02-04 07:54:40

JS工具擴(kuò)展運(yùn)算符

2014-09-16 17:00:02

UDP

2022-02-08 15:37:22

微軟Windows 11

2023-03-01 08:15:10

NginxNacos

2020-08-03 08:10:52

UDPTCP通信

2020-05-11 17:00:30

點(diǎn)贊MySQLRedis

2010-06-09 14:36:44

TCP與UDP協(xié)議

2022-04-29 14:51:22

iOS蘋果電池

2020-07-02 16:40:40

MySQLRedis數(shù)據(jù)庫

2023-10-17 17:13:14

內(nèi)存程序源碼

2010-06-09 14:42:21

UDP協(xié)議TCP協(xié)議

2025-04-07 00:55:00

RustUDP編程

2022-11-27 08:08:42

2010-06-09 11:38:37

傳輸層通信協(xié)議

2024-10-10 17:27:12

2020-01-10 15:15:53

Redis點(diǎn)贊數(shù)據(jù)庫

2015-08-24 10:31:14

Windows 10功能
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號