微服務(wù)初體驗(yàn)（二）：使用Nacos作為配置中心并集成Dubbo

首先啟動(dòng)Nacos，按照上篇文章的步驟，啟動(dòng)Nacos服務(wù)和項(xiàng)目，訪問Nacos的web頁面。確保項(xiàng)目中的服務(wù)都注冊(cè)到注冊(cè)中心當(dāng)中了。在application.yml同級(jí)目錄下添加bootstrap.yml，在Spring boot項(xiàng)目中bootstrap.yml會(huì)比application.yml優(yōu)先初始化，所以我們需要在bootstrap.yml中引入Nacos官方指定的配置文件即可（上篇文章中已經(jīng)把Nacos作為配置中心的配置寫入了application.yml，現(xiàn)在只需要把它從applicaiton.yml中剪切出來即可， 其中的spring:application:name會(huì)作為Nacos中新增配置時(shí)的Data ID，需要留意 ），再新增屬性gorup進(jìn)行分組測(cè)試，如下圖

創(chuàng)新互聯(lián)公司2013年成立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元東興做網(wǎng)站,已為上家服務(wù),為東興各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:13518219792

接著打開Nacos的服務(wù)的web頁面，打開配置管理-配置列表，點(diǎn)擊右側(cè)新增按鈕，進(jìn)行新增。

Data ID： bootstrap.yml配置文件中spring:application:name對(duì)應(yīng)的名稱 ；

Group：指定分組（便于不同環(huán)境下的項(xiàng)目配置管理，因?yàn)楣P者這里屬于測(cè)試，所以填寫的是和上文中的配置文件中g(shù)roup對(duì)應(yīng)的test一致）；

描述：針對(duì)于該配置的描述；

配置格式：配置文件的格式，要和Data ID中的后綴格式一致（這里筆者用的是yml，那么下面就選擇yaml，注意該位置也可以選擇properties，但是必須和上面bootstrap.yml文件中的file-extension的值相匹配）；

配置內(nèi)容：具體的配置內(nèi)容（這里筆者將項(xiàng)目中的application.yml中的配置全部拷貝至其中）；

測(cè)試啟動(dòng)consumer服務(wù)，在application.yml中為空的時(shí)候，項(xiàng)目啟動(dòng)端口還是如Nacos配置中的9011，說明項(xiàng)目依賴Nacos的配置中心成功，其他服務(wù)如法炮制即可：

新增一個(gè)測(cè)試Controller，然后加上@RefreshScope注解，表明該Controller中的配置數(shù)據(jù)為自動(dòng)刷新 。

編輯Nacos中的配置文件consumer新增相關(guān)參數(shù)type: test，訪問Controller，返回test。效果如下圖：

將Nacos中consumer.yml文件的type: test修改為type: prod，在不重啟項(xiàng)目的情況下重新訪問對(duì)應(yīng)的controller，效果如下圖：

因?yàn)镈ubbo是屬于各個(gè)服務(wù)之間都要公用的依賴，所以將其引入cloud-common當(dāng)中，詳細(xì)的版本可以去 mvnrepository 搜索合適自己項(xiàng)目的

引入依賴后需要編寫消費(fèi)者服務(wù)中的配置文件，將Dubbo服務(wù)注冊(cè)至Nacos，新增如下內(nèi)容，其中subscribed-services指的是生產(chǎn)者服務(wù)，prot：-1指的是端口隨機(jī)，registry:address:指的是Dubbo對(duì)應(yīng)的注冊(cè)中心那這里就應(yīng)該設(shè)置為Nacos

接下來新增接口服務(wù)，項(xiàng)目類型為Maven項(xiàng)目，在項(xiàng)目中新增一個(gè)接口。并在cloud-provider（生產(chǎn)者）和cloud-consumer（消費(fèi)者）pom.xml文件中都引入該模塊

在生產(chǎn)者實(shí)際服務(wù)中實(shí)現(xiàn)該接口對(duì)應(yīng)的方法

在服務(wù)消費(fèi)者的Controller中引入該Service，并在該Service上加入@Reference注解，注意在引入jar包的時(shí)候選擇帶有Dubbo的，不要使用Jdk原生的

編寫消費(fèi)者服務(wù)中測(cè)試Dubbo調(diào)用的接口，進(jìn)行測(cè)試，測(cè)試結(jié)果如下圖：

什么是Nacos？Nacos注冊(cè)配置中心介紹

英文全稱Dynamic Naming and Configuration Service，Na為naming/nameServer即注冊(cè)中心,co為configuration即注冊(cè)中心，service是指該注冊(cè)/配置中心都是以服務(wù)為核心。服務(wù)在nacos是一等公民

Nacos注冊(cè)中心分為server與client，server采用Java編寫，為client提供注冊(cè)發(fā)現(xiàn)服務(wù)與配置服務(wù)。而client可以用多語言實(shí)現(xiàn)，client與微服務(wù)嵌套在一起，nacos提供sdk和openApi，如果沒有sdk也可以根據(jù)openApi手動(dòng)寫服務(wù)注冊(cè)與發(fā)現(xiàn)和配置拉取的邏輯

Nacos服務(wù)領(lǐng)域模型主要分為命名空間、集群、服務(wù)。在下圖的分級(jí)存儲(chǔ)模型可以看到，在服務(wù)級(jí)別，保存了健康檢查開關(guān)、元數(shù)據(jù)、路由機(jī)制、保護(hù)閾值等設(shè)置，而集群保存了健康檢查模式、元數(shù)據(jù)、同步機(jī)制等數(shù)據(jù)，實(shí)例保存了該實(shí)例的ip、端口、權(quán)重、健康檢查狀態(tài)、下線狀態(tài)、元數(shù)據(jù)、響應(yīng)時(shí)間。這些數(shù)據(jù)的作用會(huì)在第三章講到

服務(wù)注冊(cè)方法：以Java nacos client v1.0.1 為例子，服務(wù)注冊(cè)的策略的是每5秒向nacos server發(fā)送一次心跳，心跳帶上了服務(wù)名，服務(wù)ip，服務(wù)端口等信息。同時(shí) nacos server也會(huì)向client 主動(dòng)發(fā)起健康檢查，支持tcp/http檢查。如果15秒內(nèi)無心跳且健康檢查失敗則認(rèn)為實(shí)例不健康，如果30秒內(nèi)健康檢查失敗則剔除實(shí)例。

不同的命名空間邏輯上是隔離的，不特殊設(shè)置的情況下，服務(wù)不會(huì)跨命名空間請(qǐng)求，命名空間主要的作用是區(qū)分服務(wù)使用的范圍，比如開發(fā)、測(cè)試、生產(chǎn)、灰度可以分別設(shè)置四個(gè)命名空間來互相隔離。

以springcloud為例，首先用maven導(dǎo)入nacos clinet的依賴：

先導(dǎo)入springcloud的alibaba-nacos-config和alibaba-nacos-discovery兩個(gè)依賴，這兩個(gè)依賴是用于nacos clinet與cloud結(jié)合的工具，0.2.x對(duì)應(yīng)springboot 2.x.x ,0.1.x對(duì)應(yīng)springboot 1.x.x。這兩個(gè)組件可以和各種版本的nacos-client結(jié)合。把其中的nacos-clinet依賴給排除，引入想要引入的nacosclinet版本，如下：

在bootstrap.properties上添加配置中心的配置

在application-xxx.properties新增如下配置

如果springboot啟動(dòng)類沒有 @EnableDiscover 注解則加上

完成如上更改，即可使用Nacos注冊(cè)/配置服務(wù)

演示：

使用Feign、Ribbon均可，在這不做過多介紹

普通application參數(shù)在配置中心直接配置皆可，如果需要可以動(dòng)態(tài)刷新的配置，需要在相應(yīng)類上加上 @RefreshScope 注解,示例如下，當(dāng)在nacos配置中心更改配置后，方法getId的值也會(huì)刷新。

配置中心參數(shù)修改/設(shè)置

如下兩張圖：在nacos控制臺(tái)的 配置管理-配置列表 中頂部選擇相應(yīng)的命名空間，點(diǎn)擊列表右上角的加號(hào)新增配置，Data ID 為 項(xiàng)目名-{spring.profiles.active}.properties,Group如果在bootstrap.properties中不指定則填默認(rèn)的DEFAULT_GROUP，描述寫該配置的描述，配置內(nèi)容填寫Properties格式或者Yaml格式。

在控制臺(tái)的 服務(wù)管理-服務(wù)列表 選擇一個(gè)服務(wù)點(diǎn)擊詳情，在下方的集群列表可以看到有上線/下線按鈕，點(diǎn)擊即可以對(duì)該實(shí)例執(zhí)行上線/下線操作，下線后的實(shí)例不會(huì)被請(qǐng)求

可以通過手動(dòng)配置權(quán)重來控制流量，當(dāng)一個(gè)集群內(nèi)兩個(gè)實(shí)例，權(quán)重越高，到達(dá)該實(shí)例的請(qǐng)求比例越多。

權(quán)重的初始值是1

保護(hù)閾值的范圍是0~1

服務(wù)的健康比例=服務(wù)的健康實(shí)例/總實(shí)例個(gè)數(shù)

當(dāng)服務(wù)健康比例=保護(hù)閾值時(shí)候，無論實(shí)例健不健康都會(huì)返回給調(diào)用方

當(dāng)服務(wù)健康比例保護(hù)閾值的時(shí)候，只會(huì)返回健康實(shí)例給調(diào)用方

在 服務(wù)管理-服務(wù)列表 選擇一個(gè)服務(wù)點(diǎn)擊詳情可以配置

三、微服務(wù)注冊(cè)到Nacos

將各個(gè)微服務(wù)注冊(cè)到Nacos，方便調(diào)用與配置

ps：?jiǎn)?dòng)可能會(huì)報(bào)錯(cuò)： NACOS SocketTimeoutException httpGet] currentServerAddr:，error超時(shí) ，因?yàn)檎也坏脚渲玫膎acos遠(yuǎn)程服務(wù)。若配置沒有錯(cuò)誤，則要修改 application.yml 為 bootstrap.yml ，因?yàn)椋?/p>

所以建議：若要在Nacos中管理配置文件，服務(wù)中直接使用 bootstrap.yml（bootstrap.properties） 來放nacos的配置。

微服務(wù)架構(gòu)之服務(wù)注冊(cè)與發(fā)現(xiàn)(一)

一、服務(wù)注冊(cè)中心的由來

假如沒有服務(wù)注冊(cè)中心，我們會(huì)干些什么事情呢？

在傳統(tǒng)行業(yè)的項(xiàng)目架構(gòu)中以下的方案最為常見了：

這種架構(gòu)開發(fā)、部署都是最簡(jiǎn)單的，一般適用于中小企業(yè)訪問量并不是太多的情況下，各個(gè)系統(tǒng)服務(wù)一臺(tái)機(jī)器就搞定了。系統(tǒng)之間的調(diào)用也是拿到對(duì)方的IP+PORT直接連接。

接下來可能因?yàn)閼?yīng)用B開始訪問量大了，單臺(tái)機(jī)器已經(jīng)不能滿足我們的需求，于是一些反向代理工具應(yīng)運(yùn)而出，其中比較常見的有Apache、Nigix，架構(gòu)演變?yōu)椋?/p>

相比之前的應(yīng)用B的單臺(tái)機(jī)器訪問，這種nginx代理的方式減輕了服務(wù)器的壓力，但是可能會(huì)出現(xiàn)Nginx掛了，那么整個(gè)服務(wù)也不可用，于是又來了這么一套架構(gòu)：

這樣看方案算是完美了吧。然后事情并不是想象的那么一帆風(fēng)順，這還只是應(yīng)用A調(diào)用一個(gè)應(yīng)用B，如果應(yīng)用A調(diào)用的可能是應(yīng)用B、C、D、E...，這種完全就不知道他后面到底還想干嘛，這種架構(gòu)看似可以，但是絕對(duì)會(huì)累死運(yùn)維的（nginx的配置將會(huì)非常混亂，直接導(dǎo)致運(yùn)維不干了）。

服務(wù)注冊(cè)中心干些什么事情呢？

上面提到的那種靠人力（主要是運(yùn)維干的事情）比較繁瑣，還不好維護(hù)，有這么幾點(diǎn)不方便：應(yīng)用服務(wù)的地址變了、雙十一搞活動(dòng)服務(wù)器新增等等。那么我們可以有這么的一種架構(gòu)：

服務(wù)注冊(cè)中心主要是維護(hù)各個(gè)應(yīng)用服務(wù)的ip+port列表，并保持與各應(yīng)用服務(wù)的通訊，在一定時(shí)間間隔內(nèi)進(jìn)行心跳檢測(cè)，如果心跳不能到達(dá)則對(duì)服務(wù)IP列表進(jìn)行剔除，并同時(shí)通知給其它應(yīng)用服務(wù)進(jìn)行更新。同樣要是有新增的服務(wù)進(jìn)來，應(yīng)用服務(wù)會(huì)向注冊(cè)中心進(jìn)行注冊(cè)，服務(wù)注冊(cè)中心將通知給其它應(yīng)用進(jìn)行更新。每個(gè)應(yīng)用都有需要調(diào)用對(duì)應(yīng)應(yīng)用服務(wù)的地址列表，這樣在進(jìn)行調(diào)用時(shí)只要處理客戶負(fù)載雜均衡即可。

二、微服務(wù)注冊(cè)中心

1.Zookeeper

ZooKeeper是一個(gè)分布式的，開放源碼的分布式應(yīng)用程序協(xié)調(diào)服務(wù)，是Google的Chubby一個(gè)開源的實(shí)現(xiàn)，是Hadoop和Hbase的重要組件。它是一個(gè)為分布式應(yīng)用提供一致性服務(wù)的軟件，提供的功能包括：配置維護(hù)、域名服務(wù)、分布式同步、組服務(wù)等。

上面的話直接摘抄百度百科的內(nèi)容，國(guó)內(nèi)很多公司做分布式開發(fā)最初的選型大部分都是采用dubbo框架。dubbo框架注冊(cè)中心主要使用zookeeper。zookeeper服務(wù)端與客戶端的底層通訊為netty。zookeeper采用CAP理論中的CP，一般集群部署最少需要3臺(tái)機(jī)器。

2.Euraka

先來看一下euraka的架構(gòu)圖：

Register：服務(wù)注冊(cè)

當(dāng)Eureka客戶端向Eureka Server注冊(cè)時(shí)，它提供自身的元數(shù)據(jù)，比如IP地址、端口，運(yùn)行狀況指示符URL，主頁等。

Renew：服務(wù)續(xù)約

Eureka客戶會(huì)每隔30秒發(fā)送一次心跳來續(xù)約。 通過續(xù)約來告知Eureka Server該Eureka客戶仍然存在，沒有出現(xiàn)問題。 正常情況下，如果Eureka Server在90秒沒有收到Eureka客戶的續(xù)約，它會(huì)將實(shí)例從其注冊(cè)表中刪除。 建議不要更改續(xù)約間隔。

Fetch Registries：獲取注冊(cè)列表信息

Eureka客戶端從服務(wù)器獲取注冊(cè)表信息，并將其緩存在本地。客戶端會(huì)使用該信息查找其他服務(wù)，從而進(jìn)行遠(yuǎn)程調(diào)用。該注冊(cè)列表信息定期（每30秒鐘）更新一次。每次返回注冊(cè)列表信息可能與Eureka客戶端的緩存信息不同， Eureka客戶端自動(dòng)處理。如果由于某種原因?qū)е伦?cè)列表信息不能及時(shí)匹配，Eureka客戶端則會(huì)重新獲取整個(gè)注冊(cè)表信息。 Eureka服務(wù)器緩存注冊(cè)列表信息，整個(gè)注冊(cè)表以及每個(gè)應(yīng)用程序的信息進(jìn)行了壓縮，壓縮內(nèi)容和沒有壓縮的內(nèi)容完全相同。Eureka客戶端和Eureka 服務(wù)器可以使用JSON / XML格式進(jìn)行通訊。在默認(rèn)的情況下Eureka客戶端使用壓縮JSON格式來獲取注冊(cè)列表的信息。

Cancel：服務(wù)下線

Eureka客戶端在程序關(guān)閉時(shí)向Eureka服務(wù)器發(fā)送取消請(qǐng)求。 發(fā)送請(qǐng)求后，該客戶端實(shí)例信息將從服務(wù)器的實(shí)例注冊(cè)表中刪除。該下線請(qǐng)求不會(huì)自動(dòng)完成，它需要調(diào)用以下內(nèi)容：

DiscoveryManager.getInstance().shutdownComponent()；

Eviction 服務(wù)剔除

在默認(rèn)的情況下，當(dāng)Eureka客戶端連續(xù)90秒沒有向Eureka服務(wù)器發(fā)送服務(wù)續(xù)約，即心跳，Eureka服務(wù)器會(huì)將該服務(wù)實(shí)例從服務(wù)注冊(cè)列表刪除，即服務(wù)剔除。

自我保護(hù)機(jī)制：

既然Eureka Server會(huì)定時(shí)剔除超時(shí)沒有續(xù)約的服務(wù)，那就有可能出現(xiàn)一種場(chǎng)景，網(wǎng)絡(luò)一段時(shí)間內(nèi)發(fā)生了 異常，所有的服務(wù)都沒能夠進(jìn)行續(xù)約，Eureka Server就把所有的服務(wù)都剔除了，這樣顯然不太合理。所以，就有了 自我保護(hù)機(jī)制，當(dāng)短時(shí)間內(nèi)，統(tǒng)計(jì)續(xù)約失敗的比例，如果達(dá)到一定閾值，則會(huì)觸發(fā)自我保護(hù)的機(jī)制，在該機(jī)制下， Eureka Server不會(huì)剔除任何的微服務(wù)，等到正常后，再退出自我保護(hù)機(jī)制。自我保護(hù)開關(guān)(eureka.server.enableself-preservation: false)

3.Consul

consul推薦的架構(gòu)圖：

Consul不像Euraka的部署那么簡(jiǎn)單，他是go語言開發(fā)的，需要運(yùn)維單獨(dú)部署，有提供java的客戶端連接，采用的是CAP的CP。

4.Nacos

Euraka是Spring Cloud Netflix早期版本中推薦使用的，后來euraka1.0版本不再維護(hù)，euraka2.0已經(jīng)閉源，導(dǎo)致很多新項(xiàng)目基于Spring Cloud Netflix 開發(fā)的選型變遷為Consul.

Nacos是阿里開源的服務(wù)注冊(cè)中心，它可以與spring cloud aliaba集成使用。

Nacos的官方介紹：

Nacos 致力于幫助您發(fā)現(xiàn)、配置和管理微服務(wù)。Nacos 提供了一組簡(jiǎn)單易用的特性集，幫助您實(shí)現(xiàn)動(dòng)態(tài)服務(wù)發(fā)現(xiàn)、服務(wù)配置管理、服務(wù)及流量管理。

Nacos 幫助您更敏捷和容易地構(gòu)建、交付和管理微服務(wù)平臺(tái)。 Nacos 是構(gòu)建以“服務(wù)”為中心的現(xiàn)代應(yīng)用架構(gòu)(例如微服務(wù)范式、云原生范式)的服務(wù)基礎(chǔ)設(shè)施。

Nacos 地圖

Nacos 生態(tài)圖

如 Nacos 全景圖所示，Nacos 無縫支持一些主流的開源生態(tài)，例如

Spring Cloud

Apache Dubbo and Dubbo Mesh TODO

Kubernetes and CNCF TODO

三、服務(wù)注冊(cè)與發(fā)現(xiàn)技術(shù)選型

以下是來自網(wǎng)上的一個(gè)分享：

除了上述的幾種以外，筆者更推薦使用Nacos作為服務(wù)注冊(cè)中心。

推薦理由：

Nacos服務(wù)注冊(cè)表結(jié)構(gòu)Mapnamespace, Mapgroup::serviceName, Service采用多層次Map結(jié)構(gòu)，控制的顆粒度更細(xì)，支持金絲雀模式發(fā)布，心跳同步機(jī)制也更快速，服務(wù)更新更及時(shí)。