資訊專欄INFORMATION COLUMN
摘要：進程間通過網絡組成拓撲這是進程管理里最痛苦的部分。所以無論是不是有服務注冊和發(fā)現，對集群的拓撲建模，現網狀態(tài)的可視化都是必不可少的。也就是說文章的標題基礎設施服務化需要做哪些事情，我也不知道。
基礎設施服務化
所謂基礎設施服務化就是希望做到這個
當用戶需要獲取某個基礎設施的時候，比如一個redis的集群，或者mysql的集群，可以無需在釘釘上找管理員，無需用郵件提申請。在web界面上自助就可以搞定。
為什么這個問題會特別？相比較一下這兩個場景：
1、segmentfault提供了一個寫博客的功能，我利用segmentfault開了一個自己的博客。
2、aws提供了一個mysql集群管理的功能，我在aws開了自己的mysql集群
從用戶體驗來說有本質區(qū)別嗎？不都是通過web界面申請，然后獲得了一個用tcp連接對外提供的服務嗎？兩者的區(qū)別在于
1、在segmentfault上申請博客是在已有的segmentfault的cpu和硬盤的資源池里切出來了一份屬于我的。這個過程不牽涉到新的進程的啟動。
2、而mysql集群的申請開通是需要新的機器，需要新的進程。
“業(yè)務”和“運維”的分野就在這里。業(yè)務就是在不啟動新的進程的情況下，用已有進程切分資源給不同用戶使用。而運維就是起停進程，以達到擴縮整個資源池大小，給用戶提供服務。只要我們做的事情里牽涉到了進程的起停，我就認為我們是在做運維的工作，而不是在做業(yè)務邏輯。這些進程管理相關的服務一般都會被羅列一下場景：
1、新版本發(fā)布，升級已有集群（停進程，然后再起）
2、已有版本，部署新的集群（起進程）
3、已有集群擴容（起進程）
4、已有集群縮容（停進程）
5、已有集群的故障恢復（進程死了，再拉新的）
所謂的“發(fā)布變更”，其實就是圍繞進程管理組合出來的一堆服務。這些服務以http rest api之類的形式提供給用戶使用。
進程管理的工作分解我們可以把所有的進程管理工作按這個模型來理解
而且我絲毫不懷疑bash腳本套界面的有效性。它可以非常快地達到自助化管理的目的，極大提高用戶方的效率。從投入產出比的角度來說，我是支持這么來搞的。
但是運維所有工作的考量應該是有四方面的“效率”，“質量”，“成本”，“安全” https://segmentfault.com/a/1190000002965517 。這種bash腳本套界面的做法就是典型的效率至上，其他都不管的做法。我相信這樣的做法是無法兼顧到質量和安全。當你看到一個系統(tǒng)里沉淀了幾千個bash腳本，被不同的web界面暴露出去了。你能保證這些bash腳本都是安全的？他們的組合使用的效率又是安全的？
假設我們放棄了直接把一個長長的bash腳本web化的想法。那么我們仔細來看看這些bash腳本都在干什么。概括起來可以分為四個部分
我們來分別看這四個組成部分都是在干什么。最佳的解決方案又是什么。
進程鏡像的下發(fā)對于 golang 來說，進程鏡像下發(fā)可能就是scp拷貝一個可執(zhí)行文件就行了。但是很多的進程要能啟動，需要本地有一對關聯的庫。
曾經火過一段時間的 infrastructure as code，嘗試以描述依賴的方式把這個進程鏡像下發(fā)和運行時環(huán)境的問題描述清楚。但是構建在os的包管理（apt-get，yum），各種語言的包管理（pip，npm）之上外加各種補丁的依賴管理系統(tǒng)到頭來還是浮沙之上筑高臺。
目前最流行的是docker。它確實根本上解決了單機的依賴管理問題。一個進程該有一個什么樣的運行時環(huán)境，一個docker鏡像就搞定了。
進程拉起有標配的god或者supervisord，絕對是一種福氣。沒有標準的進程托管工具，需要自己寫各種拉起腳本的，非常低效，而且不容易做到健壯。這個方面還是首選 supervisord，把進程的起停很容易就標準化了。
比進程拉起這個動作更復雜的一個問題是決定在哪里拉起這個進程。所以有mesos，yarn這樣的資源管理工具。讓進程在多個主機上更合理的分割資源。這個方面可以吹得很厲害，解決了很多成本云云。但是大部分情況下手工靜態(tài)分配進程和主機的關系，足矣。省成本這個事情，行政命令比高科技管用多了。
進程間通過網絡組成拓撲這是進程管理里最痛苦的部分。當我們啟動了這些進程之后，進程之間是需要通過網絡互相通信的。如果兩個進程是通過本地文件系統(tǒng)的ipc機制通信，我們可以建模地時候把兩個進程變成一個進程組，當一個進程看待。那么這個問題就是進程A，要知道進程B在哪里。進程B又要知道進程A在哪里。
傳統(tǒng)的做法是進程A有自己的配置文件，這里要填進程B的ip和端口。進程B也有自己的配置文件，這里要填進程A的ip和端口。所以就有一個很復雜的配置管理生成的問題。
更好的做法是讓進程去做自動的互相發(fā)現。無非就是進程A把自己注冊到注冊表里，進程B可以從注冊表里取到。無論是使用zookeeper，etcd還是consul，這個過程都是類似的。很多復雜一些的開源軟件，都會預設一個集群管理方式。比如kafka自己要求有一個zookeeper來管理其內部的幾個節(jié)點。
即便是有了服務注冊和發(fā)現，也不是進程隨便拉起就撒手不管了。服務注冊和發(fā)現可以減輕你管理整個網絡拓撲的負擔，但是不能代替你去規(guī)劃這個網絡拓撲結構。進程啟動要加入到一個集群里做自發(fā)現，仍然需要知道兩個信息，我是什么角色的service，我在什么cluster里。把進程劃分為不同的cluster，又分為不同類型的service仍然是要提前規(guī)劃的。而進程都要掛在具體的cluster的具體的service下。只是說同類型的service啟動多個進程了，服務注冊和發(fā)現可以減輕一些這方面的管理負擔。
更復雜的集群可能要牽涉到跨cluster的互相訪問。也就是cluster組cluster。這個方面仍然是沒有最佳實踐的。比如codis集群內，其實是由多個redis group組成。
當我們面對這個一個網絡拓撲的管理問題的時候有兩個解法。進程自身其實是有一個自身狀態(tài)描述了這個拓撲的actual state，另外還有一份存在于你的設計文檔也好，你的配置管理系統(tǒng)也好，是一個 expected state。我們可以用腳本直接變更actual state，然后再去同步這些state回來到某個dashboard上。或者我們可以先改變dashboard上的expected state，然后再推倒出有哪些action需要做，去變更actual state。兩種方式都可以。但是不能只有腳本，而沒有任何的state的建模。如果只有腳本，我們對于集群狀態(tài)在變更之后實際上是什么情況是兩眼一抹黑的。我們認為主從切換了，但是是不是主從切換了是不能有一個中心的dashboard可視的。這就很可怕了。
所以無論是不是有服務注冊和發(fā)現，對集群的拓撲建模，現網狀態(tài)的可視化都是必不可少的。千萬不能只有一堆腳本，kuangkuangkuang執(zhí)行完了，實際線上是什么個狀態(tài)完全不知道。
更新與網絡拓撲相關的進程狀態(tài)大部分的進程狀態(tài)是不屬于運維范疇的。比如安裝完了一個訂單管理系統(tǒng)，需要把城市列表導入到數據庫里。沒有人會認為這個城市列表導入會是運維工作的職責。但是安裝完了一個codis集群，需要把codis集群里的redis group與slot range對應上，所有人都認為這個應該是運維工作的一部分。為什么？根本原因是data partition的配置，與網絡拓撲是相關的。因為網絡拓撲是運維來組的，所以凡是和網絡拓撲有關的配置，都和運維有關系。
這個和前面的網絡相關的配置是類似的。只是在組網的時候，我們認為一個service就是網絡的ip和端口兩個屬性是有價值的。在配置data partition的時候，我們還要知道service具體是負責了什么數據。是負責了熱數據還是冷數據。是負責哪個數據分片。如果我們的cluster和service建模得好，管理得好。這些屬性完全就是ip和端口之外擴展的kv對而已。如果我們前一個工作做得不好，那么這些更復雜的狀態(tài)的管理就更加是一個災難。
數據分片更復雜的一點是它是有狀態(tài)服務的狀態(tài)的體現。把一個group遷移一些slot到另外一個group，不僅僅是一個配置變換，不僅僅是進程的起停，還包括這些配置對應的實際數據的搬遷。
但這個問題仍然是一個狀態(tài)管理的問題。我們有一個注冊表登記了group對應了哪些slot，這是一份登記的state。而這個group實際上是不是包含了這些slot，進程自己心里有數，這是一份actual的state。本質上還是state管理，actual state和expected state的同步問題。
總結現有的運維的工具很好的解決了進程管理中四個問題里最簡單的兩個問題，鏡像的下發(fā)（docker）和進程拉起（supervisord）。但是對于組網和數據分片管理，這兩個state management問題，仍然有太多的open question。更多的解決方案是個例地，腳本化的解決一些問題。沒有一個framework來系統(tǒng)性地對集群狀態(tài)管理問題給一個解決方案。也就是說文章的標題“基礎設施服務化需要做哪些事情”，我也不知道。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規(guī)行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/7974.html
摘要：云計算從概念萌芽期如今正在成為基礎設施的水和電。他們共同對云計算的下一步發(fā)展特點以及企業(yè)關注重點等問題進行了討論。所以，在國內說云計算發(fā)展的下一個階段似乎比下半場更加合適，那么下一個階段將有哪些新的特點呢各位嘉賓也提出了自己的看法。 云計算可以說是近幾年企業(yè)服務發(fā)展最快的領域之一，同時也是產業(yè)互聯網發(fā)展的基礎。云計算從概念萌芽期如今正在成為 IT 基礎設施的水和電。12 月 21 日，幾位云...
摘要：聯合創(chuàng)建青云后，林源承擔了數年首席架構師的工作，目前擔任青云的產品總監(jiān)兼運營副總裁。在未來，青云的客戶看不見青云，他們消費的是我們合作伙伴提供的服務。 showImg(https://segmentfault.com/img/remote/1460000012292093?w=640&h=416); AI（人工智能）一詞，可能早已經爛大街了，說起它，橋下貼膜的小哥也能和你說出個一二三來...
摘要：我們使用了很多的公共云資源，自己也建立了私有的云計算中心。那你們會給騰訊提供一些這方面的建議嗎會的，我們跟他們合作密切，我們之間的交流很頻繁。 Cadir Lee，現任Zynga CTO，統(tǒng)管公司的技術平臺和海量基礎架構的研發(fā)和創(chuàng)新。他管理數據分析、網絡運維、安全等方面的團隊。在加入Zynga之前，他擔任Support.com的CTO11年之久，而Support.com也是他和Zynga創(chuàng)始...
摘要：摘要智能監(jiān)控是智能運維的子領域，詳細分析。我和我的團隊在阿里內部的分工是橫向去看阿里巴巴業(yè)務指標的監(jiān)控，我們就以這個話題展開。分享分為五個環(huán)節(jié)，從阿里巴巴不同的業(yè)態(tài)，特別是新的業(yè)態(tài)帶來的挑戰(zhàn)講起。 摘要：?智能監(jiān)控是智能運維的子領域，詳細分析。 showImg(https://segmentfault.com/img/remote/1460000017348788); 作者簡介 王肇...
摘要：打好地基三年做架構分析李寧沙爽盲目崇拜云計算有風險李寧沙爽盲目崇拜云計算有風險李寧沙爽年年末，沙爽離開聯想集團來到李寧公司就任信息技術總監(jiān)一職，試用期滿后，代替轉正報告交上去的是他用三個月時間撰寫的頁李寧集團未來三年組織業(yè)務規(guī)劃書。 提及家喻戶曉的李寧集團，這家?guī)缀跻殉蔀閲蓑湴恋钠髽I(yè)目前正在將步伐邁向信息化道路。其中，信息技術系統(tǒng)部門功不可沒。李寧公司信息技術系統(tǒng)總監(jiān)沙爽表示，他的團隊致力...
閱讀 2112·2021-11-05 09:42
閱讀 2855·2021-09-23 11:21
閱讀 2848·2019-08-30 14:00
閱讀 3318·2019-08-30 13:15
閱讀 467·2019-08-29 17:18
閱讀 3556·2019-08-29 16:29
閱讀 2754·2019-08-29 14:06
閱讀 2799·2019-08-23 14:41
