微服務近年來炙手可熱，如果在後端服務領域諸多熱門技術趨勢中，比如容器、微服務、DevOps等，找出一個最火的方向，那麼非微服務莫屬。微服務架構通過有效拆分應用，解耦系統，提供更好的軟件伸縮性和企業的敏捷性，實現敏捷開發和部署。
它不是一種橫空出世的技術，事實上微服務microservice的概念已經存在多年，一度曾是軟件開發的寵兒。近年來被越來越多的企業和開發人員所推崇，並在互聯網企業當中大量落地。一些有代表性的傳統行業通過實施微服務架構，提高業務靈活性，加速業務需求變化和響應。
微服務化作爲一個體系，包括開發框架、以及周邊配套工具鏈，比如服務治理、配置中心、安全管理、與容器的結合、監控管理等等。往往，圍繞微服務的管理體系是微服務搭建的難點所在。
接下我們就談談配置中心的架構與實戰。
1爲什麼需要配置管理中心
首先，我們的觀點是，每一個稍微有點規模的分佈式系統，都應該有一個統一配置中心。
當今的系統，隨着系統的複雜度增加，配置也日益增多，隨着devops等概念的推廣，人們對配置的期望值也越來越高：期望配置修改後實時地生效，期望支持灰度發佈，發佈回滾，歷史追蹤，環境隔離，集羣配置，服務治理等等，這個時候分佈式統一配置中心就變得尤爲重要。
配置中心解決什麼痛點：
把業務開發者從複雜以及繁瑣的配置中解脫出來，只需專注於業務代碼本身，從而能夠顯著提升開發以及運維效率。同時將配置和發佈包解藕也進一步提升發佈的成功率，併爲運維的細力度管控、應急處理等提供強有力的支持。
配置中心的使用場景：
-
在服務構建階段，配合構建流水線，爲服務軟件包或鏡像提供配置。
-
在服務運維階段，動態調整服務配置，滿足運維的靈活性需求。
-
在服務開發階段，提供 OpenAPI，爲其他基礎設施的配置外置化，中心化提供支持。
配置中心Hwk產品需求：
基於上述一些列的特點，我們構思了自己的配置中心的產品需求：
-
爲分佈式系統中的基礎設施和微服務應用提供集中化的外部配置支持，實現了對服務端和客戶端中環境變量，配置文件，動態屬性配置的抽象映射，並支持配置的灰度下發，歷史版本控制等先進功能
-
配置接口完全兼容 Spring Cloud Config，後臺管理功能則通過 open API的形式對外開放，滿足企業多樣化的定製需求
-
管理Springcloud的微服務框架的業務配置，服務治理配置以及kubernetes的configmap和secrets的配置，同時也能通過插件的方式對流行的第三方類庫提供特別支持，比如與 sharding-jdbc 的深度集成
2
數人云hawk的架構
配置中心是一個強一致性的系統，配置數據不一致會一起嚴重的業務問題， Hawk 使用讀寫分離的方式處理配置數據，Hawk Portal使用mysql 存儲配置數據，並把通過審覈的配置數據同步給 HawkServer，Hawk Server 使用etcd 來存儲並下發的配置數據。
認證與授權
認證與授權分爲 Hawk Portal 和 Hawk Server 兩個部分來看。
Hawk Portal
在用戶使用 Hawk Portal 管理微服務應用和基礎設施的配置之前，首選需要使用用戶名與密碼登錄。這是一個簡單的 Form based login，目前展示不考慮與企業的認證與授權中心進行單點登錄，但需要能夠允許用戶通過存儲在企業 LDAP 中的用戶名和密碼登錄。
Hawk Server
對於微服務應用通過 Hawk Client 向 Hawk Server 發起遠程調用的時候，無需認證與授權過程，僅做必要的 TLS 對客戶端進行身份認證。
當用戶通過 Restful API 訪問配置服務時，需要對用戶的身份進行認證，用戶的認證在 API Gateway 上完成而不是配置服務本身。
服務發現
etcd 同時也爲 hawk 提供服務註冊於發現的能力，Hawk Portal 與 Hawk Client 都通過 etcd 提供的能力發現和調用 Admin Service與 Config Service。
配置存儲
企業基礎設施與微服務應用的配置數據，以及 Hawk 配置中心本身的配置信息首先在 mysql 中落盤，僅當配置數據被激活後，纔會同步到 Hawk Server，然後由 Sync Service 落盤到 etcd
領域模型。
集羣管理
Hawk 可以同時管理多個配置集羣，devops 用戶可以把不同的集羣映射爲不同的執行環境，比如開發環境 DEV，功能測試環境 FAT，驗收測試環境 UAT等等，使用一套配置中心同時支持多種環境，降低維護成本。
生產環境一般不會與上述環境部署在一起，此時用戶可以把配置集羣映射到不同的部門，在物理上隔離不同部門的配置數據。
配置集羣也可以用於在物理上隔離不同資源的配置，比如區分基礎設施(消息中心，調度中心，微服務中心，存儲中心)和微服務應用。
配置下發
微服務應用可以通過Hawk 提供的客戶端 SDK Hawk Client 獲取配置，也可以通過 Spring Cloud Zuul 服務網管來使用 Config Service 提供的兼容 Spring Cloud Config 的 Restful 接口。
Hawk 可以通過推送的方式把配置變更直接下發給 Hawk Client ，通過這種方式，配置可以實現實時更新。
Hawk Client 在獲取配置信息的同時會連接到配置信息所在的 etcd 集羣，並 watch etcd 中的配置配置數據。當 etcd 集羣中的配置信息更新後，Hawk Client 將會收到通知。
Hawk Client 提供原生接口允許微服務應用註冊監聽器監聽配置信息的變化
服務治理
配置中心的配置管理和動態配置下發能力，使得它可以承擔服務治理中的 Control Plane 的職責，它可以把服務治理相關的配置下發給實際的執行模塊，比如 dubbo，或者是 Spring Cloud 集成的 Netflix 治理工具庫，比如 hystrix 以及 ribbon。
服務治理的主要功能包括：
1. 註冊/發現：服務實例啓動後，將會自動通過 Hawk Client 向配置中心註冊，運維可以在配置中心門戶查看服務的實例列表，並進行實例級別的服務治理。
2. 負載均衡：調用其他服務時，可以靈活指定其負載均衡策略，如 round robin, hash, consistent hash, weight based round robin 等等。
3. 路由：配置微服務的路由策略和路由規則，路由策略如本地優先，本地數據中心優先等等，路由規則如白名單，黑名單，流量引導，讀寫分離，前後端分離，灰度升級等等。
4. 限流：針對某個調用方限流對象進行 QPS 限流，分鐘級或秒級，或針對所有微服務客戶端進行限流。
5. 降級：針對某個降級對象，進行手動或者自動降級（容錯），並制定降級策略，拋出異常或特定返回值。
6. 容錯：針對某個微服務，設定調用超時與重試策略。
7. 熔斷：針對某個微服務或者 RPC方法，設定熔斷的觸發條件，可以強制熔斷，或者自動熔斷，也可以取消熔斷，運維可以指定熔斷參數，比如異常，錯誤碼，失敗次數比率，時間窗口，以及窗口請求書等等。
3Hawk基於Spring Cloud的服務治理系統目標
抽象與具體的服務框架隔離的治理的數據域模型,在系統中均用系統的域模型表示所有的服務治理參數信息,下發到客戶端後,能轉化成相對應的服務配製信息。
功能分類
1. 爲其他應用提供服務：註冊；
2. 爲調用其他應用提供服務：發現和負載均衡；
3. 應用保護自己:熔斷並且包含容錯，降級。
數據流向場景
1. 用戶在potal上配製a應用要調用的服務b和c,以及a應用的基於Hystrix的熔斷配製信息,這些熔斷配製可以保存客戶端需要的熔斷配製信息；
2. a應用啓動,hawk client客戶端啓動；
3. hawk client到server拉取a應用的配製,a應用註冊到hawk server；
4. a應用根據配製中的上游服務名b和c,發現提供b和c服務的實例；
5. 根據配製中的負載均衡的算法給每個上游業務配製負載均衡器；
6. 根據配製的熔斷參數動態調用相應的功能插件生成各服務框架的標準參數格式,注入到應用中。
組件
服務治理的namespace命名: governance
負載均衡/路由(這裏可以讓用戶自由輸入ribbon的配製)
熔斷設計
說明:
基於sping cloud的爲基礎,抽象出熔斷的模型.前端通過界面操作，生成自說明key，保存成kv格式。
比如sc應用,全局的command對象的execution的timeout的enabled選項參數生成的key值是
hystrix.command.default.execution.timeout.enabled=true；
對於其他服務框架的配製主要映射到這個模型的相應字段上。
參考：
http://support.huaweicloud.com/usermanual-cse/cse_01_0025.html
https://github.com/ctripcorp/apollo
https://github.com/knightliao/disconf
https://github.com/Qihoo360/QConf
4問答環節
1、 Q：請問配置中心存儲的是配置文件還是key-value? 像數據庫連接串之類的信息如何管理的？跟數據連接池怎麼配合？
A：是key-value的，存儲在etcd集羣上，服務可通過hawk-client拉取配置到服務本地生成本地的配置或直接導入到本地環境變量，這些配置隨着服務啓動就會生效。
2、 Q：請問Hawk是一個產品嗎？
A：Hawk將會是數人云推出的一個企業產品，同時也會作爲一個開源項目發佈在github上，具體的開源時間我們還不確定，相信很快。
3、 Q：爲什麼要自己開發一個配置中心，而不是直接使用Spring cloud config？
A：其實很簡單，單純的spring cloud config沒有辦法充分地切合企業系統的生產需要。我這裏有一個功能對比圖，大家可以參考一下。
4、Q：請問這個配置中心只能應用於Java語音嗎？
A：配置中心的代碼是Java編寫的，但是配置中心的使用方，即拉取配置的一方是不限制語言，因爲配置拉取是基於http協議。
5、Q：請問數人云的官方網站有關於Hawk這個產品的詳細功能介紹嗎？今天講得還是比較快的，希望能具體瞭解；謝謝。
A：有的， https://www.shurenyun.com/product-hawk.html
6、 Q：請問CI/CD流程控制是自己研發的還是用的開源方案？
A：CI/CD持續集成，持續交互其實是一個很大的概念，我理解你想問的是Hawk的操作流程以及所使用的技術棧的問題，最初我們參考過其他的一些開源比如攜程的appolo，百度的disconf等，結合他們的一些理念，我們又自己總結思考了自己的需求，對CI/CD的業務做出歸納，以達到簡單直接的目標，技術方面，我們主要用到spring boot， spring cloud以及etcd等技術，其中spring cloud主要適用於服務註冊發現，服務治理等方面。
7、 Q：我想問下，關於配置中心部署問題，第一個，不同環境或者不同集羣，你們配置中心是怎麼部署的，還有，一些基礎組件配置和應用配置放在一個配置中心嗎？
A：配置中心通過不同的存儲集羣，可以實現一個配置中心服務多個環境，但是原則上，建議測試，開發公用一個不熟而生產獨立部署，配置中心的中心概念是基於微服務，所以從概念上說，我們的配置是生效於一個服務下的實例級別，而不是組件級別，每個實例下又分爲不同的命名空間，命名空間可劃分爲：應用層，環境變量和自定義的組件，可由客戶自定義，所以原則上涵蓋了組件與服務的概念。