微服務(wù)架構(gòu)之服務(wù)注冊與發(fā)現(xiàn)功能詳解
微服務(wù)的注冊與發(fā)現(xiàn)
我們前面在全景架構(gòu)中對服務(wù)注冊與發(fā)現(xiàn)做了大致的說明,本章我們著重詳細(xì)說明微服務(wù)下注冊與發(fā)現(xiàn)的這個(gè)能力。
微服務(wù)注冊與發(fā)現(xiàn)類似于生活中的"電話通訊錄"的概念,它記錄了通訊錄服務(wù)和電話的映射關(guān)系。在分布式架構(gòu)中,服務(wù)會注冊進(jìn)去,當(dāng)服務(wù)需要調(diào)用其它服務(wù)時(shí),就這里找到服務(wù)的地址,進(jìn)行調(diào)用。
步驟如下:
- 1、你先要把"好友某某"記錄在通訊錄中。
- 2、撥打電話的時(shí)候通過通訊錄中找到"好友某某",并撥通回電話。
- 3、當(dāng)好友某某電話號碼更新的時(shí)候,需要通知到你,并修改通訊錄服務(wù)中的號碼。
從這個(gè)過程中我們看到了一些特點(diǎn):
- 1、把 "好友某某" 的電話號碼寫入通訊錄中,統(tǒng)一在通訊錄中維護(hù),后續(xù)號碼變更也是更新到通訊錄中,這個(gè)過程就是服務(wù)注冊的過程。
- 2、后續(xù)我們通過"好友某某"就可以定位到通訊錄中的電話號碼,并撥通電話,這個(gè)過程理解為服務(wù)發(fā)現(xiàn)的過程。
而我們微服務(wù)架構(gòu)中的服務(wù)注冊與發(fā)現(xiàn)結(jié)構(gòu)如下圖所示:

圖片中是一個(gè)典型的微服務(wù)架構(gòu),這個(gè)結(jié)構(gòu)中主要涉及到三大角色:
- provider - 服務(wù)提供者
- consumer - 服務(wù)消費(fèi)者
- register center - 注冊中心
它們之間的關(guān)系大致如下:
- 1、每個(gè)微服務(wù)在啟動時(shí),將自己的網(wǎng)絡(luò)地址等信息(微服務(wù)的ServiceName、IP、Port、MetaData等)注冊到注冊中心,注冊中心存儲這些數(shù)據(jù)。
- 2、服務(wù)消費(fèi)者從注冊中心查詢服務(wù)提供者的地址,并通過該地址調(diào)用服務(wù)提供者的接口。
- 3、各個(gè)微服務(wù)與注冊中心使用一定機(jī)制(例如心跳)通信。如果注冊中心與某微服務(wù)長時(shí)間無法通信,就會注銷該實(shí)例。
優(yōu)點(diǎn)如下:
- 1、解耦:服務(wù)消費(fèi)者跟服務(wù)提供者解耦,各自變化,不互相影響
- 2、擴(kuò)展:服務(wù)消費(fèi)者和服務(wù)提供者增加和刪除新的服務(wù),對于雙方?jīng)]有任何影響
- 3、中介者設(shè)計(jì)模式:用一個(gè)中介對象來封裝一系列的對象交互,這是一種多對多關(guān)系的中介者模式。
從功能上拆開主要有三塊:服務(wù)注冊、服務(wù)發(fā)現(xiàn),和注冊中心。我們一個(gè)一個(gè)來看。
1、服務(wù)注冊
如圖中,為Register注冊中心注冊一個(gè)服務(wù)信息,會將服務(wù)的信息:ServiceName、IP、Port以及服務(wù)實(shí)例MetaData元數(shù)據(jù)信息寫入到注冊中心。當(dāng)服務(wù)發(fā)生變化的時(shí)候,也可以更新到注冊中心。

服務(wù)提供者(服務(wù)實(shí)例) 的服務(wù)注冊模型是一種簡單、容易理解、流行的服務(wù)注冊模型,其在多種技術(shù)生態(tài)中都有所體現(xiàn):
- 1、在K8S生態(tài)中,通過 K8S Service服務(wù)信息,和Pod的 endpoint(用來記錄service對應(yīng)的pod的訪問地址)來進(jìn)行注冊。
- 2、在Spring Cloud生態(tài)中,應(yīng)用名 對應(yīng) 服務(wù)Service,實(shí)例 IP + Port 對應(yīng) Instance實(shí)例。比較典型的就是A服務(wù),后面對應(yīng)有多個(gè)實(shí)例做負(fù)載均衡。
- 3、在其他的注冊組件中,比如 Eureka、Consul,服務(wù)模型也都是 服務(wù)→ 服務(wù)實(shí)例。
可以認(rèn)為服務(wù)實(shí)例是一個(gè)真正的實(shí)體的載體,服務(wù)是對這些相同能力或者相同功能服務(wù)實(shí)例的一個(gè)抽象。

2、服務(wù)發(fā)現(xiàn)
服務(wù)發(fā)現(xiàn)實(shí)際就是我們查詢已經(jīng)注冊好的服務(wù)提供者,比如 p->p.queryService(serviceName),通過服務(wù)名稱查詢某個(gè)服務(wù)是否存在,如果存在,
返回它的所有實(shí)例信息,即一組包含ip 、 port 、metadata元數(shù)據(jù)信息的endpoints信息。
這一組endpoints信息一般會被緩存在本地,如果注冊中心掛掉,可保證段時(shí)間內(nèi)依舊可用,這是去中心化的做法。對于單個(gè) Service 后面有多個(gè) Instance的情況(如上圖),做 load balance。
服務(wù)發(fā)現(xiàn)的方式一般有兩種:
1、拉取的方式:服務(wù)消費(fèi)方(Consumer)主動向注冊中心發(fā)起服務(wù)查詢的請求。
2、推送的方式:服務(wù)訂閱/通知變更(下發(fā)):服務(wù)消費(fèi)方(Consumer)主動向注冊中心訂閱某個(gè)服務(wù),當(dāng)注冊中心中該服務(wù)信息發(fā)生變更時(shí),注冊中心主動通知消費(fèi)者。
3、注冊中心
注冊中心提供的基本能力包括:提供服務(wù)注冊、服務(wù)發(fā)現(xiàn) 以及 健康檢查。
服務(wù)注冊跟服務(wù)發(fā)現(xiàn)上面已經(jīng)詳細(xì)介紹了, 健康檢查指的是指注冊中心能夠感知到微服務(wù)實(shí)例的健康狀況,便于上游微服務(wù)實(shí)例及時(shí)發(fā)現(xiàn)下游微服務(wù)實(shí)例的健康狀況。采取必備的訪問措施,如避免訪問不健康的實(shí)例。
主要的檢查方式包括:
- 1、服務(wù)Provider 進(jìn)行 TTL 健康匯報(bào)(Time To Live,微服務(wù)Provider定期向注冊中心匯報(bào)健康狀態(tài))。
- 2、注冊中心主動檢查服務(wù)Provider接口。
綜合我們前面的內(nèi)容,可以總結(jié)下注冊中心有如下幾種能力:
1、高可用
這個(gè)主要體現(xiàn)在兩個(gè)方面。一個(gè)方面是,注冊中心本身作為基礎(chǔ)設(shè)施層,具備高可用;第二種是就是前面我們說到的去中心化,極端情況下的故障,短時(shí)間內(nèi)是不影響微服務(wù)應(yīng)用的調(diào)用的
2、可視化操作
常用的注冊中心,類似 Eureka、Consul 都有比較豐富的管理界面,對配置、服務(wù)注冊、服務(wù)發(fā)現(xiàn)進(jìn)行可視化管理。
3、高效運(yùn)維
注冊中心的文檔豐富,對運(yùn)維的支持比較好,并且對于服務(wù)的注冊是動態(tài)感知獲取的,方便動態(tài)擴(kuò)容。
4、權(quán)限控制
數(shù)據(jù)是具有敏感性,無論是服務(wù)信息注冊或服務(wù)是調(diào)用,需要具備權(quán)限控制能力,避免侵入或越權(quán)請求
5、服務(wù)注冊推、拉能力
這個(gè)前面說過了,微服務(wù)應(yīng)用程序(服務(wù)的Consumer),能夠快速感知到服務(wù)實(shí)例的變化情況,使用拉取或者注冊中心下發(fā)的方式進(jìn)行處理。

4、現(xiàn)下的主流注冊中心
4.1 Eureka
4.1.1 介紹
Eureka是Netflix OSS套件中關(guān)于服務(wù)注冊和發(fā)現(xiàn)的解決方案。因?yàn)镾pring Cloud 在它的微服務(wù)解決方案中對Eureka進(jìn)行了集成,并作為優(yōu)先推薦方案進(jìn)行宣傳,所以早期有用 Spring Cloud 來建設(shè)微服務(wù)系統(tǒng)的同學(xué)會比較熟悉。
目前大量公司的微服務(wù)系統(tǒng)中依舊使用Eureka作為注冊中心,它的核心設(shè)計(jì)思想也被后續(xù)大量注冊中心產(chǎn)品借鑒。但目前 Eureka 2.0已經(jīng)停止維護(hù),所以新的微服務(wù)架構(gòu)設(shè)計(jì)中,不再建議使用。
Spring Cloud Netflix主要分為兩個(gè)部分:
1、Eureka Server: 作為注冊中心Server端,向微服務(wù)應(yīng)用程序提供服務(wù)注冊、發(fā)現(xiàn)、健康檢查等能力。
2、Eureka Client: 微服務(wù)應(yīng)用程序Client端,用以和Eureka Server進(jìn)行通信。

Eureka有比較友好的管理界面,如上圖所示:
1、System Status:顯示當(dāng)前Eureka Server信息。
2、Instances Current registered with Eureka:在Eureka Server當(dāng)前注冊的數(shù)據(jù),在Spring Cloud生態(tài)中,被注冊的服務(wù)可以唄發(fā)現(xiàn)并羅列在這個(gè)地方。
3、General Info:基本信息,如cpu、內(nèi)存、環(huán)境等。
4.1.2 整體架構(gòu)

Eureka Server可以運(yùn)行多個(gè)實(shí)例來構(gòu)建集群,解決單點(diǎn)問題,但不同于ZooKeeper的選舉leader的過程,Eureka Server采用的是Peer to Peer對等通信。
所以他有如下特點(diǎn):
- 1、去中心化的架構(gòu):無master/slave區(qū)分,每一個(gè)Peer都是對等的。在這種架構(gòu)中,節(jié)點(diǎn)通過彼此互相注冊來提高可用性,每個(gè)節(jié)點(diǎn)需要添加一個(gè)或多個(gè)有效的serviceUrl指向其他節(jié)點(diǎn)。每個(gè)節(jié)點(diǎn)都可被視為其他節(jié)點(diǎn)的副本。
- 2、故障轉(zhuǎn)移/故障恢復(fù):如果某臺Eureka Server宕機(jī),Eureka Client的請求會自動切換到新的Eureka Server節(jié)點(diǎn),當(dāng)宕機(jī)的服務(wù)器重新恢復(fù)后,Eureka會再次將其納入到服務(wù)器集群管理之中。
- 3、節(jié)點(diǎn)復(fù)制:當(dāng)節(jié)點(diǎn)開始接受客戶端請求時(shí),所有的操作都會進(jìn)行replicateToPeer(節(jié)點(diǎn)間復(fù)制)操作,將請求復(fù)制到其他Eureka Server當(dāng)前所知的所有節(jié)點(diǎn)中。
同理,一個(gè)新的Eureka Server節(jié)點(diǎn)啟動后,會首先嘗試從鄰近節(jié)點(diǎn)獲取所有實(shí)例注冊表信息,完成初始化。 - 4、CAP模式:復(fù)制算法非強(qiáng)一致性算法,而是當(dāng)有數(shù)據(jù)寫入時(shí),Eureka Server將數(shù)據(jù)同步給其他的節(jié)點(diǎn),因此Eureka在CAP提系統(tǒng)(一致性、可用性、分區(qū)容錯性)是典型的AP系統(tǒng)。
4.1.3 接入Spring Cloud

如上圖所示:
1、Provider 服務(wù)提供者:服務(wù)向注冊中心注冊服務(wù)信息,即 服務(wù) -> 服務(wù)實(shí)例 數(shù)據(jù)模型, 同時(shí)定時(shí)向注冊中心匯報(bào)健康檢查,如果一定時(shí)間內(nèi)(一般90s)沒有進(jìn)行心跳匯報(bào),則會被注冊中心剔除。
所以這邊注意,注冊中心感知到應(yīng)用下線并進(jìn)行剔除這個(gè)過程可能比較長。
2、Consumer 服務(wù)消費(fèi)者:服務(wù)向注冊中心獲取所需服務(wù)對應(yīng)的服務(wù)實(shí)例信息。這邊需要注意,Eureka不支持訂閱,因此在Spring Cloud生態(tài)中,通過定時(shí)拉取方式從注冊中心中獲取所需的服務(wù)實(shí)例信息。
3、Remote Call 遠(yuǎn)程調(diào)用:Consumer從注冊中心獲取的Provider的實(shí)例信息,通過 Load Balance的策略,確定一個(gè)實(shí)際的實(shí)例,發(fā)起遠(yuǎn)程調(diào)用。
4.2 ZooKeeper
4.2.1 介紹
作為一個(gè)分布式的、開源的協(xié)調(diào)服務(wù),ZooKeeper實(shí)現(xiàn)了一系列基礎(chǔ)功能,包括簡單易用的接口。
這些接口被用來實(shí)現(xiàn)服務(wù)的注冊與發(fā)現(xiàn)功能。并實(shí)現(xiàn)一些高級功能,如數(shù)據(jù)同步、分布式鎖、配置中心、集群選舉、命名服務(wù)等。

在數(shù)據(jù)模型上,類似于傳統(tǒng)的文件系統(tǒng),節(jié)點(diǎn)類型分為:
1、持久節(jié)點(diǎn):節(jié)點(diǎn)創(chuàng)建后,就一直存在,除非執(zhí)行刪除操作,主動刪掉這個(gè)節(jié)點(diǎn)。
2、臨時(shí)節(jié)點(diǎn)(注冊中心場景下的主要實(shí)現(xiàn)機(jī)制):臨時(shí)節(jié)點(diǎn)的生命周期和客戶端會話綁定。也就是說,如果客戶端會話失效,那么這個(gè)節(jié)點(diǎn)就會自動被清除掉。
在實(shí)際場景下,微服務(wù)啟動的時(shí)候,會創(chuàng)建一個(gè)服務(wù)臨時(shí)節(jié)點(diǎn),等把服務(wù)停止,短時(shí)間后節(jié)點(diǎn)就沒有了。

Zookeeper有如下特點(diǎn):
- 1、最終一致性:為客戶端展示同一視圖,這是zookeeper最重要的功能。
- 2、可靠性:如果消息被到一臺服務(wù)器接受,那么它將被所有的服務(wù)器接受。
- 3、實(shí)時(shí)性:Zookeeper不能保證兩個(gè)客戶端能同時(shí)得到剛更新的數(shù)據(jù),如果需要最新數(shù)據(jù),應(yīng)該在讀數(shù)據(jù)之前調(diào)用sync()接口。
- 4、等待無關(guān)(wait-free):慢的或者失效的client不干預(yù)快速的client的請求。
- 5、原子性:更新只能成功或者失敗,沒有中間狀態(tài)。
- 6、順序性:所有Server,同一消息發(fā)布順序一致。
4.2.2 整體架構(gòu)

上圖是Zookeeper 的服務(wù)架構(gòu),他有如下流程:
- 1、 多個(gè)節(jié)點(diǎn)組成分布式架構(gòu),每個(gè)Server在內(nèi)存中存儲一份數(shù)據(jù);
- 2、通過選舉產(chǎn)生leader,通過 Paxos(帕克索斯)強(qiáng)一致性算法 進(jìn)行保證,是典型的CP結(jié)構(gòu)。
- 3、Leader負(fù)責(zé)處理數(shù)據(jù)更新等操作(Zab協(xié)議);
4.2.3 接入Dubbo生態(tài)

上圖中的角色如下:
Provider:提供者,服務(wù)發(fā)布方
Consumer:消費(fèi)者, 調(diào)用服務(wù)方
Container:Dubbo容器.依賴于Spring容器
Registry:注冊中心,當(dāng)Container啟動時(shí)把所有可以提供的服務(wù)列表上Registry中進(jìn)行注冊,告訴Consumer提供了什么服務(wù),以及服務(wù)方的位置
Monitor:監(jiān)聽器
說明:ZooKeeper在注冊中心方面對Dubbo生態(tài)支持的比較好。服務(wù)提供者Providerzai Container啟動時(shí)主動向注冊中心Registry ZooKeeper中注冊信息。
服務(wù)消費(fèi)者Consumer啟動時(shí)向注冊中心Registry ZooKeeper中訂閱注冊中心,當(dāng)Provider的信息發(fā)生變化時(shí),注冊中心ZooKeeper會主動向Consumer進(jìn)行推送通知變更。
這邊注意與Eureka的區(qū)別,這是主動推送通知,是注冊中心下發(fā)的操作。
4.3 Consul
4.3.1 介紹
Consul是HashiCorp推出的一款軟件,是一個(gè)Service Mesh解決方案,提供了功能豐富的控制面功能:
1、Service Discovery(服務(wù)發(fā)現(xiàn))
2、Configuration(配置化)
3、Segmentation Functionality
這些功能可以根據(jù)需要獨(dú)立使用,或者將它們一起使用用來構(gòu)建完整的Service Mesh。
Consul提供的關(guān)鍵功能如下:
- 1、Service Discovery:服務(wù)注冊/發(fā)現(xiàn)功能。
- 2、Health Checking:健康檢查,豐富的健康檢查方式;
- 3、KV Store:KV存儲功能,可應(yīng)用多種場景,如動態(tài)配置存儲,分布式協(xié)調(diào)、leader選舉等。
- 4、Multi DataCenter:多數(shù)據(jù)中心。
4.3.2 整體架構(gòu)

如上圖為Consul的架構(gòu),這邊對技術(shù)點(diǎn)做一下說明:
1、Raft: 一種分布式一致性算法,Consul使用該算法報(bào)紙強(qiáng)一致性,所以也是典型的CP模式
2、Client:Client是一種agent,其將會重定向所有的RPC 請求到Server。Client是無狀態(tài)的,其主要參與LAN Gossip協(xié)議池。其占用很少的資源,并且消耗很少的網(wǎng)絡(luò)帶寬。
3、Server:Server是一種agent,其包含了一系列的責(zé)任包括:參與Raft協(xié)議寫半數(shù)(Raft Quorum)、維護(hù)集群狀態(tài)、響應(yīng)RPC響應(yīng)、和其他Datacenter通過WAN gossip交換信息和重定向查詢請求至leader或者遠(yuǎn)端Datacenter。
4、Datacenter: Datacenter其是私有的、低延遲、高帶寬的網(wǎng)絡(luò)環(huán)境,去除了在公共網(wǎng)絡(luò)上的網(wǎng)絡(luò)交互。
5、Consensus: Consensus一致性在leader 選舉、順序執(zhí)行transaction 上。當(dāng)這些事務(wù)已經(jīng)提交至有限狀態(tài)機(jī)(finite-state machine)中,Consul定義consensus作為復(fù)制狀態(tài)機(jī)的一致性。本質(zhì)上使用實(shí)現(xiàn)了Raft協(xié)議,對于具體實(shí)現(xiàn)細(xì)節(jié)可參考 Consensus Protocol。
6、Gossip:Consul使用了Serf,其提供了Gossip協(xié)議多種用途,Serf提供成員關(guān)系、失敗檢查和事件廣播。
7、LAN Gossip: Local Area Network Gossip其包含在同一個(gè)網(wǎng)絡(luò)環(huán)境或Datacenter的節(jié)點(diǎn)。
8、WAN Gossip: Wide Area Network Gossip 其只包含Server節(jié)點(diǎn),這些server分布在不同的datacenter中,其主要通過因特網(wǎng)或廣域網(wǎng)相互交流。
9、RPC: 遠(yuǎn)程過程調(diào)用,用于服務(wù)之間的通信。
10、CAP抉擇:在高可用方面,Consul使用Raft協(xié)議作為其分布式一致性協(xié)議,本身對故障節(jié)點(diǎn)有一定的容忍性,在單個(gè)DataCenter中Consul集群中節(jié)點(diǎn)的數(shù)量控制在2*n + 1個(gè)節(jié)點(diǎn),其中n為可容忍的宕機(jī)個(gè)數(shù),通常為3個(gè)節(jié)點(diǎn)。
所以是典型的CP模式。

根據(jù)Consul 的選舉機(jī)制和服務(wù)原理,我們有兩個(gè)注意點(diǎn) :
1、部署Consul Service 節(jié)點(diǎn)應(yīng)該奇數(shù)為宜,因?yàn)?1的偶數(shù)節(jié)點(diǎn)和奇數(shù)節(jié)點(diǎn)可容忍的故障數(shù)是一樣的,比如上圖3和4,另一方面,偶數(shù)個(gè)節(jié)點(diǎn)在選主節(jié)點(diǎn)的時(shí)候可能會出現(xiàn)二分選票的情況,還得重新選舉。
2、Consul Service 節(jié)點(diǎn)數(shù)不是越多越好,雖然Server數(shù)量越多可容忍的故障數(shù)越多,但是Raft進(jìn)行日志復(fù)制也是很耗時(shí)間的,而且Server數(shù)量越多,性能越低,所以結(jié)合實(shí)際場景,一般建議Server部署3個(gè)即可。
有興趣的同學(xué)可以去Consul官網(wǎng)看看它的選舉機(jī)制,還可以對比下Redis中Sentinel模式。
4.3.3 生態(tài)對接
對接Spring Cloud生態(tài)

Consul作為注冊中心,集成在Spring Cloud生態(tài)。可以看出,跟Eureka對接到Spring Cloud 生態(tài)的過程很像。
但是這邊的健康檢查更豐富,可以有多種不同的的Check方式:
- Script check(Script+ Interval)
- 基于HTTP請求
- 基于tcp請求
- 基于grpc請求
4.4 總結(jié)對比
4種注冊中心技術(shù)對比
| 指標(biāo) | Eureka | Zookeeper | Consul | Etcd |
| 一致性協(xié)議 | AP | CP(Paxos算法) | CP(Raft算法) | CP(Raft算法) |
| 健康檢查 | TTL(Time To Live) | TCP Keep Alive | TTL\HTTP\TCP\Script | Lease TTL KeepAlive |
| watch/long polling | 不支持 | watch | long polling | watch |
| 雪崩保護(hù) | 支持 | 不支持 | 不支持 | 不支持 |
| 安全與權(quán)限 | 不支持 | ACL | ACL | RBAC |
| 是否支持多數(shù)據(jù)中心 | 是 | 否 | 是 | 否 |
| 是否有管理界面 | 是 | 否(可用第三方ZkTools) | 是 | 否 |
| Spring Cloud 集成 | 支持 | 支持 | 支持 | 支持 |
| Dubbo 集成 | 不支持 | 支持 | 支持 | 不支持 |
| K8S 集成 | 不支持 | 不支持 | 支持 | 支持 |
這邊是對業(yè)內(nèi)4種注冊中心各緯度上的對比,Eureka是典型的AP類型,Zookeeper和Consul是典型的CP類型。如何選擇取決你的業(yè)務(wù)是傾向A:高可用性 還是 C:強(qiáng)一致性。
當(dāng)然,業(yè)務(wù)是復(fù)雜的,在真正的技術(shù)選型時(shí),還是要根據(jù)自己的實(shí)際業(yè)務(wù)現(xiàn)狀來判斷。有一些傾向,比如你的系統(tǒng)是Spring Cloud體系下,那優(yōu)先選擇Eureka、Consul。
如果業(yè)務(wù)會更多向云原生對齊,則Consul、Etcd會是比較優(yōu)先的選擇。
以上就是微服務(wù)架構(gòu)之服務(wù)注冊與發(fā)現(xiàn)功能詳解的詳細(xì)內(nèi)容,更多關(guān)于服務(wù)注冊與發(fā)現(xiàn)功能的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
windows系統(tǒng)搭建zookeeper服務(wù)器的教程
這篇文章主要介紹了windows系統(tǒng)搭建zookeeper服務(wù)器的教程,本文圖文并茂給大家介紹的非常詳細(xì),具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2019-10-10
SVN使用教程_動力節(jié)點(diǎn)Java學(xué)院整理
這篇文章主要為大家詳細(xì)介紹了SVN使用教程和注意事項(xiàng),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2017-08-08
Windows下搭建MQTT服務(wù)器的詳細(xì)教程
這篇文章主要介紹了Windows下搭建MQTT服務(wù)器的方法,基于mosquitto實(shí)現(xiàn),有需要的朋友可以參考下2023-08-08
ubuntu20.04部署ntp服務(wù)器ntpd(ntpdate?)的詳細(xì)過程
這篇文章主要介紹了ubuntu20.04部署ntp服務(wù)器ntpd(ntpdate?)的詳細(xì)過程,本文分步驟給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2023-09-09
用nginx+FastDFS一步步搭建文件管理系統(tǒng)
FastDFS 是一個(gè)開源的高性能分布式文件系統(tǒng)(DFS)。 它的主要功能包括:文件存儲,文件同步和文件訪問,以及高容量和負(fù)載平衡。主要解決了海量數(shù)據(jù)存儲問題,特別適合以中小文件(建議范圍:4KB < file_size <500MB)為載體的在線服務(wù)2020-10-10
web壓力測試工具_(dá)動力節(jié)點(diǎn)Java 學(xué)院整理
本文給大家分享幾個(gè)web 壓力測試工具,非常不錯,具有參考借鑒價(jià)值,需要的的朋友參考下吧2017-08-08

