本文來自1月18日數人云資深工程師在IT大咖說平臺的線上直播分享。
今天主要探討這幾方面：
一、配置中心的定位二、雲化的微服務對於配置中心的要求三、微服務配置原則
四、數人云分佈式配置中心整體架構
應DevOps和微服務而生的配置中心
首先想跟大家分享一下，爲什麼會有配置中心的存在？在我早期從事軟件開發時，是沒有配置中心，也沒有微服務的。
以前每次系統發佈，無論是大改動，還是很小很小的改動，都必須經歷發佈的過程。這個改動有時候小到，只是修改了某個配置文件的某個字段，也必須要重新打包，重新部署。
而且，在企業裏開發和運維的人員，往往不是同一個羣組。部署時，開發人員需要爲運維人員準備部署文檔。這個過程中，經常會由於溝通協調不到位，無法第一時間預測到所有問題，導致在正式上線時，被用戶第一時間察覺到上線出了問題，或者部署不正確等，導致一些非常嚴重的後果。
隨着時間的推移，軟件工程界出現了新的名詞--DevOps。開發和運維人員共同協作進行產品的部署上線。在DevOps時代，如何將概念通過一些IT的手段轉化爲直接的生產力。因爲每次發佈改動越大，發佈的頻率越高，系統的風險就越大。
所以業界急需一種技術手段，來協助開發、部署和運維三方面的人員，在不斷的迭代過程中，減少這種風險。配置能不能是一種動態的配置？而不再需要去做一些靜態配置。基於這種業界的風險，就有了去做配置中心的衝動。於是，市面上出現了分佈式的配置中心。
無論是分佈式的配置中心，還是普通配置中心，它到底在配置什麼東西？如果把時間往前推一段，通過SSH登陸服務器修改配置的那個時代，配置中心的作用其實不大。
到了2010年之後，業界出現了微服務，分佈式的配置中心才正式地光明正大的走向舞臺。爲什麼呢？因爲要結合分佈式配置中心+微服務，才能真正實現我們所理解的DevOps。
微服務配置原則
Heroku創始人AdamWiggins發佈了一個“十二要素應用宣言（TheTwelve-Factor App）”，爲構建使用標準化流程自動配置，服務界限清晰，可移植性高，基於雲計算平臺，可擴展的服務配置提供了方法論：
1.配置是可分離的，可從微服務中抽離出來，任何的配置修改不需要動一行代碼。
2.配置應該是中央的 通過統一的中央配置平臺去配置管理不同的微服務
3.配置中心必須必須可靠切穩定地提供配置服務。
4.配置是可追溯的，任何的配置歷史都是可追溯，被管理且可用。
在雲服務時代，對微服務做配置，對它有什麼樣的要求呢？
首先必須基於鏡像管理部署，有自己相應獨立的配置，而且程序包不可以因爲環境的改變而更改。也就是說，它是獨立於環境的不可變的程序包。
其次所有的微服務通過環境變量或者配置存儲時，在啓動的那一刻，就可以做配置，也可以通過動態的修改實時生效。
微服務啓動時配置
一個微服務從打包、上線、部署，打包以後，會在啓動階段從配置Configuration Repository 裏面拉取它的配置，通過註冊與發現，註冊在註冊中心裏，在啓動時，把服務中心的配置拉取到本地，成爲應用的一部分。
並且在服務運行過程中，實時動態監聽配置的變更，達到有新的配置時馬上下發到微服務，使配置有實時生效的效果。
配置中心的定位
有了以上這種業務需求，到底要做一個怎樣的配置中心？數人云認爲，這個配置中心必須有一致性的K-V存儲中心，K-V存儲就是說，一個K對應一個V，而且這種存儲必須持久化、可追溯。
它必須是可以集中統一配置，實時推送，以及馬上生效。
所有配置都必須實現灰度更新與回滾。所謂灰度發佈，是說一個微服務集羣裏面，比如有個訂單系統，做了一些配置上的更新。想在小範圍探討一下，實驗一下這個配置對業務有怎樣的影響，這時就用到灰度更新這個概念。
灰度更新是說，通過Data center或靜態IP，指定某個配置只對某幾個IP，或者Datacenter裏面的某個服務生效，其他的不在這個範圍內的服務，不會受到影響。觀察效果，如果OK，就把這個整體配置全面推送到所有的微服務。如果效果不滿意，就把配置回滾到原來的狀態。
全量更新，灰度更新，或者回滾，必須是可在任何時候查看，在某一個任意的時刻，回滾到某一個歷史點的配置。
最後一個是要有多集羣的啓動，所謂多集羣的啓動就是，我們把配置存儲的時候，必須存儲在一個多集羣的環境裏面，以達到物理隔離的目的。
另外還有一些原則，業務無關性、 Open API、配置生效監控。就是說配置中心必須提供API給第三方的系統來使用。配置的生效監控是，必須實時知道，有哪些服務拉取了配置，是否已經生效，或者這個配置的效果如何？
配置中心的支撐體系
第一種運維管理體系類似於偏靜態類的配置，在啓動時通過配置文件直接拉取讀業務。
另外一種是開發管理體系，偏動態管理，代表的是一種程序或者在運行過程中，通過實時的變更配置內容而實時生效，達到的一種效果。
一個健全的配置中心應該支持這兩種運維體系。
配置中心的微服務兼容
配置中心必須對現有主流的一些開發框架有API方面的兼容。數人云在做配置中心時，很難預估第三方來調用服務時，到底搭配在什麼樣的開發框架上？通常來說，配置中心不可能兼容市面上所有的東西，數人云選擇重要的框架來做深度兼容。
首先，對Spring Cloud，阿里的Dubbo這些常規的第三方雲服務框架做了API方面的兼容。目前來說，至少要支持SpringCloud、Dubbo、Nginx、Tomcat、Logback等各方面的配置。
這種配置各有各的特性，所以我們就挑選了一些有經典案例的，通用性的東西來做配置的集成，比如原生支持SpringBoot、Spring Cloud，集成支持k8s，就是k8s容器。
數人云hawk分佈式統一配置中心
數人云分佈式統一配置中心，取名Hawk。Hawk基於ETCD打造，主要解決把開發人員從複雜的業務流程和煩瑣的配置中解脫出來，讓開發人員只關注自己的業務代碼，把運維、配置這些剝離出去。同時降低服務部署、發佈過程中的風險。
基於微服務體系理念打造的分佈式統一配置中心Hawk支持多種類型配置：如Spring Cloud、 Dubbo、Kubernetes Configmap、Logback、Linux Environment，具有完善的配置管理流程、配置實施推送、支持多集羣多環境、多版本控制，更提供配置細粒度的管理如灰度管理、任意版本重置等豐富功能。
整個體系兼容開源社區的Spring Cloud Config以及Kubernetes的Configmap，極大降低使用者的學習門檻以及業務對平臺的耦合。相應的管理流程也規範了配置的使用，降低配置帶來的發佈錯誤等。
功能特性
對比主流框架，數人云HAWK有如下一些重要的功能特性：
-
支持配置實時推送以及實時生效，在程序的運行過程中，不能說把服務停下來才能更新，必須實時配置，實時生效。
-
支持多版本管理，配置不管哪個版本，都可以隨時查看、查閱以及激活歷史的版本，並做發佈。
-
支持多集羣環境，多環境配置。通過數據庫或者後端存儲，以達到支持SIT、UAT環境的體系。
-
優美的監控臺,提供多維度Dashboard以及監控視圖，支持配置灰度和回滾。
-
支持數據全局備份和回覆，進一步提升配置數據的容災能力。
-
提供OpenAPI,支持多系統集成的便利手段，支持配置應急預案處理。
-
配置流程管理，完善的配置流程管理，確保配置下發前必須獲得確認和授權。
-
認證與授權，提供LDAP集成，以及多角色權限管理。
-
支持操作審計，確保配置操作有據可查。
-
支持多種配置文件，Spring Cloud Config、Dubbo、Logback、Nginx、LinuxEnvironment、Tomcat。
-
支持Spring Cloud服務治理配置和管控，支持Spring Cloud自有的Hystrix的微服務治理如熔斷、Fallback等等。
-
無縫集成Kubernetes的Configmap以及Secrets，並提供增強的企業管理流程。
Hawk整體架構
首先接入第一層是網關，整體的存儲通過Hawk Server，下發到ETCD集羣，ETCD集羣再同步到K8S容器運行的平臺。
剛纔有同學說Hawk跟阿波羅有相似的地方。在研究對比時，我們覺得阿波羅出於業務需求，有一些比較複雜的地方，決定把流程簡化。
先從數據遷移的狀態簡化成簡單的幾部分。比如新建一個配置，要麼配置就被刪除了，直接一步到位。如果沒有這樣做，就面臨幾種情況，這個配置是否要小範圍的去做一些試探性的發佈，這種情況可以走灰度發佈，狀態變成灰度中，配置不允許更改。要麼就是兩條路走，全量發佈到所有服務上。要麼就是放棄灰度回到之前的狀態，放棄灰度後會去到已修改的狀態。
另外一種情況，新建一個配置，直接全量發佈，狀態變成已發佈狀態，這時候是可更改的。但是每一次的更改，還是會回到原來那個狀態。這個更改要做灰度嗎？還是做發佈？還是對發佈有點後悔，不打算更改了？這時，從歷史版本裏面找一個合適的版本，激活，然後再做一次發佈，通過幾個簡單的迴路，涵蓋了大部分的業務場景。
配置數據狀態變遷
Hawk Portal是主體的配置界面，用戶在界面上對配置進行輸入、增刪、改查的管理。這些資料會有兩份，一份做通過Mysql做本地存儲，另一份通過Hawk Server直接同步到ETCD。
由於HAWK Server是同步到ETCD裏面，也就是說ETCD相當於另外一個數據庫，這當中不存在數據之間的互相抄送，從而減低丟失數據的風險。持久化，是說研發和運維在後臺做數據遷移，或者數據監控時更有把握，更方便。
數人云HAWK其實有兩個ETCD，一個ETCD是做註冊發現的，HawkServer、Hawk Portal都會註冊在裏面，作爲相關的組件。類比Spring Cloud Eureka，Eureka是註冊在Eureka Server裏面的一個內存列表，集羣裏面所有Server共享這個內存信息。這個過程數人云做了簡化，所有信息全部註冊在ETCD裏面。
ECTD集羣由於是共享的，組件的狀態和一致性得到保障。Portal和Server之間不再通過Portal註冊在Server並通過心跳來維持關係而是通過共享持久化的ETCD，保證數據在任意時刻所看到的狀態都是一致的，從而保證了服務的註冊，以及服務發現的穩定性。
Hawk和Eureka 選擇的路徑不一樣。Eureka是比較重量級的，HAWK則簡化了這個配置，簡化這種代碼的複雜性，重點提高系統的完整性，打造系統閉環，通過一些相對簡單的方法，提高服務的穩定性。
配置一旦通過Hawk Portal潛入本地數據庫，微服務的註冊服務是怎麼實現配置呢？當Portal寫入配置到本地數據庫時，同時也會通過服務Sever去同步到ETCD，ETCD裏面存儲的信息，是一個持久化的數據。
通過Server實時從ETCD拉取配置，有時是運行的時候拉取，有時是啓動時拉取。啓動時拉取有兩種策略，啓動的時候拉取配置，存儲到本地作爲靜態文件的配置，運行時候拉取，動態的變更實時生效。
在Web層其實也有一些問題需要解決，比如，因爲我們不是一個開發框架，是奔着一個開源系統的方向去，所以要解決服務跟瀏覽器之間的授權。
數人云現在的做法是在本土數據庫存儲一些用戶的信息，但是並沒有採用傳統意義上的建Session來做驗證和授權，而是通過動態下發JWT的形式，每一個請求動態下發，根據我個人用戶的一些信息生成，每次的請求一來一去都有交換新的Token，每個Token實時生效並有續約的功能，來代替傳統意義上的Session。
配置中心集成第三方框架與類庫
Hawk有一個第三方類庫集成，操作流程是這樣的：操作者通過UI調用HAWK後端的portal，通過Hawk Server把配置寫入ETCD。另外一些運營者和開發人員所持有的第三方服務，通過集成Hawk Client來讀取配置。
Hawk也有新的迭代，跟Sharding-JDBC做了集成，JDBC
2.0的一些趨勢跟HAWK系統做了深度集成。服務通過實時讀取配置中心配置實現動態更改分庫分表的策略。
Q&A
Q1：實時更改分佈分表策略？
A1：可以，Sharding JDBC 2.0就是重點實現這個功能，這也是Hawk與Sharding JDBC深度合作的成果
Q2：歷史數據怎麼辦？
A2：歷史的數據其實都是持久化存儲的。如果有一天要回到某個歷史版本，可以隨時通過調取已發佈的歷史。Hawk有一個版面叫發佈歷史。這裏，每一個配置都有配置歷史可追尋，可以隨時查看或激活某個版本。激活的時候，需要用戶去選擇要做一個全鏈發佈還灰度發佈，還是說什麼都不做。
Q3：是否支持ServiceMesh？
A3：目前來說ServiceMesh還是一個比較新的東西。如果ServiceMesh是獨立配置的話，其實可以支持到。但是ServiceMesh有非常多的特性，還不敢說100%可以支持得到。其實數人云也在做ServiceMesh相關的項目，就是說它以後還是有非常大的可能，還是要集成ServiceMesh配置中心裏面做一個閉環。目前這個版本支持一些比較輕量的配置。
ServiceMesh中文網微信公衆號（ID：servicemesh），大量Istio、Conduit官方文檔翻譯版和技術乾貨文章，歡迎關注。
Q4：開發環境和生產環境用哪一步驟？
A4：SIT和UI其實可以部署在一起，通過存儲隔離來做到。但是，不建議生產也部署在一起，生產還是建議獨立部署。生產還是物理隔離是最好的方案。
Q5：配置中心和服務中心是不是兩個系統？
A5：目前來說是兩個系統，但是現在的想法是暫時的。現在的想法是是不是把配置中心再擴大一點，不叫配置中心了，而是叫比如微服務服務平臺。服務平臺裏把配置中心跟註冊中心都作爲一個組件融入進去，把一些跟業務無關的東西抽離出來，搭載一些公共的平臺上，以組件的形式去融入到這個平臺裏面去。
Q6：開源有本地緩存嗎？
A6：目前來說沒有本地緩存，是直接獲取ETCD的東西，所以它是實時的，但是註冊中心裏面會加入緩存。
Q7：一般哪些信息通過配置中心配置？
A7：非業務的東西，比如平時開發一個系統，或者開發一個第三方系統，我們都有所有的配置文件，比如數據庫的連接，跟治理相關的東西，或者一些國外的引用，都可以通過配置中心來配置，並且這種配置不僅僅是在頁面上的配置，有一個插件給它，啓動之後直接把這些配置導入到配置中心裏面去，還可以通過啓動的時候把這種配置下發到本地，形成一個本地的靜態配置。
Q8：server如果斷開怎麼處理？
A8：因爲Server是多Server集羣的，如果斷開了並不是說通過指定IP地址去訪問這個Server，而是通過註冊與發現去訪問這個Server，如果Server斷開了，其實也就是說他們之間沒有心跳了，他們就會嘗試去ETCD裏面請求一個新的連接，而這個連接也會通過註冊與發現，會發現其他的Server，這樣的話他們就會連接。
本文來自1月18日數人云資深工程師在IT大咖說平臺的線上直播分享。
今天主要探討這幾方面：
一、配置中心的定位二、雲化的微服務對於配置中心的要求三、微服務配置原則四、數人云分佈式配置中心整體架構
應DevOps和微服務而生的配置中心
首先想跟大家分享一下，爲什麼會有配置中心的存在？在我早期從事軟件開發時，是沒有配置中心，也沒有微服務的。
以前每次系統發佈，無論是大改動，還是很小很小的改動，都必須經歷發佈的過程。這個改動有時候小到，只是修改了某個配置文件的某個字段，也必須要重新打包，重新部署。
而且，在企業裏開發和運維的人員，往往不是同一個羣組。部署時，開發人員需要爲運維人員準備部署文檔。這個過程中，經常會由於溝通協調不到位，無法第一時間預測到所有問題，導致在正式上線時，被用戶第一時間察覺到上線出了問題，或者部署不正確等，導致一些非常嚴重的後果。
隨着時間的推移，軟件工程界出現了新的名詞--DevOps。開發和運維人員共同協作進行產品的部署上線。在DevOps時代，如何將概念通過一些IT的手段轉化爲直接的生產力。因爲每次發佈改動越大，發佈的頻率越高，系統的風險就越大。
所以業界急需一種技術手段，來協助開發、部署和運維三方面的人員，在不斷的迭代過程中，減少這種風險。配置能不能是一種動態的配置？而不再需要去做一些靜態配置。基於這種業界的風險，就有了去做配置中心的衝動。於是，市面上出現了分佈式的配置中心。
無論是分佈式的配置中心，還是普通配置中心，它到底在配置什麼東西？如果把時間往前推一段，通過SSH登陸服務器修改配置的那個時代，配置中心的作用其實不大。
到了2010年之後，業界出現了微服務，分佈式的配置中心才正式地光明正大的走向舞臺。爲什麼呢？因爲要結合分佈式配置中心+微服務，才能真正實現我們所理解的DevOps。
微服務配置原則
1.配置是可分離的，可從微服務中抽離出來，任何的配置修改不需要動一行代碼。
2.配置應該是中央的 通過統一的中央配置平臺去配置管理不同的微服務
3.配置中心必須必須可靠切穩定地提供配置服務。
4.配置是可追溯的，任何的配置歷史都是可追溯，被管理且可用。
在雲服務時代，對微服務做配置，對它有什麼樣的要求呢？
首先必須基於鏡像管理部署，有自己相應獨立的配置，而且程序包不可以因爲環境的改變而更改。也就是說，它是獨立於環境的不可變的程序包。
其次所有的微服務通過環境變量或者配置存儲時，在啓動的那一刻，就可以做配置，也可以通過動態的修改實時生效。
微服務啓動時配置
一個微服務從打包、上線、部署，打包以後，會在啓動階段從配置Configuration Repository 裏面拉取它的配置，通過註冊與發現，註冊在註冊中心裏，在啓動時，把服務中心的配置拉取到本地，成爲應用的一部分。
並且在服務運行過程中，實時動態監聽配置的變更，達到有新的配置時馬上下發到微服務，使配置有實時生效的效果。
配置中心的定位
有了以上這種業務需求，到底要做一個怎樣的配置中心？數人云認爲，這個配置中心必須有一致性的K-V存儲中心，K-V存儲就是說，一個K對應一個V，而且這種存儲必須持久化、可追溯。
它必須是可以集中統一配置，實時推送，以及馬上生效。
所有配置都必須實現灰度更新與回滾。所謂灰度發佈，是說一個微服務集羣裏面，比如有個訂單系統，做了一些配置上的更新。想在小範圍探討一下，實驗一下這個配置對業務有怎樣的影響，這時就用到灰度更新這個概念。
灰度更新是說，通過Data center或靜態IP，指定某個配置只對某幾個IP，或者Datacenter裏面的某個服務生效，其他的不在這個範圍內的服務，不會受到影響。觀察效果，如果OK，就把這個整體配置全面推送到所有的微服務。如果效果不滿意，就把配置回滾到原來的狀態。
全量更新，灰度更新，或者回滾，必須是可在任何時候查看，在某一個任意的時刻，回滾到某一個歷史點的配置。
最後一個是要有多集羣的啓動，所謂多集羣的啓動就是，我們把配置存儲的時候，必須存儲在一個多集羣的環境裏面，以達到物理隔離的目的。
另外還有一些原則，業務無關性、 Open API、配置生效監控。就是說配置中心必須提供API給第三方的系統來使用。配置的生效監控是，必須實時知道，有哪些服務拉取了配置，是否已經生效，或者這個配置的效果如何？
配置中心的支撐體系
第一種運維管理體系類似於偏靜態類的配置，在啓動時通過配置文件直接拉取讀業務。
另外一種是開發管理體系，偏動態管理，代表的是一種程序或者在運行過程中，通過實時的變更配置內容而實時生效，達到的一種效果。
一個健全的配置中心應該支持這兩種運維體系。
配置中心的微服務兼容
配置中心必須對現有主流的一些開發框架有API方面的兼容。數人云在做配置中心時，很難預估第三方來調用服務時，到底搭配在什麼樣的開發框架上？通常來說，配置中心不可能兼容市面上所有的東西，數人云選擇重要的框架來做深度兼容。
首先，對Spring Cloud，阿里的Dubbo這些常規的第三方雲服務框架做了API方面的兼容。目前來說，至少要支持SpringCloud、Dubbo、Nginx、Tomcat、Logback等各方面的配置。
這種配置各有各的特性，所以我們就挑選了一些有經典案例的，通用性的東西來做配置的集成，比如原生支持SpringBoot、Spring Cloud，集成支持k8s，就是k8s容器。
數人云hawk分佈式統一配置中心
數人云分佈式統一配置中心，取名Hawk。Hawk基於ETCD打造，主要解決把開發人員從複雜的業務流程和煩瑣的配置中解脫出來，讓開發人員只關注自己的業務代碼，把運維、配置這些剝離出去。同時降低服務部署、發佈過程中的風險。
基於微服務體系理念打造的分佈式統一配置中心Hawk支持多種類型配置：如Spring Cloud、 Dubbo、Kubernetes Configmap、Logback、Linux Environment，具有完善的配置管理流程、配置實施推送、支持多集羣多環境、多版本控制，更提供配置細粒度的管理如灰度管理、任意版本重置等豐富功能。
整個體系兼容開源社區的Spring Cloud Config以及Kubernetes的Configmap，極大降低使用者的學習門檻以及業務對平臺的耦合。相應的管理流程也規範了配置的使用，降低配置帶來的發佈錯誤等。
功能特性
對比主流框架，數人云HAWK有如下一些重要的功能特性：
-
支持配置實時推送以及實時生效，在程序的運行過程中，不能說把服務停下來才能更新，必須實時配置，實時生效。
-
支持多版本管理，配置不管哪個版本，都可以隨時查看、查閱以及激活歷史的版本，並做發佈。
-
支持多集羣環境，多環境配置。通過數據庫或者後端存儲，以達到支持SIT、UAT環境的體系。
-
優美的監控臺,提供多維度Dashboard以及監控視圖，支持配置灰度和回滾。
-
支持數據全局備份和回覆，進一步提升配置數據的容災能力。
-
提供OpenAPI,支持多系統集成的便利手段，支持配置應急預案處理。
-
配置流程管理，完善的配置流程管理，確保配置下發前必須獲得確認和授權。
-
認證與授權，提供LDAP集成，以及多角色權限管理。
-
支持操作審計，確保配置操作有據可查。
-
支持多種配置文件，Spring Cloud Config、Dubbo、Logback、Nginx、LinuxEnvironment、Tomcat。
-
支持Spring Cloud服務治理配置和管控，支持Spring Cloud自有的Hystrix的微服務治理如熔斷、Fallback等等。
-
無縫集成Kubernetes的Configmap以及Secrets，並提供增強的企業管理流程。
Hawk整體架構
首先接入第一層是網關，整體的存儲通過Hawk Server，下發到ETCD集羣，ETCD集羣再同步到K8S容器運行的平臺。
剛纔有同學說Hawk跟阿波羅有相似的地方。在研究對比時，我們覺得阿波羅出於業務需求，有一些比較複雜的地方，決定把流程簡化。
先從數據遷移的狀態簡化成簡單的幾部分。比如新建一個配置，要麼配置就被刪除了，直接一步到位。如果沒有這樣做，就面臨幾種情況，這個配置是否要小範圍的去做一些試探性的發佈，這種情況可以走灰度發佈，狀態變成灰度中，配置不允許更改。要麼就是兩條路走，全量發佈到所有服務上。要麼就是放棄灰度回到之前的狀態，放棄灰度後會去到已修改的狀態。
另外一種情況，新建一個配置，直接全量發佈，狀態變成已發佈狀態，這時候是可更改的。但是每一次的更改，還是會回到原來那個狀態。這個更改要做灰度嗎？還是做發佈？還是對發佈有點後悔，不打算更改了？這時，從歷史版本裏面找一個合適的版本，激活，然後再做一次發佈，通過幾個簡單的迴路，涵蓋了大部分的業務場景。
配置數據狀態變遷
Hawk Portal是主體的配置界面，用戶在界面上對配置進行輸入、增刪、改查的管理。這些資料會有兩份，一份做通過Mysql做本地存儲，另一份通過Hawk Server直接同步到ETCD。
由於HAWK Server是同步到ETCD裏面，也就是說ETCD相當於另外一個數據庫，這當中不存在數據之間的互相抄送，從而減低丟失數據的風險。持久化，是說研發和運維在後臺做數據遷移，或者數據監控時更有把握，更方便。
數人云HAWK其實有兩個ETCD，一個ETCD是做註冊發現的，HawkServer、Hawk Portal都會註冊在裏面，作爲相關的組件。類比Spring Cloud Eureka，Eureka是註冊在Eureka Server裏面的一個內存列表，集羣裏面所有Server共享這個內存信息。這個過程數人云做了簡化，所有信息全部註冊在ETCD裏面。
ECTD集羣由於是共享的，組件的狀態和一致性得到保障。Portal和Server之間不再通過Portal註冊在Server並通過心跳來維持關係而是通過共享持久化的ETCD，保證數據在任意時刻所看到的狀態都是一致的，從而保證了服務的註冊，以及服務發現的穩定性。
Hawk和Eureka 選擇的路徑不一樣。Eureka是比較重量級的，HAWK則簡化了這個配置，簡化這種代碼的複雜性，重點提高系統的完整性，打造系統閉環，通過一些相對簡單的方法，提高服務的穩定性。
配置一旦通過Hawk Portal潛入本地數據庫，微服務的註冊服務是怎麼實現配置呢？當Portal寫入配置到本地數據庫時，同時也會通過服務Sever去同步到ETCD，ETCD裏面存儲的信息，是一個持久化的數據。
通過Server實時從ETCD拉取配置，有時是運行的時候拉取，有時是啓動時拉取。啓動時拉取有兩種策略，啓動的時候拉取配置，存儲到本地作爲靜態文件的配置，運行時候拉取，動態的變更實時生效。
在Web層其實也有一些問題需要解決，比如，因爲我們不是一個開發框架，是奔着一個開源系統的方向去，所以要解決服務跟瀏覽器之間的授權。
數人云現在的做法是在本土數據庫存儲一些用戶的信息，但是並沒有採用傳統意義上的建Session來做驗證和授權，而是通過動態下發JWT的形式，每一個請求動態下發，根據我個人用戶的一些信息生成，每次的請求一來一去都有交換新的Token，每個Token實時生效並有續約的功能，來代替傳統意義上的Session。
配置中心集成第三方框架與類庫
Hawk有一個第三方類庫集成，操作流程是這樣的：操作者通過UI調用HAWK後端的portal，通過Hawk Server把配置寫入ETCD。另外一些運營者和開發人員所持有的第三方服務，通過集成Hawk Client來讀取配置。
Hawk也有新的迭代，跟Sharding-JDBC做了集成，JDBC
2.0的一些趨勢跟HAWK系統做了深度集成。服務通過實時讀取配置中心配置實現動態更改分庫分表的策略。
Q&A
Q1：實時更改分佈分表策略？
A1：可以，Sharding JDBC 2.0就是重點實現這個功能，這也是Hawk與Sharding JDBC深度合作的成果
Q2：歷史數據怎麼辦？
A2：歷史的數據其實都是持久化存儲的。如果有一天要回到某個歷史版本，可以隨時通過調取已發佈的歷史。Hawk有一個版面叫發佈歷史。這裏，每一個配置都有配置歷史可追尋，可以隨時查看或激活某個版本。激活的時候，需要用戶去選擇要做一個全鏈發佈還灰度發佈，還是說什麼都不做。
Q3：是否支持ServiceMesh？
A3：目前來說ServiceMesh還是一個比較新的東西。如果ServiceMesh是獨立配置的話，其實可以支持到。但是ServiceMesh有非常多的特性，還不敢說100%可以支持得到。其實數人云也在做ServiceMesh相關的項目，就是說它以後還是有非常大的可能，還是要集成ServiceMesh配置中心裏面做一個閉環。目前這個版本支持一些比較輕量的配置。
ServiceMesh中文網微信公衆號（ID：servicemesh），大量Istio、Conduit官方文檔翻譯版和技術乾貨文章，歡迎關注。
Q4：開發環境和生產環境用哪一步驟？
A4：SIT和UI其實可以部署在一起，通過存儲隔離來做到。但是，不建議生產也部署在一起，生產還是建議獨立部署。生產還是物理隔離是最好的方案。
Q5：配置中心和服務中心是不是兩個系統？
A5：目前來說是兩個系統，但是現在的想法是暫時的。現在的想法是是不是把配置中心再擴大一點，不叫配置中心了，而是叫比如微服務服務平臺。服務平臺裏把配置中心跟註冊中心都作爲一個組件融入進去，把一些跟業務無關的東西抽離出來，搭載一些公共的平臺上，以組件的形式去融入到這個平臺裏面去。
Q6：開源有本地緩存嗎？
A6：目前來說沒有本地緩存，是直接獲取ETCD的東西，所以它是實時的，但是註冊中心裏面會加入緩存。
Q7：一般哪些信息通過配置中心配置？
A7：非業務的東西，比如平時開發一個系統，或者開發一個第三方系統，我們都有所有的配置文件，比如數據庫的連接，跟治理相關的東西，或者一些國外的引用，都可以通過配置中心來配置，並且這種配置不僅僅是在頁面上的配置，有一個插件給它，啓動之後直接把這些配置導入到配置中心裏面去，還可以通過啓動的時候把這種配置下發到本地，形成一個本地的靜態配置。
Q8：server如果斷開怎麼處理？
A8：因爲Server是多Server集羣的，如果斷開了並不是說通過指定IP地址去訪問這個Server，而是通過註冊與發現去訪問這個Server，如果Server斷開了，其實也就是說他們之間沒有心跳了，他們就會嘗試去ETCD裏面請求一個新的連接，而這個連接也會通過註冊與發現，會發現其他的Server，這樣的話他們就會連接。
