摘要:于是,市面上出現(xiàn)了分布式的配置中心。為什么呢因為要結(jié)合分布式配置中心微服務(wù),才能真正實現(xiàn)我們所理解的。所謂灰度發(fā)布,是說一個微服務(wù)集群里面,比如有個訂單系統(tǒng),做了一些配置上的更新。數(shù)人云分布式統(tǒng)一配置中心數(shù)人云分布式統(tǒng)一配置中心,取名。
本文來自1月18日數(shù)人云資深工程師在IT大咖說平臺的線上直播分享。
今天主要探討這幾方面:
一、配置中心的定位
二、云化的微服務(wù)對于配置中心的要求
三、微服務(wù)配置原則
四、數(shù)人云分布式配置中心整體架構(gòu)
應(yīng)DevOps和微服務(wù)而生的配置中心
首先想跟大家分享一下,為什么會有配置中心的存在?在我早期從事軟件開發(fā)時,是沒有配置中心,也沒有微服務(wù)的。
以前每次系統(tǒng)發(fā)布,無論是大改動,還是很小很小的改動,都必須經(jīng)歷發(fā)布的過程。這個改動有時候小到,只是修改了某個配置文件的某個字段,也必須要重新打包,重新部署。
而且,在企業(yè)里開發(fā)和運維的人員,往往不是同一個群組。部署時,開發(fā)人員需要為運維人員準(zhǔn)備部署文檔。這個過程中,經(jīng)常會由于溝通協(xié)調(diào)不到位,無法第一時間預(yù)測到所有問題,導(dǎo)致在正式上線時,被用戶第一時間察覺到上線出了問題,或者部署不正確等,導(dǎo)致一些非常嚴(yán)重的后果。
隨著時間的推移,軟件工程界出現(xiàn)了新的名詞--DevOps。開發(fā)和運維人員共同協(xié)作進(jìn)行產(chǎn)品的部署上線。在DevOps時代,如何將概念通過一些IT的手段轉(zhuǎn)化為直接的生產(chǎn)力。因為每次發(fā)布改動越大,發(fā)布的頻率越高,系統(tǒng)的風(fēng)險就越大。
所以業(yè)界急需一種技術(shù)手段,來協(xié)助開發(fā)、部署和運維三方面的人員,在不斷的迭代過程中,減少這種風(fēng)險。配置能不能是一種動態(tài)的配置?而不再需要去做一些靜態(tài)配置?;谶@種業(yè)界的風(fēng)險,就有了去做配置中心的沖動。于是,市面上出現(xiàn)了分布式的配置中心。
無論是分布式的配置中心,還是普通配置中心,它到底在配置什么東西?如果把時間往前推一段,通過SSH登陸服務(wù)器修改配置的那個時代,配置中心的作用其實不大。
到了2010年之后,業(yè)界出現(xiàn)了微服務(wù),分布式的配置中心才正式地光明正大的走向舞臺。為什么呢?因為要結(jié)合分布式配置中心+微服務(wù),才能真正實現(xiàn)我們所理解的DevOps。
微服務(wù)配置原則
Heroku創(chuàng)始人AdamWiggins發(fā)布了一個“十二要素應(yīng)用宣言(TheTwelve-Factor App)”,為構(gòu)建使用標(biāo)準(zhǔn)化流程自動配置,服務(wù)界限清晰,可移植性高,基于云計算平臺,可擴展的服務(wù)配置提供了方法論:
1.配置是可分離的,可從微服務(wù)中抽離出來,任何的配置修改不需要動一行代碼。 2.配置應(yīng)該是中央的 通過統(tǒng)一的中央配置平臺去配置管理不同的微服務(wù) 3.配置中心必須必須可靠切穩(wěn)定地提供配置服務(wù)。 4.配置是可追溯的,任何的配置歷史都是可追溯,被管理且可用。
在云服務(wù)時代,對微服務(wù)做配置,對它有什么樣的要求呢?
首先必須基于鏡像管理部署,有自己相應(yīng)獨立的配置,而且程序包不可以因為環(huán)境的改變而更改。也就是說,它是獨立于環(huán)境的不可變的程序包。
其次所有的微服務(wù)通過環(huán)境變量或者配置存儲時,在啟動的那一刻,就可以做配置,也可以通過動態(tài)的修改實時生效。
微服務(wù)啟動時配置
一個微服務(wù)從打包、上線、部署,打包以后,會在啟動階段從配置Configuration Repository 里面拉取它的配置,通過注冊與發(fā)現(xiàn),注冊在注冊中心里,在啟動時,把服務(wù)中心的配置拉取到本地,成為應(yīng)用的一部分。
并且在服務(wù)運行過程中,實時動態(tài)監(jiān)聽配置的變更,達(dá)到有新的配置時馬上下發(fā)到微服務(wù),使配置有實時生效的效果。
配置中心的定位
有了以上這種業(yè)務(wù)需求,到底要做一個怎樣的配置中心?數(shù)人云認(rèn)為,這個配置中心必須有一致性的K-V存儲中心,K-V存儲就是說,一個K對應(yīng)一個V,而且這種存儲必須持久化、可追溯。
它必須是可以集中統(tǒng)一配置,實時推送,以及馬上生效。
所有配置都必須實現(xiàn)灰度更新與回滾。所謂灰度發(fā)布,是說一個微服務(wù)集群里面,比如有個訂單系統(tǒng),做了一些配置上的更新。想在小范圍探討一下,實驗一下這個配置對業(yè)務(wù)有怎樣的影響,這時就用到灰度更新這個概念。
灰度更新是說,通過Data center或靜態(tài)IP,指定某個配置只對某幾個IP,或者Datacenter里面的某個服務(wù)生效,其他的不在這個范圍內(nèi)的服務(wù),不會受到影響。觀察效果,如果OK,就把這個整體配置全面推送到所有的微服務(wù)。如果效果不滿意,就把配置回滾到原來的狀態(tài)。
全量更新,灰度更新,或者回滾,必須是可在任何時候查看,在某一個任意的時刻,回滾到某一個歷史點的配置。
最后一個是要有多集群的啟動,所謂多集群的啟動就是,我們把配置存儲的時候,必須存儲在一個多集群的環(huán)境里面,以達(dá)到物理隔離的目的。
另外還有一些原則,業(yè)務(wù)無關(guān)性、 Open API、配置生效監(jiān)控。就是說配置中心必須提供API給第三方的系統(tǒng)來使用。配置的生效監(jiān)控是,必須實時知道,有哪些服務(wù)拉取了配置,是否已經(jīng)生效,或者這個配置的效果如何?
配置中心的支撐體系
第一種運維管理體系類似于偏靜態(tài)類的配置,在啟動時通過配置文件直接拉取讀業(yè)務(wù)。
另外一種是開發(fā)管理體系,偏動態(tài)管理,代表的是一種程序或者在運行過程中,通過實時的變更配置內(nèi)容而實時生效,達(dá)到的一種效果。
一個健全的配置中心應(yīng)該支持這兩種運維體系。
配置中心的微服務(wù)兼容
配置中心必須對現(xiàn)有主流的一些開發(fā)框架有API方面的兼容。數(shù)人云在做配置中心時,很難預(yù)估第三方來調(diào)用服務(wù)時,到底搭配在什么樣的開發(fā)框架上?通常來說,配置中心不可能兼容市面上所有的東西,數(shù)人云選擇重要的框架來做深度兼容。
首先,對Spring Cloud,阿里的Dubbo這些常規(guī)的第三方云服務(wù)框架做了API方面的兼容。目前來說,至少要支持SpringCloud、Dubbo、Nginx、Tomcat、Logback等各方面的配置。
這種配置各有各的特性,所以我們就挑選了一些有經(jīng)典案例的,通用性的東西來做配置的集成,比如原生支持SpringBoot、Spring Cloud,集成支持k8s,就是k8s容器。
數(shù)人云hawk分布式統(tǒng)一配置中心
數(shù)人云分布式統(tǒng)一配置中心,取名Hawk。Hawk基于ETCD打造,主要解決把開發(fā)人員從復(fù)雜的業(yè)務(wù)流程和煩瑣的配置中解脫出來,讓開發(fā)人員只關(guān)注自己的業(yè)務(wù)代碼,把運維、配置這些剝離出去。同時降低服務(wù)部署、發(fā)布過程中的風(fēng)險。
基于微服務(wù)體系理念打造的分布式統(tǒng)一配置中心Hawk支持多種類型配置:如Spring Cloud、 Dubbo、Kubernetes Configmap、Logback、Linux Environment,具有完善的配置管理流程、配置實施推送、支持多集群多環(huán)境、多版本控制,更提供配置細(xì)粒度的管理如灰度管理、任意版本重置等豐富功能。
整個體系兼容開源社區(qū)的Spring Cloud Config以及Kubernetes的Configmap,極大降低使用者的學(xué)習(xí)門檻以及業(yè)務(wù)對平臺的耦合。相應(yīng)的管理流程也規(guī)范了配置的使用,降低配置帶來的發(fā)布錯誤等。
功能特性
對比主流框架,數(shù)人云HAWK有如下一些重要的功能特性:
支持配置實時推送以及實時生效,在程序的運行過程中,不能說把服務(wù)停下來才能更新,必須實時配置,實時生效。
支持多版本管理,配置不管哪個版本,都可以隨時查看、查閱以及激活歷史的版本,并做發(fā)布。
支持多集群環(huán)境,多環(huán)境配置。通過數(shù)據(jù)庫或者后端存儲,以達(dá)到支持SIT、UAT環(huán)境的體系。
優(yōu)美的監(jiān)控臺,提供多維度Dashboard以及監(jiān)控視圖,支持配置灰度和回滾。
支持?jǐn)?shù)據(jù)全局備份和回復(fù),進(jìn)一步提升配置數(shù)據(jù)的容災(zāi)能力。
提供OpenAPI,支持多系統(tǒng)集成的便利手段,支持配置應(yīng)急預(yù)案處理。
配置流程管理,完善的配置流程管理,確保配置下發(fā)前必須獲得確認(rèn)和授權(quán)。
認(rèn)證與授權(quán),提供LDAP集成,以及多角色權(quán)限管理。
支持操作審計,確保配置操作有據(jù)可查。
支持多種配置文件,Spring Cloud Config、Dubbo、Logback、Nginx、LinuxEnvironment、Tomcat。
支持Spring Cloud服務(wù)治理配置和管控,支持Spring Cloud自有的Hystrix的微服務(wù)治理如熔斷、Fallback等等。
無縫集成Kubernetes的Configmap以及Secrets,并提供增強的企業(yè)管理流程。
Hawk整體架構(gòu)
首先接入第一層是網(wǎng)關(guān),整體的存儲通過Hawk Server,下發(fā)到ETCD集群,ETCD集群再同步到K8S容器運行的平臺。
剛才有同學(xué)說Hawk跟阿波羅有相似的地方。在研究對比時,我們覺得阿波羅出于業(yè)務(wù)需求,有一些比較復(fù)雜的地方,決定把流程簡化。
先從數(shù)據(jù)遷移的狀態(tài)簡化成簡單的幾部分。比如新建一個配置,要么配置就被刪除了,直接一步到位。如果沒有這樣做,就面臨幾種情況,這個配置是否要小范圍的去做一些試探性的發(fā)布,這種情況可以走灰度發(fā)布,狀態(tài)變成灰度中,配置不允許更改。要么就是兩條路走,全量發(fā)布到所有服務(wù)上。要么就是放棄灰度回到之前的狀態(tài),放棄灰度后會去到已修改的狀態(tài)。
另外一種情況,新建一個配置,直接全量發(fā)布,狀態(tài)變成已發(fā)布狀態(tài),這時候是可更改的。但是每一次的更改,還是會回到原來那個狀態(tài)。這個更改要做灰度嗎?還是做發(fā)布?還是對發(fā)布有點后悔,不打算更改了?這時,從歷史版本里面找一個合適的版本,激活,然后再做一次發(fā)布,通過幾個簡單的回路,涵蓋了大部分的業(yè)務(wù)場景。
配置數(shù)據(jù)狀態(tài)變遷
Hawk Portal是主體的配置界面,用戶在界面上對配置進(jìn)行輸入、增刪、改查的管理。這些資料會有兩份,一份做通過Mysql做本地存儲,另一份通過Hawk Server直接同步到ETCD。
由于HAWK Server是同步到ETCD里面,也就是說ETCD相當(dāng)于另外一個數(shù)據(jù)庫,這當(dāng)中不存在數(shù)據(jù)之間的互相抄送,從而減低丟失數(shù)據(jù)的風(fēng)險。持久化,是說研發(fā)和運維在后臺做數(shù)據(jù)遷移,或者數(shù)據(jù)監(jiān)控時更有把握,更方便。
數(shù)人云HAWK其實有兩個ETCD,一個ETCD是做注冊發(fā)現(xiàn)的,Hawk Server、Hawk Portal都會注冊在里面,作為相關(guān)的組件。類比Spring Cloud Eureka,Eureka是注冊在Eureka Server里面的一個內(nèi)存列表,集群里面所有Server共享這個內(nèi)存信息。這個過程數(shù)人云做了簡化,所有信息全部注冊在ETCD里面。
ECTD集群由于是共享的,組件的狀態(tài)和一致性得到保障。Portal和Server之間不再通過Portal注冊在Server并通過心跳來維持關(guān)系而是通過共享持久化的ETCD,保證數(shù)據(jù)在任意時刻所看到的狀態(tài)都是一致的,從而保證了服務(wù)的注冊,以及服務(wù)發(fā)現(xiàn)的穩(wěn)定性。
Hawk和Eureka 選擇的路徑不一樣。Eureka是比較重量級的,HAWK則簡化了這個配置,簡化這種代碼的復(fù)雜性,重點提高系統(tǒng)的完整性,打造系統(tǒng)閉環(huán),通過一些相對簡單的方法,提高服務(wù)的穩(wěn)定性。
配置一旦通過Hawk Portal潛入本地數(shù)據(jù)庫,微服務(wù)的注冊服務(wù)是怎么實現(xiàn)配置呢?當(dāng)Portal寫入配置到本地數(shù)據(jù)庫時,同時也會通過服務(wù)Sever去同步到ETCD,ETCD里面存儲的信息,是一個持久化的數(shù)據(jù)。
通過Server實時從ETCD拉取配置,有時是運行的時候拉取,有時是啟動時拉取。啟動時拉取有兩種策略,啟動的時候拉取配置,存儲到本地作為靜態(tài)文件的配置,運行時候拉取,動態(tài)的變更實時生效。
在Web層其實也有一些問題需要解決,比如,因為我們不是一個開發(fā)框架,是奔著一個開源系統(tǒng)的方向去,所以要解決服務(wù)跟瀏覽器之間的授權(quán)。
數(shù)人云現(xiàn)在的做法是在本土數(shù)據(jù)庫存儲一些用戶的信息,但是并沒有采用傳統(tǒng)意義上的建Session來做驗證和授權(quán),而是通過動態(tài)下發(fā)JWT的形式,每一個請求動態(tài)下發(fā),根據(jù)我個人用戶的一些信息生成,每次的請求一來一去都有交換新的Token,每個Token實時生效并有續(xù)約的功能,來代替?zhèn)鹘y(tǒng)意義上的Session。
配置中心集成第三方框架與類庫
Hawk有一個第三方類庫集成,操作流程是這樣的:操作者通過UI調(diào)用HAWK后端的portal,通過Hawk Server把配置寫入ETCD。另外一些運營者和開發(fā)人員所持有的第三方服務(wù),通過集成Hawk Client來讀取配置。
Hawk也有新的迭代,跟Sharding-JDBC做了集成,JDBC 2.0的一些趨勢跟HAWK系統(tǒng)做了深度集成。服務(wù)通過實時讀取配置中心配置實現(xiàn)動態(tài)更改分庫分表的策略。
Q&A
Q1:實時更改分布分表策略?
A1:可以,Sharding JDBC 2.0就是重點實現(xiàn)這個功能,這也是Hawk與Sharding JDBC深度合作的成果
Q2:歷史數(shù)據(jù)怎么辦?
A2:歷史的數(shù)據(jù)其實都是持久化存儲的。如果有一天要回到某個歷史版本,可以隨時通過調(diào)取已發(fā)布的歷史。Hawk有一個版面叫發(fā)布?xì)v史。這里,每一個配置都有配置歷史可追尋,可以隨時查看或激活某個版本。激活的時候,需要用戶去選擇要做一個全鏈發(fā)布還灰度發(fā)布,還是說什么都不做。
Q3:是否支持ServiceMesh?
A3:目前來說ServiceMesh還是一個比較新的東西。如果ServiceMesh是獨立配置的話,其實可以支持到。但是ServiceMesh有非常多的特性,還不敢說100%可以支持得到。其實數(shù)人云也在做ServiceMesh相關(guān)的項目,就是說它以后還是有非常大的可能,還是要集成ServiceMesh配置中心里面做一個閉環(huán)。目前這個版本支持一些比較輕量的配置。
ServiceMesh中文網(wǎng)微信公眾號(ID:servicemesh),大量Istio、Conduit官方文檔翻譯版和技術(shù)干貨文章,歡迎關(guān)注。
Q4:開發(fā)環(huán)境和生產(chǎn)環(huán)境用哪一步驟?
A4:SIT和UI其實可以部署在一起,通過存儲隔離來做到。但是,不建議生產(chǎn)也部署在一起,生產(chǎn)還是建議獨立部署。生產(chǎn)還是物理隔離是最好的方案。
Q5:配置中心和服務(wù)中心是不是兩個系統(tǒng)?
A5:目前來說是兩個系統(tǒng),但是現(xiàn)在的想法是暫時的?,F(xiàn)在的想法是是不是把配置中心再擴大一點,不叫配置中心了,而是叫比如微服務(wù)服務(wù)平臺。服務(wù)平臺里把配置中心跟注冊中心都作為一個組件融入進(jìn)去,把一些跟業(yè)務(wù)無關(guān)的東西抽離出來,搭載一些公共的平臺上,以組件的形式去融入到這個平臺里面去。
Q6:開源有本地緩存嗎?
A6:目前來說沒有本地緩存,是直接獲取ETCD的東西,所以它是實時的,但是注冊中心里面會加入緩存。
Q7:一般哪些信息通過配置中心配置?
A7:非業(yè)務(wù)的東西,比如平時開發(fā)一個系統(tǒng),或者開發(fā)一個第三方系統(tǒng),我們都有所有的配置文件,比如數(shù)據(jù)庫的連接,跟治理相關(guān)的東西,或者一些國外的引用,都可以通過配置中心來配置,并且這種配置不僅僅是在頁面上的配置,有一個插件給它,啟動之后直接把這些配置導(dǎo)入到配置中心里面去,還可以通過啟動的時候把這種配置下發(fā)到本地,形成一個本地的靜態(tài)配置。
Q8:server如果斷開怎么處理?
A8:因為Server是多Server集群的,如果斷開了并不是說通過指定IP地址去訪問這個Server,而是通過注冊與發(fā)現(xiàn)去訪問這個Server,如果Server斷開了,其實也就是說他們之間沒有心跳了,他們就會嘗試去ETCD里面請求一個新的連接,而這個連接也會通過注冊與發(fā)現(xiàn),會發(fā)現(xiàn)其他的Server,這樣的話他們就會連接。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/68344.html
摘要:在研究數(shù)據(jù)時,你會發(fā)現(xiàn)數(shù)據(jù)集中存在一些缺失值。現(xiàn)在,我們將檢查每個變量中缺失值的百分比。我們可以使用適當(dāng)?shù)姆椒▉磔斎胱兞?,或者我們可以設(shè)置閾值,比如,并刪除具有超過缺失值的變量。讓我們首先使用已知觀察值的中值來填充列中的缺失值。 showImg(https://segmentfault.com/img/remote/1460000019178806); 介紹 你是否曾經(jīng)處理過具有一千多...
摘要:區(qū)塊鏈上的底層模型設(shè)計,實際上就是分別以比特幣和以太坊為代表的兩種模型比特幣的模型以太坊的模型而實際上二者的差異千差萬別,代表了兩種思路。以太坊的模型和銀行賬戶類似,在賬戶中記錄用戶的余額。 showImg(https://segmentfault.com/img/bVbt7zb?w=2779&h=1179); 6 月 18 日,F(xiàn)acebook 加密貨幣項目 Libra 發(fā)布的白皮書...
摘要:等硬件公司會倒閉或被公有云收購。公有云會用自己的產(chǎn)品取代現(xiàn)有一切基礎(chǔ)軟件,提供自己的操作系統(tǒng)數(shù)據(jù)庫以及一切。跟公有云相比,缺少一個核心超高的,服務(wù)等級協(xié)議,供應(yīng)商對客戶服務(wù)的質(zhì)量承諾,達(dá)不到服務(wù)質(zhì)量會有相應(yīng)的賠償。無法提供公有云的。作者簡介:張鑫,是世界上最早一批虛擬化開發(fā)者,是《系統(tǒng)虛擬化》一書的主要作者。2010年赴硅谷加入IaaS初創(chuàng)公司Cloud.com,是CloudStack核心架...
閱讀 2260·2023-04-25 14:50
閱讀 1233·2021-10-13 09:50
閱讀 1866·2019-08-30 15:56
閱讀 1839·2019-08-29 15:29
閱讀 2886·2019-08-29 15:27
閱讀 3548·2019-08-29 15:14
閱讀 1192·2019-08-29 13:01
閱讀 3299·2019-08-26 14:06