国产精品久久久久激情影院,自拍偷拍综合网,成人福利在线免费观看

微服務(wù)現(xiàn)在是一個(gè)很火的話題，好像不管項(xiàng)目的大小，適用范圍都在往微服務(wù)上去靠。這也使得現(xiàn)在如果不會(huì)微服務(wù)出去都沒法和別人聊了。

僅從我自己的工作經(jīng)歷來(lái)看，盡管我們的項(xiàng)目也是微服務(wù)化了的。但是說(shuō)實(shí)話在業(yè)務(wù)開發(fā)過程中并沒有體會(huì)到微服務(wù)的開發(fā)和單體項(xiàng)目開發(fā)中存在很大的區(qū)別(僅業(yè)務(wù)開發(fā)這一塊來(lái)說(shuō))。

微服務(wù)的學(xué)習(xí)單獨(dú)的寫幾個(gè)demo并沒有啥用，現(xiàn)在的框架封裝程度都很高，就算是代碼跑起來(lái)來(lái)依舊是云里霧里。微服務(wù)的學(xué)習(xí)更多的是搞清楚微服務(wù)中每一個(gè)組件到底是什么？為什么有這些組件？沒有會(huì)怎么樣？功能大概是怎么實(shí)現(xiàn)的？

搞清楚來(lái)這些基本上就可以說(shuō)對(duì)微服務(wù)有個(gè)大體的掌握了。

為什么需要注冊(cè)中心

在微服務(wù)中首先需要面對(duì)的問題就是不同的服務(wù)之間如何進(jìn)行通信呢？在單體服務(wù)中如果不同的服務(wù)之間需要通信，一般就是服務(wù)將接口暴露，然后其他的服務(wù)通過http進(jìn)行請(qǐng)求，那么很明顯在微服務(wù)中也可以這樣。

但這里存在的問題在于單體服務(wù)中我們需要請(qǐng)求的目標(biāo)是我們?cè)谡?qǐng)求的url中直接寫死的，因?yàn)榉?wù)不多可以這樣。而微服務(wù)中需要考慮的是存在大量服務(wù)時(shí)手動(dòng)維護(hù)服務(wù)列表是否合適？如果服務(wù)橫向擴(kuò)展時(shí)如何通知其他的服務(wù)？服務(wù)宕機(jī)后，如何及時(shí)下線等等問題。

注冊(cè)中心的功能

注冊(cè)中心的存在是為了更好更方便的管理應(yīng)用中的每一個(gè)服務(wù)，是各個(gè)分布式節(jié)點(diǎn)之間的紐帶。注冊(cè)中心主要提供以下核心功能：

服務(wù)注冊(cè)與發(fā)現(xiàn)：動(dòng)態(tài)的增減服務(wù)節(jié)點(diǎn)，服務(wù)節(jié)點(diǎn)增減后動(dòng)態(tài)的通知服務(wù)消費(fèi)者，而不需要由消費(fèi)者來(lái)更新配置。
服務(wù)配置：動(dòng)態(tài)修改服務(wù)配置，并將其推送到服務(wù)提供者和服務(wù)消費(fèi)者而不需要重啟服務(wù)。
健康檢查和服務(wù)摘除：主動(dòng)的檢查服務(wù)健康情況，對(duì)于宕機(jī)的服務(wù)將其摘除服務(wù)列表。

注冊(cè)中心的實(shí)現(xiàn)

注冊(cè)中心的主要功能就是保存服務(wù)的具體信息，然后由服務(wù)消費(fèi)者讀取這些信息。從整體的流程上來(lái)說(shuō)大概就是這樣：

除了將服務(wù)注冊(cè)到注冊(cè)中心，實(shí)際還存在服務(wù)的反注冊(cè)。

目前對(duì)注冊(cè)中心的實(shí)現(xiàn)分為兩種模式，分別為客戶端(應(yīng)用內(nèi)注冊(cè))和服務(wù)端(應(yīng)用外注冊(cè))。

客戶端注冊(cè)中心

目前客戶端實(shí)現(xiàn)的注冊(cè)中心比較有代表性的就是eureka，雖然eureka2.0版本在此前宣布閉源，但目前好像沒有太大的影響。后續(xù)的話可以考慮阿里開源的nacos。

eureka是一個(gè)基于JAVA語(yǔ)言實(shí)現(xiàn)的費(fèi)用與服務(wù)發(fā)現(xiàn)與注冊(cè)的組件，包含服務(wù)端和客戶端兩部分。

服務(wù)端主要用來(lái)存儲(chǔ)服務(wù)信息，定時(shí)進(jìn)行服務(wù)檢查。而客戶端用于完成向服務(wù)端注冊(cè)服務(wù)信息以及從服務(wù)端拉取服務(wù)信息等。

上圖是eureka官給出的eureka的架構(gòu)圖。

從圖中可以很明顯的看到eureka的服務(wù)端也是作為一個(gè)服務(wù)部署，而客戶端則是通過sdk的方式接入應(yīng)用。客戶端向服務(wù)端進(jìn)行服務(wù)注冊(cè)以及更新服務(wù)等，同時(shí)客戶端從服務(wù)端獲取服務(wù)信息，不同服務(wù)之間根據(jù)獲得的服務(wù)信息進(jìn)行遠(yuǎn)程調(diào)用。

為了滿足服務(wù)的高可用，通過移動(dòng)多個(gè)eureka server服務(wù)，不同eureka server相互注冊(cè)實(shí)現(xiàn)服務(wù)的高可用。

服務(wù)端注冊(cè)中心

eureka是由注冊(cè)中心提供服務(wù)端和客戶端的SDK，業(yè)務(wù)端通過引入注冊(cè)中心提供的SDK，來(lái)實(shí)現(xiàn)服務(wù)的注冊(cè)和發(fā)現(xiàn)。而服務(wù)端的注冊(cè)中心則是通過應(yīng)用外的組件來(lái)實(shí)現(xiàn)服務(wù)注冊(cè)功能的。目前用的比較多的服務(wù)端注冊(cè)中心組件如zookeeper、consul等。這里以zookeeper為例。

Zookeeper 是 Apache Hadoop 的子項(xiàng)目，是一個(gè)樹型的目錄服務(wù)，支持變更推送，適合作為 Dubbo 服務(wù)的注冊(cè)中心，工業(yè)強(qiáng)度較高，可用于生產(chǎn)環(huán)境，是目前Dubbo官方主推搭配的注冊(cè)中心。

上圖是dubbo官網(wǎng)提供的zookeeper作為注冊(cè)中心的基本原理。

以dubbo為根目錄，創(chuàng)建一服務(wù)接口全限定名的目錄，在其下創(chuàng)建存放服務(wù)提供者接口信息的providers目錄、存放服務(wù)消費(fèi)者接口信息的consumers目錄、存放服務(wù)配置信息的configurators目錄等。

服務(wù)提供者啟動(dòng)的時(shí)候在providers下創(chuàng)建一條服務(wù)信息，該信息可以被consumer獲取。通過zk提供的watcher機(jī)制注冊(cè)一個(gè)watcher在服務(wù)提供者的providers目錄下，這樣當(dāng)服務(wù)出現(xiàn)擴(kuò)容或者宕機(jī)的時(shí)候就可以立即被consumer消費(fèi)。

注冊(cè)中心的問題

在微服務(wù)中，注冊(cè)中心作為一個(gè)存儲(chǔ)所有服務(wù)中心的地方必然不可能是單機(jī)的。因?yàn)槿绻?cè)中心無(wú)法使用，那么服務(wù)提供者就無(wú)法對(duì)外暴露自己的服務(wù)，消費(fèi)者也無(wú)法獲取自己需要調(diào)用的服務(wù)的具體地址，整個(gè)應(yīng)用將會(huì)崩潰。首先需要保證的就是注冊(cè)中心的高可用。

一致性和可用性的抉擇

說(shuō)到高可用，CAP理論是繞不過去的，CAP簡(jiǎn)單來(lái)說(shuō)就是我們需要在服務(wù)的可用性和服務(wù)間的一致性進(jìn)行一個(gè)抉擇。是犧牲可用性來(lái)保證強(qiáng)一致性還是保證可用性犧牲強(qiáng)一致性呢？

CP類型注冊(cè)中心

Zookeeper是一個(gè)典型的CP類型的高可用組件。zookeeper實(shí)現(xiàn)來(lái)paxos算法，zookeeper集群有一個(gè)節(jié)點(diǎn)作為leader，如果leader節(jié)點(diǎn)掛了zk會(huì)通過ZAB協(xié)議來(lái)進(jìn)行l(wèi)eader選舉，但是在選舉的過程中zk是不能對(duì)外提供服務(wù)的。

而且當(dāng)因?yàn)榫W(wǎng)絡(luò)分區(qū)導(dǎo)致zk集群出現(xiàn)腦裂問題時(shí)，由于ZAB協(xié)議需要半數(shù)以上的節(jié)點(diǎn)參與，所以可能會(huì)有部分或者全部的zk節(jié)點(diǎn)無(wú)法對(duì)外提供服務(wù)。但是zk可以保證所有可用節(jié)點(diǎn)都數(shù)據(jù)都是一致，即使節(jié)點(diǎn)崩潰，在恢復(fù)后也會(huì)和其他節(jié)點(diǎn)保持一致，這就是zk犧牲了可用性而保證的強(qiáng)一致性。

AP類型注冊(cè)中心

而類似與eureka的注冊(cè)中心則是AP類型的。eureka實(shí)現(xiàn)高可用是通過啟動(dòng)多個(gè)eureka server服務(wù)，每一個(gè)eureka server即是提供者也是消費(fèi)者，每個(gè)eureka server將自己作為服務(wù)注冊(cè)給其他的eureka server，這樣每個(gè)eureka server都是其他server 的replica。eureka這種模式中每個(gè)節(jié)點(diǎn)都是平等的，不存在leader、flower。

當(dāng)集群中某一個(gè)server節(jié)點(diǎn)宕機(jī)，請(qǐng)求可以直接轉(zhuǎn)移到其他節(jié)點(diǎn)。即使發(fā)生了網(wǎng)絡(luò)分區(qū)，盡管不同分區(qū)之間無(wú)法進(jìn)行通信，但是在每一個(gè)分區(qū)內(nèi)的節(jié)點(diǎn)是通信并且可以正常對(duì)外提供服務(wù)，這樣就保證了在server節(jié)點(diǎn)宕機(jī)的情況下的注冊(cè)中心的可用性。

而問題在于由于不同分區(qū)無(wú)法通信，就導(dǎo)致可能一部分節(jié)點(diǎn)的數(shù)據(jù)和另一部分有差別，這就是犧牲了強(qiáng)一致性來(lái)?yè)Q取系統(tǒng)可用性。

注冊(cè)中心的選擇

首先我們應(yīng)該明確的是其實(shí)注冊(cè)中心的存在與否應(yīng)該是不能直接影響服務(wù)的調(diào)用的。服務(wù)之間的調(diào)用時(shí)通過http或者rpc等協(xié)議直接調(diào)用的，注冊(cè)中心只是提供一個(gè)調(diào)用地址。服務(wù)是否可以正常使用不能直接靠注冊(cè)中心節(jié)點(diǎn)信息來(lái)決定。

即使注冊(cè)中心出現(xiàn)問題，只要服務(wù)本身沒有宕機(jī)，理論上來(lái)說(shuō)還是應(yīng)該正常對(duì)外提供服務(wù)。所以很明顯對(duì)于我們來(lái)說(shuō)AP類型的注冊(cè)中心是要優(yōu)于CP類型的注冊(cè)中心的。

當(dāng)然在實(shí)際實(shí)現(xiàn)過程中很多框架都會(huì)盡可能的去修補(bǔ)這些問題，比如eureka會(huì)定時(shí)的同步各個(gè)節(jié)點(diǎn)的數(shù)據(jù)，盡可能的做到數(shù)據(jù)一致性。dubbo的zk注冊(cè)中心實(shí)現(xiàn)過程中也會(huì)本地緩存服務(wù)信息并不是完全通過zk信息來(lái)決定是否剔除服務(wù)等。所以實(shí)際在選擇時(shí)還是需要根據(jù)自身實(shí)際以及是否還有其他需求來(lái)確定。

混合語(yǔ)言開發(fā)

在微服務(wù)中，每一個(gè)服務(wù)都是一個(gè)獨(dú)立的整體。各個(gè)服務(wù)之間并不向單體應(yīng)用中的不同模塊大都要求是同一語(yǔ)言實(shí)現(xiàn)。現(xiàn)如今各大公司開發(fā)語(yǔ)言是多樣化的，不同的業(yè)務(wù)線開發(fā)的語(yǔ)言可能都不盡相同，混合語(yǔ)言是我們必須要面對(duì)的一個(gè)問題，所以出現(xiàn)了多語(yǔ)言之間服務(wù)調(diào)用的問題。

對(duì)于像eureka這樣的應(yīng)用內(nèi)的注冊(cè)中心。由于服務(wù)的注冊(cè)與發(fā)現(xiàn)都是依賴于SDK，所以如果要使用eureak那需要對(duì)應(yīng)的語(yǔ)言實(shí)現(xiàn)的SDK，目前有不少語(yǔ)言都有提供如Python、node.js。目前springclould的Sidecar組件也可以做到將其他語(yǔ)言納入到springclould體系中來(lái)。

對(duì)于應(yīng)用外的注冊(cè)中心，一般會(huì)由這些中間件提供客戶端操作實(shí)現(xiàn)。然后由語(yǔ)言本身來(lái)實(shí)現(xiàn)服務(wù)注冊(cè)和治理等功能。目前很多語(yǔ)言實(shí)際上也有相關(guān)的開源工程。

節(jié)點(diǎn)存活判斷

前面已經(jīng)說(shuō)過了保證CP類型的強(qiáng)一致性注冊(cè)中心以及AP類型保證可用性的注冊(cè)中心。而對(duì)于一個(gè)注冊(cè)中心來(lái)說(shuō)最重要的就是管理其中的節(jié)點(diǎn)信息。服務(wù)啟動(dòng)的時(shí)候需要將服務(wù)信息記錄，當(dāng)服務(wù)出現(xiàn)問題的時(shí)候需要將服務(wù)摘除。

但是問題在于如何實(shí)現(xiàn)這個(gè)摘除的操作，目前注冊(cè)中心的實(shí)現(xiàn)都是通過心跳檢測(cè)來(lái)判斷服務(wù)的健康狀態(tài)。正常情況下如果服務(wù)宕機(jī)了，心跳檢測(cè)無(wú)法和服務(wù)通信判斷該節(jié)點(diǎn)無(wú)法正常服務(wù)，將服務(wù)從注冊(cè)中心摘除，這個(gè)過程是沒有問題的。但是如果發(fā)生網(wǎng)絡(luò)問題，比如網(wǎng)絡(luò)抖動(dòng)或者網(wǎng)絡(luò)分區(qū)，這時(shí)候心跳檢測(cè)肯定是無(wú)法正常通信的，但如果就因此直接將服務(wù)摘除那肯定是有問題的，因?yàn)楣?jié)點(diǎn)實(shí)際上是能夠正常提供服務(wù)的。所以需要有機(jī)制來(lái)確保這個(gè)過程不會(huì)粗暴的將節(jié)點(diǎn)從注冊(cè)中心摘除。

客戶端判斷

目前很多的框架實(shí)現(xiàn)都會(huì)在本地緩存微服務(wù)的節(jié)點(diǎn)信息。實(shí)際上使用這些節(jié)點(diǎn)的是各個(gè)服務(wù)，服務(wù)是否能正常使用，這些節(jié)點(diǎn)才是最有發(fā)言權(quán)的。

客戶端緩存了節(jié)點(diǎn)信息，當(dāng)服務(wù)端判定服務(wù)出現(xiàn)問題后發(fā)出更新請(qǐng)求時(shí)，客戶端并不立刻刪除，可以先做一個(gè)標(biāo)識(shí)。后續(xù)的業(yè)務(wù)請(qǐng)求過來(lái)后，仍舊判定該服務(wù)時(shí)可用的，只有當(dāng)發(fā)出的請(qǐng)求無(wú)法收到正常回應(yīng)時(shí)才將該服務(wù)摘除。由客戶端來(lái)決定節(jié)點(diǎn)是否可用，不過這需要容錯(cuò)機(jī)制來(lái)支持。

動(dòng)態(tài)設(shè)置心跳檢測(cè)

在網(wǎng)絡(luò)頻繁抖動(dòng)的情況下，注冊(cè)中心的節(jié)點(diǎn)信息會(huì)快速變化，也會(huì)給客戶端發(fā)送大量的信息，當(dāng)服務(wù)較多的時(shí)候可能會(huì)有大量的帶寬被占用導(dǎo)致正常的請(qǐng)求都無(wú)法處理。

所以需要一種動(dòng)態(tài)的調(diào)整注冊(cè)中心心跳檢測(cè)頻率的機(jī)制，當(dāng)檢測(cè)到網(wǎng)絡(luò)抖動(dòng)頻繁時(shí)，根據(jù)網(wǎng)絡(luò)情況調(diào)整心跳檢測(cè)的頻率，比如調(diào)整為正常情況下的1/2,10/1等。在網(wǎng)絡(luò)正常時(shí)心跳檢測(cè)也恢復(fù)正常。