前言
上一篇簡單介紹了Consul，並使用開發模式（dev）進行流程演示，但在實際開發中需要考慮Consul的高可用和操作安全性，所以接着來聊聊集群和ACL的相關配置，涉及到的命令會在環境搭建過程中詳細介紹。
正文
關於集群，第一反應就是多搞幾台機器(或者容器等)，將其關聯在一塊，提供功能即可；在搭建集群環境之前，需要對幾個角色進行熟悉，因為在Consul中，它們至關重要。見下圖(以一個數據中心為例)：
- 數據中心(DataCenter)：Consul運行的節點集連接在一起稱為數據中心；在數據中心中，各個Consul節點可以以服務器(Server)或客戶端模式(Client)運行；為了保證可用性和高性能，通常一個數據中心內推薦3~5個服務器(不超過5個)，客戶端個數建議不要超過5000個(具體根據業務決定)。
- 客戶端模式(Client)：客戶端負責注冊服務、運行健康檢查並將相關RPC轉發給服務器，相對來說是無狀態的。Client+LAN gossip協議組成了一個數據中心中的節點集，通信效率高。
- 服務器模式(Server)：服務器包含客戶端的功能，每個Server還參與選舉，響應RPC查詢，轉發信息給ServerLeader等；另外還負責維護Consul的集群狀態(持久化)：包括其他服務器和客戶端的信息、哪些服務可供發現、哪些服務允許相互通信；每個Consul數據中心必須至少有一個服務器。
- 服務器領導者(Server Leader)：除了包含Server的功能外，還負責同步數據到各個Server；每一個集群中只能有一個ServerLeader，保證集群內數據一致。
在整個集群中是通過網絡進行關聯，需要多個端口實現對應功能，如上圖；端口簡介：
了解到Consul的架構及各個角色功能，接下來就是實操啦。
1. 搭建集群
在這里，就不搞那么多機器了，兩台搭集群，一台服務器模式，一台客戶端模式(電腦有限，不想搞那么多虛擬機)，原理是一樣的，主要還是着重說說過程：
1.1 啟動一個Server(就一台Server,那它肯定是Leader了)
這里演示在啟動節點前，將配置文件目錄和data創建好，如下：
使用命令啟動：
consul agent -server -bootstrap-expect 1 -datacenter=dc_zoe -config-dir=./config -data-dir ./data -node=s1 -ui -rejoin -bind=192.168.1.6 -client 0.0.0.0
啟動起來時包含一些節點信息，如下：
命令解析
- agent：Consul的核心進程，每個節點都需要代理的形式運行；
- -server：代表是Server模式，如果沒有-server就代表是Client模式；
- -bootstrap-expect：在一個數據中心中期望的Server的節點個數，直到啟動Server個數達到設置的個數時，集群才能起作用，並從中選舉出一個ServerLeader;
- -bootstrap：手動指定Server為Leader；當Server個數大於0時，該參數不能和-bootstrap-expect一起使用(以上命令中沒有用到)；
- -datacenter：指定數據中心的名稱；
- -config-dir：指定配置文件目錄，這里指定的是當前目錄下的config目錄，Consul會自動加載里面所有Json格式的配置文件(.json結尾)；
- -data-dir：指定節點運行時數據狀態保存的路徑，這里將其對應的數據保存在當前文件夾下的data目錄中；
- -node：指定節點的名稱，在集群中必須是唯一的，默認是主機名；
- -ui：使用默認UI界面，Consul提供一個UI項目，下載可以指定對應的目錄，使用-ui-dir 指定對應的UI目錄即可；
- -rejoin：忽略之前的斷開，重新啟動時會嘗試加入集群；
- -bind：指定綁定的地址，該地址通常用來在集群內部通訊，集群內的所有節點地址都必須正常通訊；
- -client：Consul服務監聽的地址，這個地址提供HTTP/DNS/RPC等服務，默認是127.0.0.1，所以外部不能訪問，UI通過IP地址也不能訪問；如果需要提供服務，將其指定為0.0.0.0即可。
- -encrypt：指定一個秘鑰，在通訊時進行加密，這個秘鑰可以通過
consul keygen生成，在同一個集群中，各節點必須使用相同的秘鑰；
以上列舉常用的參數，還有一些不太常用的，小伙伴如果用到去官網上查查(偷偷告訴小伙伴，參數還可以統一放在配置文件中哦)。
如果是多個Server，只需在每台機器上執行以上命令即可，根據Server數量，修改bootstrap-expect后面的數量即可，然后再改改bind后面的地址即可。
1.2 啟動一個Client
啟動一個Client和Server幾乎一樣，只是不用指定Server參數，默認就是客戶端模式，命令如下：
consul agent -datacenter=dc_zoe -config-dir=./config -data-dir ./data -node=c1 -bind=192.168.1.8 -client 0.0.0.0
這樣Client 就啟動起來了
如果是多個Client，在各台機器上執行以上命令即可，只是改改bind的地址即可。
1.3 將節點加入到集群中
上面只是將各節點啟動，如果是Server節點，不是Leader的話，會一直提示找不到Leader；如果是Client節點，就會提示找不到對應的Server節點；因為一個集群中至少得有一個Server，在Server中必須得要有且只有一個ServerLeader。所以節點啟動之后，下一步就是要將各節點加入到集群中，通常的做法是在各個節點上執行以下命令：
consul join 192.168.1.6 # 通常后面跟的地址是ServerLeader的地址
執行命令之后，對應的節點就加入到集群中了，可以通過UI看到節點：
也可以通過命令查看：
最終這樣一個簡單集群就搭建完成了，流程就是這樣，其余的就是節點個數的問題。
2. ACL配置
Consul使用 Access Control Lists（ACL-訪問控制列表）來保護對UI、API、CLI、服務通信和代理通信的訪問；ACL的核心是將規則分組為策略，然后將一個或多個策略與令牌相關聯。
Consul使用token的形式進行安全控制訪問，這里的token就是隨機的字符串，有了token就有對應的操作權限啦；就好比之前說到WebAPI接口加訪問控制一樣，通過一個授權token就可以訪問相關的接口資源。
配置ACL的前提是所有節點都需要將ACL啟用，然后還要一個bootstrap token，因為針對子權限(策略)生成token的時候需要用到，就好比MySQL中的root用戶一樣，只有有了root權限才能給其他用戶分配更多的權限。接下就以UI的訪問和Services的控制進行ACL配置演示，其他基本上都一樣，重點就是規划好策略規則。
首先在各節點啟動時將ACL啟用，在配置文件夾目錄中(這里目錄名是config)增加acl.hcl文件(每個節點都需要加)，內容如下：
acl = {
enabled = true
default_policy = "deny"
enable_token_persistence = true
}
參數說明：
- enabled=true 代表開啟ACL；
- default_policy=“deny”默認為allow，如果需要自定義權限，需要將其設置為deny；
- enable_token_persistence =true開啟token持久化，將token持久化到磁盤上；
這里需要注意一點，之前說配置目錄下的Json文件會被自動加載，其實還有hcl文件也會被自動加載，這里用hcl的形式演示一下。 配置文件准備好之后，重新啟動節點即可(集群中的所有節點都需要用上)，訪問UI試試，就會彈出如下界面：
點擊登錄，需要輸入一個Token，如果是在配置文件中配置，輸入配置的token即可，如果沒有配置，可以在運行時生成一個bootstrap token，在任意一個Server中執行consul acl bootstrap命令獲得該bootstrap token；Consul中token都很重要，需要保存好。
將生成的bootstrap token輸入在登錄框中，然后就可以正常獲取信息啦；
bootstrap token權限很大，不可能每個小伙伴都擁有，就像MySQL的root權限一樣，只能有個別的人知道。其他用戶的權限需單獨控制；Consul也是如此，針對不同權限策略，生成對應的token，使用這個token就只能訪問或操作對應權限范圍內的資源。
UI方式配置
ACL的配置其他token可以通過命令的形式，也可以通過UI界面的形式(因為現在有bootstrap token超級權限)，這里通過UI的形式很方便的，三步走：
-
創建策略：
策略其他信息基本上沒啥說的，主要是規則(Rules)的配置，通常主要針對節點(node)、服務(service)、鍵值對(K/V)進行配置，可以模糊指定，也可以具體指定，如下：
node_prefix ""：節點前綴為空，代表所有的節點都使用策略；
service_prefix ""：服務前綴為空，代表所有的服務都使用策略；
service "Code6688Name"：指定對應的服務使用策略；
key_prefix "redis/"：只對前綴有"redis/"的key使用對應策略；
key "dashboard-app"：指定對應的key使用策略；
以上指定策略的范圍是比較常用的方式，具體可以參照官網；
規則中關於策略(policy)通常有以下幾種：
read：只能查詢；
write：可查可寫；
deny：不能讀不能寫；
其他細節可以參考ACL官方配置文檔。
-
根據策略生成token:
有了策略之后，接下來就要針對策略生成對應的token啦，如下：
在對應彈出框中輸入對應的信息即可，如下：
保存之后就生成對應的token，可以進入到詳細頁看到生成的token，直接將token給別人用即可。
-
使用token：
ui測試，直接將token發給其他小伙伴，登錄時輸入即可,如果是其他操作，帶上token即可；對於自己界面測試，切換一下token就可以啦，如下：
切換之后，界面中除了node能查出信息，其他都不能使用，操作Key/Value，還報如下錯誤：
在服務注冊或服務發現中使用該token，也不能注冊和查詢服務成功，如下：
如果是用配置文件進行服務注冊，在配置文件中也要指定token，否則注冊服務不成功，如下：
服務發現也是一個道理：
直接使用HTTP API也是一樣需要帶上token：
命令方式
UI配置的這種形式是不是夠直接，命令的方式我就不演示的了吧，步驟的一樣，只是全靠命令即可，如下：
-
編寫規則文件；
-
根據規則文件生成策略；
-
根據策略生成token;
-
使用token；
有了token就可以能干對應權限范圍的事了，具體使用就不介紹了，不管是UI、還是API查詢，小伙伴自己體驗一下吧（上面已經說到）。
注： 以上步驟中開啟ACL之后，沒有統一配置好超級管理員的boostrap token，所以每次操作都需要帶上-token參數。
總結
集群再加ACL訪問控制配置就先說到這啦，文中更主要的是提供相關思路，並沒有把所有權限配置方式舉例演示(比較多)，剩下小伙伴自己嘗試吧；通過上一篇(來，Consul 服務發現入個門(一看就會的那種))的使用，再加上這篇的集群環境和ACL配置思路介紹，小伙伴應該日常使用沒問題了吧；其余的功能根據業務需要再去研究吧，我如果有對應的應用場景，依然會第一時間分享。下期聊聊網關吧~~~
感謝小伙伴點贊、轉發和評論
一個被程序搞丑的帥小伙，關注"Code綜藝圈"，跟我一起學~~~
