如何配置consulconfig

⑴ 如何用Consul打造彈性可擴展的PaaS平台

如何用Consul打造彈性可擴展的PaaS平台
杜威，程序員，混跡互聯網研發和運維近十年。《Linux系統案例精解》合著者之一。目前就職亮風台，專注DevOps、雲計算、大數據等相關領域。

應用背景

HiAR 是亮風台打造的新一代增強現實(AR)開發平台，提供簡單易用、功能強大、跨平台的 AR 服務。讓廣大開發者可以輕松使用最前沿的計算機視覺技術、計算機圖形學技術，快速搭建個性化的 AR 應用。

雲服務是HiAR平台中重要的基礎設施。無論從高可用，還是到可擴展，服務發現都發揮著不可或缺的作用。在沒有使用服務發現之前，我們遇到的幾個痛點：

◆ 系統添加一個服務節點，我們需要手工修改Nginx/LVS的配置文件、修改DNS記錄。

◆ 應用服務發布新版本，我們還是需要手工修改Nginx的配置文件把節點下線、等待發布成功後，再次修改Nginx的配置文件把服務上線。

◆ 盡管後來我們對上面兩種場景的運維做了改進，編寫腳本把過程改良為半自動半手動的方式，但還不是很方便，而結合服務注冊就可以做到全自動。

◆ 內網DNS出了故障，我們需要對DNS服務進行維護。

◆ 沒有服務注冊，限制了Docker的發揮，只能當輕量級虛擬機來用。

現在，有了服務發現，一切都變得簡單有趣。增減服務節點可以自動更新Nginx/LVS的配置文件；DNS丟一邊吧！用IP就好；接入Mesos+Docker玩彈性擴展。

為什麼選擇 Consul

已經有很多文章對Zookeeper、etcd、Consul進行比較，這里就不重復類比了。沒有什麼比合適更重要！Consul 的運維成本低，部署簡單、使用方便、五臟俱全，這對於中小型團隊應該是性價比很高的。

在進入實戰前，先看看 Consul 都有哪些特性。

◆ 服務注冊。通過HTTP API或DNS，告訴服務注冊中心有新的服務加入。

◆ 服務發現。通過HTTP API或DNS，可以知道目標服務的地址和埠。

◆ 健康檢查。支持多種方式，HTTP、TCP、Docker、Shell腳本定製化監控。

◆ 配置模板。Consul Template 負責定期從服務注冊中心獲取信息，如果有變化自動更新配置文件並重新載入。

以上四點已經能滿足很多企業的需求。當然這不是Consul的所有，Consul還有很多錦上添花的特性，比如：可視化Web界面、支持多數據中心。

實戰經驗

我們對Consul的使用可以歸納到四個方面：部署、應用、管理、升級。

部署

Consul Cluster有Server和Client兩種角色。Server一般是3~5台，這也是官方推薦的。Consul Client就是需要進行服務注冊或服務發現的節點。

Consul的部署簡單、開箱即用，一個consul可執行文件，還沒有亂七八糟的依賴。在官網下載編譯好的Consul agent可執行文件，並上傳到所有Server和Client角色的節點，便隨時可啟動consul agent了。

下面一起來看看，如何啟動一個Consul集群(3台Server、1台Client)。

實驗環境：

server01 192.168.1.11
server02 192.168.1.12
server03 192.168.1.13
client01 192.168.1.21
分別登錄Server01、Server02、Server03，並啟動agent。

[worker@server01 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.11 -node=server01
[worker@server02 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.12 -node=server02
[worker@server03 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.13 -node=server03
新開窗口登錄Server03，加入Server01、Server02的集群。

[worker@server03 ~]$ consul join 192.168.1.11 192.168.1.12
上面幾步就完成了初始化Server節點，以後通過-rejoin參數啟動，可以重新加入集群。

[worker@server01 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.11 -node=server01 -rejoin
[worker@server02 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.12 -node=server02 -rejoin
[worker@server03 ~]$ consul agent -server -bootstrap-expect 2 -data-dir /tmp/consul -bind=192.168.1.13 -node=server03 -rejoin
就這樣三個Server節點部署完畢。接下來，部署Client節點，和Server節點一樣，有初次啟動、手工加入和重新加入集群三步。

[worker@client01 ~]$ consul agent -data-dir /tmp/consul -bind=192.168.1.21 -node=client01
還是在Client01上，新開一個登錄窗口，加入Server01的集群。

[worker@client01 ~]$ consul join 192.168.1.11
Client01節點日後的維護，通過-rejoin參數啟動，便可重新加入集群。

[worker@client01 ~]$ consul agent -data-dir /tmp/consul -bind=192.168.1.21 -node=client01 -rejoin
到這里為止，我們已經搭建好了一個Consul集群。然而，怎麼進行服務注冊和服務發現呢?這得跟實際需求緊密結合，在接下來的小節中進一步說明。

應用

Consul不是單獨存在的。為了充分發揮Consul的優勢，可以結合Nginx、LVS、Docker等工具來應用。

Nginx、LVS是系統的基礎組件，RecoService、FeatureService、SearchService是基於SOA的內部服務。前者向Consul集群發現服務，後者向Consul集群注冊服務。Consul是粘合劑也是開關，讓整個系統的運作起來，低成本的實現了彈性伸縮。

接入層，用的是Nginx，負責反向代理和負載均衡。Nginx節點上跑兩個Consul相關服務。一個是Consul Agent，做Consul Client；另外一個是Consul Template，做服務發現和配置更新。Consul Template負責定期查詢本地Consul Agent，如果相關服務的注冊信息有變化，則更新Nginx的配置文件並重新載入Nginx服務。

運行Consul Template是實現彈性擴展的關鍵步驟：

$ consul-template -consul 127.0.0.1:8500 -template "/etc/nginx/conf/vhosts/test.ctmpl:/etc/nginx/conf/vhosts/test.conf:nginx -s reload"
上面這句命令中，test.conf是Nginx的虛擬主機配置文件，test.ctmpl是該配置文件對應的模板。下面是模板在負載均衡上的代碼片段：

upstream test-cluster {
ip_hash;{{range service "test"}}
server {{.Address}}:{{.Port}};{{end}}
}
邏輯層，基於SOA的內部服務集群。不同的內部服務集群之間通信需要做服務發現，這里引入LVS做服務發現。好處是不用在內部服務的代碼里實現服務發現，而且規模大了還要做負載均衡。與接入層的Nginx類似，LVS也用Consul Template定期查詢本地Consul Agent，更新相關配置文件，然後重載服務。

內部服務如何向服務中心注冊?有兩種方式，一是通過Consul的服務注冊HTTP API，由服務自身在啟動後調用API注冊自己，二是通過在配置文件中定義服務的方式進行注冊。建議使用後面一種方式來做服務注冊。怎麼辦到的?請繼續往下看 ：)

為項目添加一個配置文件consul.json，指定服務名稱和服務埠，並加上健康檢查，內容如下：

{
"service":
{
"name" : "test",
"port" : 9999,
"check":
{
"tcp": "127.0.0.1:9999",
"interval": "10s"
}
}
}
最後一步，對服務進行注冊，需要在Consul agent啟動時指定配置文件，如下：

$ consul agent -data-dir /tmp/consul -node=test -bind=192.168.1.21 -config-dir=/tmp/consul.json
管理

一是節點管理，也就是Consul進程的管理。由於Consul Agent本身不具備高可用能力，所以我們有必要對Consul進程進行接管，我們用的是Systemd，你也可以選擇Supervisord或者Upstart這些進程管理工具。

二是集群管理，Consul提供了可視化管理界面。可以查看所有的服務和節點，以及它們的健康檢測和當前狀態。

升級

由於Consul關繫到整個系統的正常運作，所以升級的時候還是要很小心。最好在測試環境試驗多幾次，再到生產環境升級。升級的狀況可以歸納為下面三種，需要對號入座之後再進行升級。

◆ 特殊版本的升級。在upgrade-specific頁面查看當前升級的版本是否有特殊說明。比如：0.5.1之前的版本直接升級到0.6版本，要藉助工具consul-migrate進行數據遷移。

◆ 不兼容的升級。使用consul -v查看新版的向後兼容協議版本號，當出現與當前版本不兼容時，需要分兩步升級。先通過參數-protocal=舊的協議版本號，把整個集群升級一次，再把啟動命令中的參數-protocal去掉來重啟所有節點。

◆ 標準的升級。如果上面兩種情況都不是，那麼恭喜你，你需要做的只是簡單的標准升級。即：停止舊版本的agent，然後啟動新版本的agent。PS：其實大多數情況都是標准升級。

升級節點的推薦順序是，先升級Server的Follower節點，再升級Server的Leader節點，最後升級所有Client的節點。

結語

在系統中引入服務注冊和發現，雖然是一發牽動全身的改造，但整個系統架構會因此受益，尤其是現代的微服務架構。相信很多系統都具備負載均衡、健康檢查、心跳檢測等能力，利用好服務發現，那麼彈性伸縮、服務高可用、灰度發布，自然是水到渠成的事情。

⑵ consul在本地安裝後有哪些配置文件

是有兩個，就像刪個一樣。比方說在酷狗里下了一首個歌這一首歌是你本來的歌單就有的你要把在酷狗里的這首歌刪掉本地文件就是你本來的不是在酷狗里的那首歌那就叫本地文件

⑶ OpenResty 動態負載均衡

在之前提到的OpenResty/Nginx的負載均衡當中，當伺服器啟動之後，upstream中的上游伺服器就是固定死的了，做不到動態的變更。這裡面說到的變更，其實更多指的是增加機器。因為當上游伺服器不可用時，upstream會自動將伺服器摘除，但是當新增伺服器時，upstream就做不到了。傳統的負載均衡辦法，就是能是修改配置，然後重啟服務。下面介紹一下動態負載均衡的方式，一種是通過動態重啟服務；另外一種是通過代碼的方式動態拉取伺服器列表。

Consul是一個分布式服務注冊與發現系統。這裡面使用Consul來管理上游伺服器，當伺服器啟動時將其注冊到注冊中心去，當服務關閉時從注冊中心列表中剔除。這裡面需要注意一點的是：當上游伺服器關閉時，Consul本身不會自動從列表中剔除，而是需要在伺服器關閉前主動向Consul發起刪除服務。

Consul有以下特性：

通過Consul可以獲取到upstream中的上游伺服器列表，下面要做的事情就是生成upstream中的模板了。這里就需要用到Consul-templete，它可以使用HTTP長輪詢實現變更觸發和配置更改。從而可以根據Consul伺服器列表動態生成配置文件，然後去重新啟動OpenResty/Nginx即可。

Consul+Consul-templete 就如上面所說的，是一種監聽伺服器列表變更，然後動態生成upstream模板，重啟伺服器。

Consul-Server

筆者使用的是MAC，下面所進行的操作都是基於MAC系統的。首先需要安裝Consul如下：

安裝完成之後，可以通過如下命令啟動Consul服務：

啟動完成之後，可以通過如下地址：localhost:8500/ui。訪問Consul的Web界面：

可以使用HTTP的方式向Consul注冊一個服務：

Consul-template

Consul-template的作用是生成upstream配置模板，安裝命令如下：

然後在nginx.conf同級目錄下創建moguhu_server.ctmpl

重啟OpenResty腳本如下：reboot.sh

然後nginx.conf配置如下:

上游伺服器

上游伺服器upstream中使用的是Spring Boot實現的，其核心代碼如下所示：

筆者在實驗時，Consul版本的問題，造成在JVM停止時，沒有執行刪除服務的操作。因此附上下面的pom依賴

測試驗證

1、啟動Consul

2、啟動Consul-template

3、啟動2台upstream伺服器

然後你會發現在nginx.conf的同級目錄下生成了moguhu_server.conf文件，內容如下：

當手動停掉一台伺服器時，配置又會變更為如下：

此時reboot.sh腳本會自動觸發執行，如下所示：

上面的方式實現動態負載均衡在配置較多的時候會有一些問題，比如配置較多時，OpenResty重啟的速度就會變慢。所以通過Lua腳本的方式可以規避掉重啟這一步驟。

使用Lua實現時，與上面的組件相比Consul-templete就不需要了。通過Consul的 http://127.0.0.1:8500/v1/catalog/service/moguhu_server 介面就可以獲取到服務的列表，如下所示：

這一方式當中主要就是OpenResty裡面的相關配置。

OpenResty 配置

upstreams.lua

nginx.conf

上面通過balancer_by_lua_block去動態的設置了，upstream的伺服器列表。然後啟動OpenResty就可以了。

參考：《億級流量網站架構核心技術》

⑷ consul修改默認配置後執行命令失效

創建一個 bootstrap.properties 配置文件來配置consul的配置中心相關配置。
consul的配置中心功能可使用，在bootstrap.properties 配置文件中設置， spring.cloud.consul.config.enabled=false 。
僅使用consul的服務注冊與發現功能，pom文件中刪除spring-cloud-consul-config依賴。僅使用consul的服務注冊與發現功能

⑸ 微服務架構系列之–最全配置中心對比（面試隨便裝）

本文從社區活躍度、產品特點、成功案例、產品缺點等維度，全方位對比Spring Cloud Config、Apollo、Nacos、Disconf、Spring Cloud Consul、Spring Cloud Zookeeper等幾款Spring Cloud生態的配置伺服器，幫助你選擇合適的配置伺服器。

一、Spring Cloud Config

GitHub地址

https://github.com/spring-cloud/spring-cloud-config ，Star數1178，官方組件，社區較活躍

開源廠商

Pivotal（Spring官方團隊）

產品特點

演示環境

暫無

成功案例

N多，目前用Spring Cloud的大多團隊都是用的Spring Cloud Config

缺點

二、Apollo

GitHub地址

https://github.com/ctripcorp/apollo ，Star數11169，社區很活躍

開源廠商

攜程

產品特點

成功案例

攜程、網易蜂巢、中國平安等，更多公司詳見https://github.com/ctripcorp/apollo

演示環境

http://106.12.25.204:8070/

賬號/密碼：apollo/admin

缺點

暫未發現

三、Nacos

GitHub地址

https://github.com/alibaba/nacos ，Star數3820，社區非常活躍

開源廠商

阿里巴巴

產品特點

成功案例

阿里巴巴、虎牙直播、工商銀行軟體開發中心、愛奇藝等，更多公司詳見https://github.com/alibaba/nacos/issues/273

演示環境

http://console.nacos.io/nacos/index.html

缺點

暫未發現明顯缺點

四、Disconf

GitHub地址

https://github.com/knightliao/disconf ，Start數4505，社區活躍度一般

開源廠商

原網路員工，現在螞蟻金服

產品特點

成功案例

網路、滴滴出行、順豐、網易等，更多公司詳見https://github.com/knightliao/disconf

缺點

最新的版本發布於兩年前，有點久了。

五、Spring Cloud Consul

GitHub地址

https://github.com/spring-cloud/spring-cloud-consul ，Star數493，官方組件，社區較活躍

開源廠商

Pivotal（Spring官方團隊）

產品特點

成功案例

暫未發現

演示環境

暫無

缺點

六、Spring Cloud Zookeeper

GitHub地址

https://github.com/spring-cloud/spring-cloud-zookeeper ，Star數330，官方組件，社區較活躍

開源廠商

Pivotal（Spring官方團隊）

產品特點

演示環境

暫無

成功案例

暫未發現

缺點

其他

如果使用的是Spring Cloud Kubernetes，或者將Spring Cloud應用部署在Kubernetes環境中，還可以選擇ConfigMap，這種方式就筆者了解，業界這么玩的還不多，暫時不分析了。已經將Spring Cloud Kubernetes列入博客19年更新名單中了，敬請期待。

結論

⑹ 一、Nacos介紹

6月份阿里開源的Nacos發布了1.0.1版本，從去年7月份第一個release版本到現在一直在默默關注

官方的版本規劃為：Nacos從0.8.0開始支持生產可用，1.0版本可大規模生產可用，2.0版本接入k8s、SpringCloud、ServiceMesh、ServerLess

公司目前的項目都是Springcloud，由於eureka2.X的斷更、以及Nacos面世，所以自然而然最近就進行了一次試水爬坑，雖然過程艱苦，但是最終效果似乎還不錯。

本文主要從以下幾點來帶大家熟悉下Nacos

Nacos是什麼？好像沒聽過，不要緊。那Eureka聽說過吧，在SpringCloud中做服務注冊中心組件，類似的還有Zookeeper、Consul。

所以Nacos也是一個注冊中心組件咯，當然是，不過 它不僅僅是注冊中心 。

Nacos也是一個配置中心 ，比如SpringCloud中的Config，將配置文件版本化管理。

那麼Nacos到底是什麼呢, 總結為官網一句話就是:

首先要說Nacos的發展歷程就要從阿里巴巴的內部產品ConfigServer說起了，因為 Nacos是ConfigServer 的開源實現

早在2008年阿里就開始服務化的進程(那個時候我好像還在上初中啊)，在那個時候阿里內部自研的服務發現解決方案就叫做ConfigServer

ConfigServer經歷了十年的發展從V1.0的單機版演變為目前對外公布的V4.0集群版。

2018年7月阿里巴巴高級技術專家許真恩（慕義）發布了Nacos首個開源版本V0.1.0，Nacos作為ConfigServer的開源實現截止目前已經更新到了V1.0.1的大版本，並且支持大規模生產版本。

雖然 官方文檔 也有介紹，但是語言比較官方，我就用大白話談一點自己的使用感受。

首先先上一張官方的生態圖

除了對於阿里開源生態體系如 Dubbo 等自身的支持，也非常強調融入其它的開源生態，這里就包括 Java 的微服務生態體系 Spring Cloud，Kubernetes/CNCF 雲原生生態體系。

Nacos 無縫支持 Spring Cloud，為 Spring Cloud 用戶其提供更簡便的配置中心和注冊中心的解決方案。

Nacos支持目前幾乎所有主流的微服務生態體系。

Nacos從官方的介紹上看，就像是SpringCloud中Eureka+Config+Bus+Git+MQ的一個結合體，當然也不能完全這么理解。Nacos是脫胎於阿里內部的ConfigServer，而ConfigServer早在3.0版本就解決了Eureka在1.0版本留下的隱患，所以從技術的更新和迭代角度來看，穩定版本的Nacos將更適合做為微服務體系中的服務注冊發現組件，當然了他也不單單只是注冊和發現。更多的特性和功能，不如一起搭建試試吧。

Nacos官方手冊

⑺ consul 怎麼把kv導出到一個指定的文件

方法一：先對結果進行排序分類匯總，復制粘貼排序後的數據，比較方便。
方法二： 進行三維地址引用。
直接在新的excel表輸入公式查找，而地址引用原來的表格，自然結果就會在新表了。
例如，在工作薄 book1 中引用工作薄 book2 的 sheet1 。
工作表的 第3行第5列單元格，可以寫作 [book2]sheet1!E3。

⑻ tectia client 配置文件路徑

1. 相對路徑
go run 或者 go build後在配置目錄的相對路徑上執行
假設當前目錄如下:
├─config
│ │ main.go
│ │
│ └─file // 配置文件目錄
│ config.ini
│
也就是說無論你是go run或者build後的執行程序,都應該在你執行目錄下
有該配置文件路徑如file/config.ini
否則就會發生以下錯誤, 無法讀取配置文件
panic: Error:can not read file "./file/config.ini"
// 測試代碼
func runOrBuildLoadConfig(){
// 使用庫 go get github.com/aWildProgrammer/fconf
c, err := fconf.NewFileConf(" ./file/config.ini")
if err != nil {
panic(err)
}
fmt.Println(c.Int("server.port"))
}
2. 絕對路徑
使用絕對路徑讀取配置文件
如果配置文件動態的話, 具體怎麼傳入 配置文件路徑
使用flag包, go run或者build的執行程序 帶上 -config=xxxxx路徑
通過配置set/export環境變數, os.Getenv()獲取該變數名稱對應的值(即路徑)
// 測試代碼
func useAbsPathLoadConfig(){
// 這是直接硬編碼的路徑
ff,err := os.OpenFile("D:/GoWorkspace/src/Examples/config/file/config.ini",os.O_RDWR,666)
if err != nil {
panic(err)
}
var buf [100]byte
ff.Read(buf[:])
log.Println(string(buf[:]))
}
3. 網路GET, http ftp等
3.1 通過網路去獲取配置文件
e.g http://localhost:8080/config/config.ini
func useNetworkLoadConfig(){
// ... 具體不實現
}
4. 嵌入到應用程序中
go-bindata 把配置文件打包進去
1. go get -u github.com/jteeuwen/go-bindata/...
2. 然後在當前目錄執行go install ../..安裝到GOPATH/bin目錄
3. 使用 go-bindata --prefix=file file/... 將file目錄下的文件嵌入,會生成bindata.go
4. go run main.go bindata.go 或者 build成可執行文件執行
// 測試代碼
func useBindataLoadConfig(){
data, err := Asset("config.ini")
if err != nil {
panic(err)
}
// 輸出 也可以拿來解析
log.Println(string(data))
5. 遠程配置中心
5.1 使用遠程配置中心去讀取配置
通過key/value的方式存儲在redis的配置, 配置過多可以使用pipe方式到導入
使用etcd / consul 之類的KV Store 進行動態配置

⑼ 電腦consul環境變數怎麼設置和使用

環境變數也是我們系統屬性中的一項重要的變數，接下來小編就教大家怎樣進行環境變數的配置和使用。

具體如下：

1.首先打開電腦進入到桌面，然後找到我的電腦圖標滑鼠右擊，在打開的菜單中選擇屬性選項。

然後我們會進入到系統界面我們在這個界面中點擊左側菜單中的高級系統設置選項。

接下來就會打開屬性界面，我們點擊系統屬性窗口上方的高級設置選項，進入到高級設置選項界面之後，就可以點擊界面下方的環境變數選項。

2.然後我們就會進入到環境變數窗口，我們在這個窗口下方系統變數中找到path的變數，然後我們滑鼠點擊選中之後，點擊窗口下方的編輯按鈕。

3. 接下來我們就會進入到編輯系統變數的窗口，我們在窗口下方便靚值的輸入欄的分號後面進行編輯，輸入D:\consul;。完成之後我們就可以點擊窗口下方的確定按鈕了。需要注意的是我們修改變數值的時候一定要在分號後面才可以進行修改，不然就會導致變數的損壞。

4.編輯完成之後我們就可以點擊鍵盤上的WINDOWS圖標鍵加上r鍵，打開運行窗口之後，在輸入欄中輸入cmd命令，然後敲擊回車運行命令。如果我們在界面中出現了一連串的英文就說明我們已經成功修改了，如果失敗了我們就需要重新進行設置。

5. 如果我們成功的進行配置之後我們就可以在最下方輸入以下的命令:

consul.exe agent -dev ，consul.exe agent -dev -client 192.168.xx.xx。命令輸入完成之後我們就已經可以成功使用了。

以上就是電腦consul環境變數的配置和使用方法。

⑽ f5和consul結合使用

兩者可以組合使用。
1、該客戶端提供一個服務，比如api或者mysql，另外一個客戶端就可以去發現指定服務的服務提供者。通過DNS或者HTTP應用程序可以容易找到所依賴的服務。
2、健康檢查consul可以提供健康檢查服務。這個信息可以監視集群的健康。可以用來避免將流量發送到不健康的主機。
3、存儲。應用程序可以使用consul的層級的儲存。比如動態配置，協調服務。直接可以用HTTPAPI來操作。