⑴ consul 怎麼移除失敗的服務
Docker 1.9.0開始支持多主機網路（multi-host networking）。我們可以通過OVNOpen vSwitch virtual network）來將Docker的網路和Open vSwitch結合起來。
簡介
對於OVN和Docker的多主機網路（multi-host networking），Docker需要分布式鍵值對存儲的支持。假設我們這里採用consul來提供分布式鍵值對存儲，並且你的主機IP地址為$HOST_IP。用戶可以使用下面的命令來啟動Docker進程：
docker daemon --cluster-store=consul://127.0.0.1:8500 /
--cluster-advertise=$HOST_IP:0
OVN為容器提供了網路虛擬化技術。OVN和Docker的結合使用存在兩種模式—underlay模式和overlay模式。
在underlay模式下，OVN要求配置OpenStack來提供容器網路。在這個模式下，用戶可以創建邏輯網路，並且讓運行在虛擬機中的容器、獨立的虛擬機（沒有容器運行在其中）和物理機器連接到同一個邏輯網路上。這是一種多租戶、多主機的解決辦法。
在overlay模式下，OVN可以為運行跨主機的容器們提供一個邏輯網路。這是一種單租戶（是否能擴展到多租戶取決於安全特性）、多主機的解決辦法。在這種模式下，你並不需要預創建好的OpenStack。
值得注意的是，用戶必須在他想要運行容器的虛擬機或主機上安裝並運行Open vSwitch。
Overlay 模式
Overlay模式下，需要Open vSwitch 2.5版本或後續版本的支持。
啟動核心模塊
OVN架構中會有一個核心的模塊來存儲網路信息。因此你需要在你其中一台主機（IP地址為$CENTRAL_IP，並且已經安裝和啟動了Open vSwitch）上啟動相關的核心服務。
首先我們讓ovsdb-server監聽一個TCP埠：
ovs-appctl -t ovsdb-server ovsdb-server/add-remote ptcp:6640
接下來，啟動ovn-northd後台進程。這個進程負責將來自Docker的網路信息（存儲在OVN_Northbound 資料庫中）轉換成邏輯流存儲於OVN_Southbound資料庫。
/usr/share/openvswitch/scripts/ovn-ctl start_northd
一次性配置
在每一個你打算創建容器的主機上，你需要運行以下的命令（如果你的OVS資料庫被清空，你需要再次運行這個命令。除此之外，重復運行這個命令都是沒有任何影響的）。
其他的主機可以通過$LOCAL_IP地址來訪問到這個主機，它就相當於本地通道的端點。
$ENCAP_TYPE是指用戶想使用的通道的類型。它可以是地geneve逗或者地stt逗。（注意，你的內核需要支持以上兩個類型，用戶可以通過運行以下命令來檢測內核是否支持以上類型：逗lsmod | grep $ENCAP_TYPE"）
ovs-vsctl set Open_vSwitch . external_ids:ovn-remote="tcp:$CENTRAL_IP:6640"
external_ids:ovn-encap-ip=$LOCAL_IP external_ids:ovn-encap-type="$ENCAP_TYPE"
最後，啟動ovn-controller（你需要在每一次啟動時運行以下命令）：
/usr/share/openvswitch/scripts/ovn-ctl start_controller
啟動Open vSwitch網路驅動
在默認情況下，Docker使用Linux網橋，但它支持外擴展。為了替換Linux網橋，我們需要先啟動Open vSwitch驅動。
Open vSwitch驅動使用了python Flask模塊來監聽Docker的網路API請求。因此，用戶需要先安裝Python 的Flask模塊。
easy_install -U pip
pip install Flask
在每一個你想要創建容器的主機上啟動Open vSwitch驅動：
ovn-docker-overlay-driver --detach
Docker內部包含了一些模塊，這些模塊擁有類似於OVN的邏輯交換機和邏輯埠的概念。請讀者仔細閱讀Docker的文檔來查找相關的命令。這里我們給出了一些案例：
NID=`docker network create -d openvswitch --subnet=192.168.1.0/24 foo`
docker network ls
你也可以通過以下命令從OVN的northbound資料庫中查找到這個邏輯交換機：
ovn-nbctl --db=tcp:$CENTRAL_IP:6640 lswitch-list
docker run -itd --net=foo --name=busybox busybox
ovn-nbctl --db=tcp:$CENTRAL_IP:6640 lport-list $NID
docker network create -d openvswitch --subnet=192.168.2.0/24 bar
docker network connect bar busybox
用戶可以刪除邏輯埠，或者將它們從運行容器上分離出來：
docker network disconnect bar busybox
docker network rm bar
Underlay模式
在這個模式下，OVN要求用戶預安裝好OpenStack。
用戶也可以刪除邏輯交換機：
用戶也可以創建一個邏輯埠，並將它添加到一個運行中的容器上：
顯示所有的邏輯埠
Docker現在並沒有一個CLI命令來羅列所有的邏輯埠，但是你可以從OVN的資料庫中找到它們：
Docker創建邏輯埠，並且將這個埠附加到邏輯網路上
比如說，將一個邏輯埠添加到容器busybox的逗foo地網路上：
顯示已有邏輯交換機
創建用戶自己的邏輯交換機
下面的命令創建了一個名為地foo逗的邏輯交換機，它的網段為地192.168.1.0/24地：
一次性配置
一個OpenStack的租戶創建了一個虛擬機，這個虛擬機擁有單張或多張網卡。如果租戶想要發送虛擬機中容器的網路包，他需要獲取這些網卡的port-id。port-id可以通過以下命令獲得：
nova list
然後運行：
neutron port-list --device_id=$id
在虛擬機中，下載OpenStack的RC文件，這些文件包含了租戶的信息（我們用openrc.sh來指代它）。編輯這個文件，並且將之前獲取到的port-id以 export OS_VIF_ID=$port-id的格式加入到文件中。文件的內容如下：
!/bin/bash
export OS_AUTH_URL=
export OS_TENANT_ID=
export OS_TENANT_NAME="demo"
export OS_USERNAME="demo"
export OS_VIF_ID=e798c371-85f4-4f2d-ad65-d09dd1d3c1c9
創建Open vSwitch網橋
如果用戶的虛擬機只有一個乙太網介面（比如說eth0），你需要將這個設備作為一個埠加入到Open vSwitch的地breth0地網橋上，並且移除它的IP地址，將其他相關的信息轉移到這個網橋上。（如果有多個網路介面，用戶自己創建Open vSwitch網橋，並且添加介面到網橋上）
如果你使用DHCP來獲取IP地址，你需要關閉監聽eth0的DHCP客戶端，並且開啟一個監聽Open vSwitch breth0網橋的DHCP客戶端。
你可以讓以上的步驟持久化，比如說你的虛擬機是Debian/Ubuntu，你可以參考 openvswitch-switch.README.Debian，如果你的虛擬機基於RHEL，你可以閱讀 README.RHEL完成持久化。
開啟Open vSwitch網路驅動
Open vSwitch驅動使用了Python Flask模塊來監聽Docker的網路API調用。這個驅動還使用了OpenStack的python-neutronclient庫。因此，如果你的主機還沒有安裝Python Flask或者python-neutronclient，你需要使用以下命令來安裝：
easy_install -U pip
pip install python-neutronclient
pip install Flask
運行openrc文件：
../openrc.sh
開啟網路驅動，並且提供OpenStack租戶的密碼：
ovn-docker-underlay-driver --bridge breth0 --detach
從現在開始，你可以使用和overlay模式類似的Docker命令了。請閱讀逗man ovn-architecture地來理解OVN的技術細節。
⑵ 怎樣使用Spring Cloud跨雲管理
使用Spring Cloud構建實際的微服務架構。
基本概念:
使用Docker進行集成測試
混合持久化
微服務架構
服務發現
API網關
Docker
使用Docker對每一個服務進行構建和部署。使用Docker Compose在一個開發機上進行端到端的集成測試。
混合持久化
混合持久化其實就是說使用多種資料庫來存儲。不同的微服務實例都會使用它們自己的資料庫，並通過REST服務或者消息匯流排來通信，舉個例子，你可以使用基於以下資料庫來構建微服務：
Neo4j(圖形化)
MongoDB(文檔化)
MySQL(關聯)
微服務架構
這個例子演示了如何使用微服務創建一個新的應用。由於在項目中的每一個微服務只有一個單一的父項目。開發者為此得到的收益是可以在本機上運行和開發每一個微服務。添加一個新的微服務非常簡單，當發現微服務時將會自動發現運行時的集群環境上。
Service Discovery
項目中包含兩個發現服務，一個在Netflix Eureka，另一個使用了
Consul from Hashicorp。多種發現服務提供了多種選擇，一個是使用(Consul)來做DNS服務集群，另一個是(Consul)基於代理的API 網關。
API 網關
每一個微服務都關聯Eureka，在整個集群中檢索API路由。使用這個策略，每一個在集群上運行的微服務只需要通過一個共同的API網關進行負載均衡和暴露介面，每一個服務也會自動發現並將路由請求轉發到自己的路由服務中。這個代理技術有助於開發用戶界面，作為平台完整的 API通過自己的主機映射為代理服務。
Docker 實例
下面的實例將會通過Maven來構建，使用Docker為每一個微服務構建容器鏡像。我們可以很優雅的使用Docker Compose在我們自己的主機上搭建全部的微服務集群。
開始構建
在這之前，請先移步至項目的GitHub 倉庫。
https://github.com/kbastani/spring-cloud-microservice-example
克隆或者fork這個項目並且把源碼下載到自己的電腦上。下載完畢後，你需要使用Maven和Docker來編譯和構建本地的容器鏡像。
下載Docker
首先，如果你還沒有Docker請先下載它。可以跟隨這個指南來獲取Docker:https://docs.docker.com/installation/，然後在開發機上安裝並運行。
當然你也需要安裝Docker Compose(https//docs.docker.com/compose/)，這個指南將會幫到你:https://docs.docker.com/compose/install/。
環境要求
能夠運行實常式序，需要在你的開發機上安裝下面的軟體：
Maven 3
java 8
Docker
Docker Compose
構建項目
通過命令行方式來構建當前項目，在項目的根目錄中運行如下的命令：
$ mvn clean install
項目將會根據pom.xml中的每一個項目聲明中下載相應的依賴jar包。每一個服務都將會被構建，同時Maven的Docker插件將會自動從本地Docker Registry中構建每一個容器鏡像。Docker將會在構建成功後，根據命令行運行mvn clean install來清除相應的資源。
⑶ 【知識總結】6.服務注冊發現框架比較(Consul/Zookeeper/etcd/Eureka)
服務發現就是服務提供者將自己提供的地址post或者update到服務中介，服務消費者從服務中介那裡get自己想要的服務的地址。
但是有兩個問題：
第一個問題：如果有一個服務提供者宕機，那麼中介的key/value中會有一個不能訪問的地址，該怎麼辦？
心跳機制： 服務提供者需要每隔5秒左右向服務中介匯報存活，服務中介將服務地址和匯報時間記錄在zset數據結構的value和score中。服務中介需要每隔10秒左右檢查zset數據結構，踢掉匯報時間嚴重落後的地址。這樣就可以保證服務列表中地址的有效性。
第二個問題是服務地址變動時如何通知消費者。有兩種解決方案。
第一種是輪詢，消費者每隔幾秒查詢服務列表是否有改變。如果服務地址很多，查詢會很慢。這時候可以引入服務版本號機制，給每個服務提供一個版本號，在服務變動時，遞增這個版本號。消費者只需要輪詢這個版本號的變動即可知道服務列表是否發生了變化。
第二種是採用pubsub。這種方式及時性要明顯好於輪詢。缺點是每個pubsub都會佔用消費者一個線程和一個額外的連接。為了減少對線程和連接的浪費，我們使用單個pubsub廣播全局版本號的變動。所謂全局版本號就是任意服務列表發生了變動，這個版本號都會遞增。接收到版本變動的消費者再去檢查各自的依賴服務列表的版本號是否發生了變動。這種全局版本號也可以用於第一種輪詢方案。
CAP理論
CAP理論是分布式架構中重要理論
關於P的理解，我覺得是在整個系統中某個部分，掛掉了，或者宕機了，並不影響整個系統的運作或者說使用，而可用性是，某個系統的某個節點掛了，但是並不影響系統的接受或者發出請求，CAP 不可能都取，只能取其中2個。原因是
（1）如果C是第一需求的話，那麼會影響A的性能，因為要數據同步，不然請求結果會有差異，但是數據同步會消耗時間，期間可用性就會降低。
（2）如果A是第一需求，那麼只要有一個服務在，就能正常接受請求，但是對與返回結果變不能保證，原因是，在分布式部署的時候，數據一致的過程不可能想切線路那麼快。
（3）再如果，同事滿足一致性和可用性，那麼分區容錯就很難保證了，也就是單點，也是分布式的基本核心，好了，明白這些理論，就可以在相應的場景選取服務注冊與發現了。
平時經常用到的服務發現的產品進行下特性的對比，首先看下結論：
補充：
（1）運維和開發如果是 Java 更熟，也更多 Java 的應用，那毫無疑問應該用 ZK；如果是搞 Go 的，那麼還是 etcd 吧，畢竟有時候遇到問題還是要看源碼的。
（2）在創建一百萬個或更多鍵時，etcd可以比Zookeeper或Consul穩定地提供更好的吞吐量和延遲。此外，它實現了這一目標，只有一半的內存，顯示出更高的效率。但是，還有一些改進的餘地，Zookeeper設法通過etcd提供更好的最小延遲，代價是不可預測的平均延遲。
（3）
一致性協議： etcd 使用 Raft 協議，Zookeeper 使用 ZAB（類PAXOS協議），前者容易理解，方便工程實現；
運維方面：etcd 方便運維，Zookeeper 難以運維；
數據存儲：etcd 多版本並發控制（MVCC）數據模型 ， 支持查詢先前版本的鍵值對
項目活躍度：etcd 社區與開發活躍，Zookeeper 感覺已經快死了；
API：etcd 提供 HTTP+JSON, gRPC 介面，跨平台跨語言，Zookeeper 需要使用其客戶端；
訪問安全方面：etcd 支持 HTTPS 訪問，Zookeeper 在這方面缺失；
與 Eureka 有所不同，Apache Zookeeper 在設計時就緊遵CP原則，即任何時候對 Zookeeper 的訪問請求能得到一致的數據結果，同時系統對網路分割具備容錯性，但是 Zookeeper 不能保證每次服務請求都是可達的。
從 Zookeeper 的實際應用情況來看，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 集群中的 Leader 宕機了，該集群就要進行 Leader 的選舉，又或者 Zookeeper 集群中半數以上伺服器節點不可用（例如有三個節點，如果節點一檢測到節點三掛了 ，節點二也檢測到節點三掛了，那這個節點才算是真的掛了），那麼將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。
當然，在大多數分布式環境中，尤其是涉及到數據存儲的場景，數據一致性應該是首先被保證的，這也是 Zookeeper 設計緊遵CP原則的另一個原因。
但是對於服務發現來說，情況就不太一樣了，針對同一個服務，即使注冊中心的不同節點保存的服務提供者信息不盡相同，也並不會造成災難性的後果。
因為對於服務消費者來說，能消費才是最重要的，消費者雖然拿到可能不正確的服務實例信息後嘗試消費一下，也要勝過因為無法獲取實例信息而不去消費，導致系統異常要好（淘寶的雙十一，京東的618就是緊遵AP的最好參照）。
當master節點因為網路故障與其他節點失去聯系時，剩餘節點會重新進行leader選舉。問題在於，選舉leader的時間太長，30~120s，而且選舉期間整個zk集群都是不可用的，這就導致在選舉期間注冊服務癱瘓。
在雲部署環境下， 因為網路問題使得zk集群失去master節點是大概率事件，雖然服務能最終恢復，但是漫長的選舉事件導致注冊長期不可用是不能容忍的。
Spring Cloud Netflix 在設計 Eureka 時就緊遵AP原則。Eureka是在Java語言上，基於Restful Api開發的服務注冊與發現組件，由Netflix開源。遺憾的是，目前Eureka僅開源到1.X版本，2.X版本已經宣布閉源。
Eureka Server 也可以運行多個實例來構建集群，解決單點問題，但不同於 ZooKeeper 的選舉 leader 的過程，Eureka Server 採用的是Peer to Peer 對等通信。這是一種去中心化的架構，無 master/slave 之分，每一個 Peer 都是對等的。在這種架構風格中，節點通過彼此互相注冊來提高可用性，每個節點需要添加一個或多個有效的 serviceUrl 指向其他節點。每個節點都可被視為其他節點的副本。
在集群環境中如果某台 Eureka Server 宕機，Eureka Client 的請求會自動切換到新的 Eureka Server 節點上，當宕機的伺服器重新恢復後，Eureka 會再次將其納入到伺服器集群管理之中。當節點開始接受客戶端請求時，所有的操作都會在節點間進行復制（replicate To Peer）操作，將請求復制到該 Eureka Server 當前所知的其它所有節點中。
當一個新的 Eureka Server 節點啟動後，會首先嘗試從鄰近節點獲取所有注冊列表信息，並完成初始化。Eureka Server 通過 getEurekaServiceUrls() 方法獲取所有的節點，並且會通過心跳契約的方式定期更新。
默認情況下，如果 Eureka Server 在一定時間內沒有接收到某個服務實例的心跳（默認周期為30秒），Eureka Server 將會注銷該實例（默認為90秒， eureka.instance.lease-expiration-ration-in-seconds 進行自定義配置）。
當 Eureka Server 節點在短時間內丟失過多的心跳時，那麼這個節點就會進入自我保護模式。
Eureka的集群中，只要有一台Eureka還在，就能保證注冊服務可用（保證可用性），只不過查到的信息可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鍾內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與注冊中心出現了網路故障，此時會出現以下幾種情況：
Eureka不再從注冊表中移除因為長時間沒有收到心跳而過期的服務；
Eureka仍然能夠接受新服務注冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）；
當網路穩定時，當前實例新注冊的信息會被同步到其它節點中；
因此，Eureka可以很好的應對因網路故障導致部分節點失去聯系的情況，而不會像zookeeper那樣使得整個注冊服務癱瘓。
Consul 是 HashiCorp 公司推出的開源工具，用於實現分布式系統的服務發現與配置。Consul 使用 Go 語言編寫，因此具有天然可移植性（支持Linux、windows和Mac OS X）。
Consul採用主從模式的設計，使得集群的數量可以大規模擴展，集群間通過RPC的方式調用(HTTP和DNS)。
Consul 內置了服務注冊與發現框架、分布一致性協議實現、健康檢查、Key/Value 存儲、多數據中心方案，不再需要依賴其他工具（比如 ZooKeeper 等），使用起來也較為簡單。
Consul 遵循CAP原理中的CP原則，保證了強一致性和分區容錯性，且使用的是Raft演算法，比zookeeper使用的Paxos演算法更加簡單。雖然保證了強一致性，但是可用性就相應下降了，例如服務注冊的時間會稍長一些，因為 Consul 的 raft 協議要求必須過半數的節點都寫入成功才認為注冊成功 ；在leader掛掉了之後，重新選舉出leader之前會導致Consul 服務不可用。
默認依賴於SDK
Consul本質上屬於應用外的注冊方式，但可以通過SDK簡化注冊流程。而服務發現恰好相反，默認依賴於SDK，但可以通過Consul Template（下文會提到）去除SDK依賴。
Consul Template
Consul，默認服務調用者需要依賴Consul SDK來發現服務，這就無法保證對應用的零侵入性。
所幸通過 Consul Template ，可以定時從Consul集群獲取最新的服務提供者列表並刷新LB配置（比如nginx的upstream），這樣對於服務調用者而言，只需要配置一個統一的服務調用地址即可。
Consul強一致性(C)帶來的是：
Eureka保證高可用(A)和最終一致性：
其他方面，eureka就是個servlet程序，跑在servlet容器中; Consul則是go編寫而成。
etcd是一個採用http協議的分布式鍵值對存儲系統，因其易用，簡單。很多系統都採用或支持etcd作為服務發現的一部分，比如kubernetes。但正事因為其只是一個存儲系統，如果想要提供完整的服務發現功能，必須搭配一些第三方的工具。
比如配合etcd、Registrator、confd組合，就能搭建一個非常簡單而強大的服務發現框架。但這種搭建操作就稍微麻煩了點，尤其是相對consul來說。所以etcd大部分場景都是被用來做kv存儲，比如kubernetes。
etcd 比較多的應用場景是用於服務發現，服務發現 (Service Discovery) 要解決的是分布式系統中最常見的問題之一，即在同一個分布式集群中的進程或服務如何才能找到對方並建立連接。和 Zookeeper 類似，etcd 有很多使用場景，包括：
配置管理
服務注冊發現
選主
應用調度
分布式隊列
分布式鎖
按照官網給出的數據， 在 2CPU，1.8G 內存，SSD 磁碟這樣的配置下，單節點的寫性能可以達到 16K QPS, 而先寫後讀也能達到12K QPS。這個性能還是相當可觀。
etcd 提供了 etcdctl 命令行工具 和 HTTP API 兩種交互方法。etcdctl命令行工具用 go 語言編寫，也是對 HTTP API 的封裝，日常使用起來也更容易。所以這里我們主要使用 etcdctl 命令行工具演示。
（1）注冊中心ZooKeeper、Eureka、Consul 、Nacos對比
https://zhuanlan.hu.com/p/165217227?utm_source=wechat_session
（2）常用的服務發現對比（Consul、zookeeper、etcd、eureka）
https://blog.csdn.net/gaohe7091/article/details/101197107
⑷ 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入門篇
consul是google開源的一個使用go語言開發的服務發現、配置管理中心服務。內置了服務注冊與發現框架（類似zookeeper）、分布一致性協議實現、健康檢查、Key/Value存儲、多數據中心方案。服務部署簡單，只有一個可運行的二進制的包。每個節點都需要運行agent，他有兩種運行模式server和client。每個節點為以下三種狀態的一種：
上圖來源於 Consul 官網，很好的解釋了 Consul 的工作原理。consul是一個服務管理軟體，主要功能如下：
有些人可能對服務注冊和發現還沒有概念，有些人可能使用過其他服務發現的工具，比如 ZooKeeper，etcd，會有一些先入為主的經驗。本文談一下 Consul 做服務發現的實踐和原理。
下面這張圖描述了服務發現的完整流程，先大致看一下：
首先需要有一個正常的 Consul 集群，有 Server，有 Leader。這里在伺服器 Server1、Server2、Server3 上分別部署了 Consul Server。
假設他們選舉了 Server2 上的 Consul Server 節點為 Leader。這些伺服器上最好只部署 Consul 程序，以盡量維護 Consul Server 的穩定。
然後在伺服器 Server4 和 Server5 上通過 Consul Client 分別注冊 Service A、B、C，這里每個 Service 分別部署在了兩個伺服器上，這樣可以避免 Service 的單點問題。
服務注冊到 Consul 可以通過 HTTP API（8500 埠）的方式，也可以通過 Consul 配置文件的方式。
Consul Client 可以認為是無狀態的，它將注冊信息通過 RPC 轉發到 Consul Server，服務信息保存在 Server 的各個節點中，並且通過 Raft 實現了強一致性。
最後在伺服器 Server6 中 Program D 需要訪問 Service B，這時候 Program D 首先訪問本機 Consul Client 提供的 HTTP API，本機 Client 會將請求轉發到 Consul Server。
Consul Server 查詢到 Service B 當前的信息返回，最終 Program D 拿到了 Service B 的所有部署的 IP 和埠，然後就可以選擇 Service B 的其中一個部署並向其發起請求了。
如果服務發現採用的是 DNS 方式，則 Program D 中直接使用 Service B 的服務發現域名，域名解析請求首先到達本機 DNS 代理，然後轉發到本機 Consul Client，本機 Client 會將請求轉發到 Consul Server。
Consul Server 查詢到 Service B 當前的信息返回，最終 Program D 拿到了 Service B 的某個部署的 IP 和埠。
圖中描述的部署架構筆者認為是最普適最簡單的方案，從某些默認配置或設計上看也是官方希望使用者採用的方案，比如 8500 埠默認監聽 127.0.0.1，當然有些同學不贊同，後邊會提到其他方案。
consul必須啟動agent才能使用，有兩種啟動模式server和client，還有一個官方自帶的web ui。server用與持久化服務信息，集群官方建議3或5個節點。client只用與於server交互。ui可以查看集群情況的。
server模式啟動如下：
參數解釋：
client啟動如下：
client節點可以有多個，自己根據服務指定即可。
ui啟動如下:
參數解釋：
集群創建完成後：
使用一些常用的命令檢查集群的狀態：
可以在raft：stat看到此節點的狀態是Fllower或者leader
新加入一個節點有幾種方式；
訪問ui：
http://192.168.1.198:8500/ui
埠：
8300：consul agent服務relplaction、rpc（client-server）
8301：lan gossip
8302：wan gossip
8500：http api埠
8600：DNS服務埠
輸入 consul agent -dev
在瀏覽器中輸入 www.localhost:8500 就可以啟動web查看
consul注冊服務，有三種方式，
方式一：通過配置文件的方式靜態注冊
創建文件夾/etc/consul.d
.d代表有許多配置文件在裡面
vim /etc/consul.d/jetty.json 內容如下：
重啟consul，並將配置文件的路徑給consul（指定參數：-config-dir /etc/consul.d）
方式二：通過HTTP API介面來動態注冊
直接調用/v1/agent/service/register介面注冊即可，需要注意的是：http method為PUT提交方式。如：
注意，這種方式，和上面的注冊方式有一點不一樣，body的參數，是上面service的值，這點需要注意
方式三：使用程序實現服務的注冊和發現（Java）
首先加入consul client的依賴
服務發現
consul支持兩種方式實現服務發現，一種是通過http API來查詢有哪些服務，另外一種是通過consul agent 自帶的DNS（8600埠），域名是以NAME.service.consul的形式給出，NAME即在定義的服務配置文件中，服務的名稱。DNS方式可以通過check的方式檢查服務。
服務間的通信協議
Consul使用gossip協議管理成員關系、廣播消息到整個集群，他有兩個gossip pool（LAN pool和WAN pool），LAN pool是同一個數據中心內部通信的，WAN pool是多個數據中心通信的，LAN pool有多個，WAN pool只有一個。
https://www.toutiao.com/a6639493728086000142/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1×tamp=1546144777&app=news_article&utm_source=weixin&iid=55667270026&utm_medium=toutiao_android&group_id=6639493728086000142
⑹ consul修改默認配置後執行命令失效
創建一個 bootstrap.properties 配置文件來配置consul的配置中心相關配置。
consul的配置中心功能可使用，在bootstrap.properties 配置文件中設置， spring.cloud.consul.config.enabled=false 。
僅使用consul的服務注冊與發現功能，pom文件中刪除spring-cloud-consul-config依賴。僅使用consul的服務注冊與發現功能
⑺ 【實踐】2.Prometheus命令和配置詳解
Prometheus配置方式有兩種：
（1）命令行，用來配置不可變命令參數，主要是Prometheus運行參數，比如數據存儲位置
（2）配置文件，用來配置Prometheus應用參數，比如數據採集，報警對接
不重啟進程配置生效方式也有兩種：
（1）對進程發送信號SIGHUP
（2）HTTP POST請求，需要開啟--web.enable-lifecycle選項curl -X POST http://192.168.66.112:9091/-/reload
配置文件格式是yaml格式，說明：
.yml或者.yaml 都是 yaml格式的文件，
yaml格式的好處: 和json交互比較容易
python/go/java/php 有yaml格式庫，方便語言之間解析,並且這種格式存儲的信息量很大。
命令行可用配置可通過prometheus -h來查看。
配置文件使用yml格式，配置文件中一級配置項如下，說明參考#備注內容。
配置文件中通用欄位值格式
<boolean>: 布爾類型值為true和false
<scheme>: 協議方式包含http和https
原始配置文件內容：
全局默認的數據拉取間隔
全局默認的單次數據拉取超時，當報context deadline exceeded錯誤時需要在特定的job下配置該欄位。
全局默認的規則(主要是報警規則)拉取間隔
該服務端在與其他系統對接所攜帶的標簽
該欄位配置與Alertmanager進行對接的配置
樣例：
上面的配置中的 alert_relabel_configs 是指警報重新標記在發送到Alertmanager之前應用於警報。 它具有與目標重新標記相同的配置格式和操作，外部標簽標記後應用警報重新標記，主要是針對集群配置。
這個設置的用途是確保具有不同外部label的HA對Prometheus服務端發送相同的警報信息。
Alertmanager 可以通過 static_configs 參數靜態配置，也可以使用其中一種支持的服務發現機制動態發現，我們上面的配置是靜態的單實例。
此外， relabel_configs 允許從發現的實體中選擇 Alertmanager，並對使用的API路徑提供高級修改，該路徑通過 __alerts_path__ 標簽公開。
完成以上配置後，重啟Prometheus服務，用以載入生效，也可以使用熱載入功能，使其配置生效。然後通過瀏覽器，訪問 http://192.168.1.220:19090/alerts 就可以看 inactive pending firing 三個狀態，沒有警報信息是因為我們還沒有配置警報規則 rules 。
這里定義和prometheus集成的alertmanager插件，用於監控報警。後續會單獨進行alertmanger插件的配置、配置說明、報警媒介以及route路由規則記錄。
此項配置和 scrape_configs 欄位中 relabel_configs 配置一樣，用於對需要報警的數據進行過濾後發向 Alertmanager
說明
relabel-configs的配置允許你選擇你想抓取的目標和這些目標的標簽是什麼。所以說如果你想要抓取這種類型的伺服器而不是那種，可以使用relabel_configs
相比之下，metric_relabel_configs是發生在抓取之後，但在數據被插入存儲系統之前使用。因此如果有些你想過濾的指標，或者來自抓取本身的指標（比如來自/metrics頁面）你就可以使用metric_relabel_configs來處理。
該項目主要用來配置不同的 alertmanagers 服務，以及Prometheus服務和他們的鏈接參數。 alertmanagers 服務可以靜態配置也可以使用服務發現配置。Prometheus以pushing 的方式向alertmanager傳遞數據。
alertmanager 服務配置和target配置一樣，可用欄位如下
這個主要是用來設置告警規則，基於設定什麼指標進行報警（類似觸發器trigger）。這里設定好規則以後，prometheus會根據全局global設定的evaluation_interval參數進行掃描載入，規則改動後會自動載入。其報警媒介和route路由由alertmanager插件實現。
樣例：
"first_rules.yml"樣例：
Prometheus 支持兩種類型的 Rules ，可以對其進行配置，然後定期進行運算：recording rules 記錄規則 與 alerting rules 警報規則，規則文件的計算頻率與警報規則計算頻率一致，都是通過全局配置中的 evaluation_interval 定義。
不論是recording rules還是alerting rules都要在組裡面。
要在Prometheus中使用Rules規則，就必須創建一個包含必要規則語句的文件，並讓Prometheus通過Prometheus配置中的rule_files欄位載入該文件，前面我們已經講過了。 其實語法都一樣，除了 recording rules 中的收集的指標名稱 record: <string> 欄位配置方式略有不同，其他都是一樣的。
配置範例：
recording rules 是提前設置好一個比較花費大量時間運算或經常運算的表達式，其結果保存成一組新的時間序列數據。當需要查詢的時候直接會返回已經計算好的結果，這樣會比直接查詢快，同時也減輕了PromQl的計算壓力，同時對可視化查詢的時候也很有用，可視化展示每次只需要刷新重復查詢相同的表達式即可。
在配置的時候，除卻 record: <string> 需要注意，其他的基本上是一樣的，一個 groups 下可以包含多條規則 rules ，Recording 和 Rules 保存在 group 內，Group 中的規則以規則的配置時間間隔順序運算，也就是全局中的 evaluation_interval 設置。
配置範例：
上面的規則其實就是根據 record 規則中的定義，Prometheus 會在後台完成 expr 中定義的 PromQL 表達式周期性運算，以 job 為維度使用 sum 聚合運算符 計算 函數rate 對http_requests_total 指標區間 10m 內的增長率，並且將計算結果保存到新的時間序列 job:http_requests_total:rate10m 中， 同時還可以通過 labels 為樣本數據添加額外的自定義標簽，但是要注意的是這個 lables 一定存在當前表達式 Metrics 中。
模板是在警報中使用時間序列標簽和值展示的一種方法，可以用於警報規則中的注釋（annotation）與標簽（lable）。模板其實使用的go語言的標准模板語法，並公開一些包含時間序列標簽和值的變數。這樣查詢的時候，更具有可讀性，也可以執行其他PromQL查詢 來向警報添加額外內容，ALertmanager Web UI中會根據標簽值顯示器警報信息。
{{ $lable.<lablename>}} 可以獲取當前警報實例中的指定標簽值
{{ $value }} 變數可以獲取當前PromQL表達式的計算樣本值。
調整好rules以後，我們可以使用 curl -XPOST http://localhost:9090/-/reload 或者 對Prometheus服務重啟，讓警報規則生效。
這個時候，我們可以把閾值調整為 50 來進行故障模擬操作，這時在去訪問UI的時候，當持續1分鍾滿足警報條件，實際警報狀態已轉換為 Firing，可以在 Annotations中看到模板信息 summary 與 description 已經成功顯示。
規則檢查
拉取數據配置，在配置欄位內可以配置拉取數據的對象(Targets)，job以及實例
定義job名稱，是一個拉取單元。每個job_name都會自動引入默認配置如
這些也可以在單獨的job中自定義
服務端拉取過來的數據也會存在標簽，配置文件中也會有標簽，這樣就可能發生沖突。
true就是以抓取數據中的標簽為准
false就會重新命名抓取數據中的標簽為「exported」形式，然後添加配置文件中的標簽
切換抓取數據所用的協議
定義可選的url參數
每次抓取數據請求的認證信息
password和password_file互斥只可以選擇其一
bearer_token和bearer_token_file互斥只可以選擇其一
抓取ssl請求時證書配置
通過代理去主去數據
Prometheus支持多種服務現工具，詳細配置這里不再展開
更多參考官網： https://prometheus.io/docs/prometheus/latest/configuratio n/configuration/
服務發現來獲取抓取目標為動態配置，這個配置項目為靜態配置，靜態配置為典型的targets配置，在改配置欄位可以直接添加標簽
採集器所採集的數據都會帶有label，當使用服務發現時，比如consul所攜帶的label如下:
這些lable是數據篩選與聚合計算的基礎。
抓取數據很繁雜，尤其是通過服務發現添加的target。所以過濾就顯得尤為重要，我們知道抓取數據就是抓取target的一些列metrics，Prometheus過濾是通過對標簽操作操現的，在欄位relabel_configs和metric_relabel_configs裡面配置，兩者的配置都需要relabel_config欄位。該欄位需要配置項如下
target配置示例
target中metric示例
target中metric示例
使用示例
由以上可知當使用服務發現consul會帶入標簽__meta_consul_dc，現在為了表示方便需要將該標簽變為dc
需要做如下配置，這裡面action使用的replacement
過濾採集target
為了防止Prometheus服務過載，使用該欄位限制經過relabel之後的數據採集數量，超過該數字拉取的數據就會被忽略
Prometheus可以進行遠程讀/寫數據。欄位remote_read和remote_write
（1）Prometheus 配置詳解
https://www.dazhuanlan.com/2019/12/12/5df11ada207ce/
（2）Prometheus配置文件prometheus.yml 四個模塊詳解
http://www.21yunwei.com/archives/7321
（3）官方文檔說明
https://prometheus.io/docs/prometheus/latest/configuration/configuration/
（4）Prometheus監控神器-Rules篇
https://zhuanlan.hu.com/p/179295676
（5）Prometheus監控神器-Alertmanager篇(1)
https://zhuanlan.hu.com/p/179292686
（6）Prometheus監控神器-Alertmanager篇(2)
https://zhuanlan.hu.com/p/179294441
⑻ 電腦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環境變數的配置和使用方法。