如何設計高可用的配置中心

⑴ 開發自動化運維架構六要素

運維自動化是我們所渴望獲得的，但是我們在一味強調自動化能力時，卻忽略了影響自動化落地的一個關鍵因素。那便是跟運維朝夕相處，讓人又愛又恨的業務架構。
要點一：架構獨立
任何架構的產生都是為了滿足特定的業務訴求，如果我們在滿足業務要求的同時，能夠兼顧運維對架構管理的非功能性要求。那麼我們有理由認為這樣的架構是對運維友好的。
站在運維的角度，所訴求的架構獨立包含四個方面：獨立部署，獨立測試，組件化和技術解耦。
獨立部署
指的是一份源代碼，可以按照便於運維的管理要求去部署、升級、伸縮等，可通過配置來區分地域分布。服務間相互調用通過介面請求實現，部署獨立性也是運維獨立性的前提。
獨立測試
運維能夠通過一些便捷的測試用例或者工具，驗證該業務架構或服務的可用性。具備該能力的業務架構或服務讓運維具備了獨立上線的能力，而不需要每次發布或變更都需要開發或測試人員的參與。
組件規范
指的是在同一個公司內對相關的技術能有很好的框架支持，從而避免不同的開發團隊使用不同的技術棧或者組件，造成公司內部的技術架構失控。
這種做法能夠限制運維對象的無序增加，讓運維對生產環境始終保持著掌控。同時也能夠讓運維保持更多的精力投入，來圍繞著標准組件做更多的效率與質量的建設工作。
技術解耦
指的是降低服務和服務之間相互依賴的關系，也包含了降低代碼對配置文件的依賴。這也是實現微服務的基礎，實現獨立部署、獨立測試、組件化的基礎。
要點二：部署友好
DevOps 中有大量的篇幅講述持續交付的技術實踐，希望從端到端打通開發、測試、運維的所有技術環節，以實現快速部署和交付價值的目標。可見，部署是運維日常工作很重要的組成部分，是屬於計劃內的工作，重復度高，必須提升效率。
實現高效可靠的部署能力，要做好全局規劃，以保證部署以及運營階段的全方位運維掌控。有五個緯度的內容是與部署友好相關的：
CMDB配置
在每次部署操作前，運維需要清晰的掌握該應用與架構、與業務的關系，為了更好的全局理解和評估工作量和潛在風險。
在織雲自動化運維平台中，我們習慣於將業務關系、集群管理、運營狀態、重要級別、架構層等配置信息作為運維的管理對象納管於CMDB配置管理資料庫中。這種管理辦法的好處很明顯，集中存儲運維對象的配置信息，對日後涉及的運維操作、監控和告警等自動化能力建設，將提供大量的配置數據支撐和決策輔助的功效。
環境配置
在運維標准化程度不高的企業中，阻礙部署交付效率的原罪之一便是環境配置，這也是容器化技術主要希望解決的運維痛點之一。
騰訊的運維實踐中，對開發、測試、生產三大主要環境的標准化管理，通過枚舉納管與環境相關的資源集合與運維操作，結合自動初始化工具以實現標准環境管理的落地。
依賴管理
解決應用軟體對庫、運營環境等依賴關系的管理。在織雲實踐經驗中，我們利用包管理，將依賴的庫文件或環境的配置，通過整體打包和前後置執行腳本的方案，解決應用軟體在不同環境部署的難題。業界還有更輕量的容器化交付方法，也是不錯的選擇。
部署方式
持續交付原則提到要打造可靠可重復的交付流水線，對應用軟體的部署操作，我們也強烈按此目標來規劃。業界有很多案例可以參考，如Docker的Build、Ship、Run，如織雲的通過配置描述、標准化流程的一鍵部署等等。
發布自測
發布自測包含兩部分：
應用的輕量級測試；
發布/變更內容的校對。
建設這兩種能力以應對不同的運維場景需求，如在增量發布時，使用發布內容的校對能力，運維人員可快速的獲取變更文件md5，或對相關的進程和埠的配置信息進行檢查比對，確保每次發布變更的可靠。
同理，輕量級測試則是滿足發布時對服務可用性檢測的需求，此步驟可以檢測服務的連通性，也可以跑些主幹的測試用例。
灰度上線
在《日常運維三十六計》中有這么一句話：對不可逆的刪除或修改操作，盡量延遲或慢速執行。這便是灰度的思想，無論是從用戶、時間、伺服器等緯度的灰度上線，都是希望盡量降低上線操作的風險，業務架構支持灰度發布的能力，讓應用部署過程的風險降低，對運維更友好。
要點三：可運維性
運維腦海中最理想的微服務架構，首當其沖的肯定是可運維性強的那類。不具可運維性的應用或架構，對運維團隊帶來的不僅僅是黑鍋，還有對他們職業發展的深深的傷害，因為維護一個沒有可運維性的架構，簡直就是在浪費運維人員的生命。
可運維性按操作規范和管理規范可以被歸納為以下七點：
配置管理
在微服務架構管理中，我們提議將應用的二進制文件與配置分離管理，以便於實現獨立部署的目的。
被分離出來的應用配置，有三種管理辦法：
文件模式；
配置項模式；
分布式配置中心模式。
限於篇幅不就以上三種方式的優劣展開討論。不同的企業可選用最適用的配置管理辦法，關鍵是要求各業務使用一致的方案，運維便可以有針對性的建設工具和系統來做好配置管理。
版本管理
DevOps持續交付八大原則之一「把所有的東西都納入版本控制」。就運維對象而言，想要管理好它，就必須能夠清晰的描述它。
和源代碼管理的要求類似，運維也需要對日常操作的對象，如包、配置、腳本等都進行腳本化管理，以備在運維系統在完成自動化操作時，能夠准確無誤的選定被操作的對象和版本。
標准操作
運維日常有大量重復度高的工作需要被執行，從精益思想的視角看，這里存在極大的浪費：學習成本、無價值操作、重復建設的腳本/工具、人肉執行的風險等等。
倘若能在企業內形成統一的運維操作規范，如文件傳輸、遠程執行、應用啟動停止等等操作都被規范化、集中化、一鍵化的操作，運維的效率和質量將得以極大的提升。
進程管理
包括應用安裝路徑、目錄結構、規范進程名、規范埠號、啟停方式、監控方案等等，被收納在進程管理的范疇。做好進程管理的全局規劃，能夠極大的提升自動化運維程度，減少計劃外任務的發生。
空間管理
做好磁碟空間使用的管理，是為了保證業務數據的有序存放，也是降低計劃外任務發生的有效手段。
要求提前做好的規劃：備份策略、存儲方案、容量預警、清理策略等，輔以行之有效的工具，讓這些任務不再困擾運維。
日誌管理
日誌規范的推行和貫徹需要研發密切配合，在實踐中得出的經驗，運維理想中的日誌規范要包含這些要求：
業務數據與日誌分離
日誌與業務邏輯解耦
日誌格式統一
返回碼及注釋清晰
可獲取業務指標（請求量/成功率/延時）
定義關鍵事件
輸出級別
管理方案（存放時長、壓縮備份等）
當具體上述條件的日誌規范得以落地，開發、運維和業務都能相應的獲得較好的監控分析能力。
集中管控
運維的工作先天就容易被切割成不同的部分，發布變更、監控分析、故障處理、項目支持、多雲管理等等，我們訴求一站式的運維管理平台，使得所有的工作信息能夠銜接起來和傳承經驗，杜絕因為信息孤島或人工傳遞信息而造成的運營風險，提升整體運維管控的效率和質量。
要點四：容錯容災
在騰訊技術運營（運維）的四大職責：質量、效率、成本、安全。質量是首要保障的陣地，轉換成架構的視角，運維眼中理想的高可用架構架構設計應該包含以下幾點：
負載均衡
無論是軟體或硬體的負責均衡的方案，從運維的角度出發，我們總希望業務架構是無狀態的，路由定址是智能化的，集群容錯是自動實現的。
在騰訊多年的路由軟體實踐中，軟體的負載均衡方案被廣泛應用，為業務架構實現高可用立下汗馬功勞。
可調度性
在移動互聯網盛行的年代，可調度性是容災容錯的一項極其重要的運維手段。在業務遭遇無法立刻解決的故障時，將用戶或服務調離異常區域，是海量運營實踐中屢試不爽的技巧，也是騰訊QQ和微信保障平台業務質量的核心運維能力之一。
結合域名、VIP、接入網關等技術，讓架構支持調度的能力，豐富運維管理手段，有能力更從容的應對各種故障場景。
異地多活
異地多活是數據高可用的訴求，是可調度性的前提。針對不同的業務場景，技術實現的手段不限。
騰訊社交的實踐可以參考周小軍老師的文章「2億QQ用戶大調度背後的架構設計和高效運營」。
主從切換
在資料庫的高可用方案中，主從切換是最常見的容災容錯方案。通過在業務邏輯中實現讀寫分離，再結合智能路由選擇實現無人職守的主從切換自動化，無疑是架構設計對DBA最好的饋贈。
柔性可用
「先扛住再優化」是騰訊海量運營思想之一，也為我們在做業務架構的高可用設計點明了方向。
如何在業務量突增的情況下，最大程度的保障業務可用？是做架構規劃和設計時不可迴避的問題。巧妙的設置柔性開關，或者在架構中內置自動拒絕超額請求的邏輯，能夠在關鍵時刻保證後端服務不雪崩，確保業務架構的高可用。
要點五：質量監控
保障和提高業務質量是運維努力追逐的目標，而監控能力是我們實現目標的重要技術手段。運維希望架構為質量監控提供便利和數據支持，要求實現以下幾點：
指標度量
每個架構都必須能被指標度量，同時，我們希望的是最好只有唯一的指標度量。對於業務日趨完善的立體化監控，監控指標的數量隨之會成倍增長。因此，架構的指標度量，我們希望的是最好只有唯一的指標度量。
基礎監控
指的是網路、專線、主機、系統等低層次的指標能力，這類監控點大多屬於非侵入式，很容易實現數據的採集。
在自動化運維能力健全的企業，基礎監控產生的告警數據絕大部分會被收斂掉。同時，這部分監控數據將為高層次的業務監控提供數據支撐和決策依據，或者被包裝成更貼近上層應用場景的業務監控數據使用，如容量、多維指標等。
組件監控
騰訊習慣把開發框架、路由服務、中間件等都統稱為組件，這類監控介於基礎監控和業務監控之間，運維常寄希望於在組件中內嵌監控邏輯，通過組件的推廣，讓組件監控的覆蓋度提高，獲取數據的成本屬中等。如利用路由組件的監控，運維可以獲得每個路由服務的請求量、延時等狀態和質量指標。
業務監控
業務監控的實現方法分主動和被動的監控，即可侵入式實現，又能以旁路的方式達到目的。這類監控方案要求開發的配合，與編碼和架構相關。
通常業務監控的指標都能歸納為請求量、成功率、延時3種指標。實現手段很多，有日誌監控、流數據監控、波測等等，業務監控屬於高層次的監控，往往能直接反饋業務問題，但倘若要深入分析出問題的根源，就必須結合必要的運維監控管理規范，如返回碼定義、日誌協議等。需要業務架構在設計時，前置考慮運維監控管理的訴求，全局規劃好的范疇。
全鏈路監控
基礎、組件、業務的監控手段更多的是聚焦於點的監控，在分布式架構的業務場景中，要做好監控，我們必須要考慮到服務請求鏈路的監控。
基於唯一的交易ID或RPC的調用關系，通過技術手段還原調用關系鏈，再通過模型或事件觸發監控告警，來反饋服務鏈路的狀態和質量。該監控手段屬於監控的高階應用，同樣需要業務架構規劃時做好前置規劃和代碼埋點。。
質量考核
任何監控能力的推進，質量的優化，都需要有管理的閉環，考核是一個不錯的手段，從監控覆蓋率、指標全面性、事件管理機制到報表考核打分，運維和開發可以攜手打造一個持續反饋的質量管理閉環，讓業務架構能夠不斷進化提升。
要點六：性能成本
在騰訊，所有的技術運營人員都肩負著一個重要的職能，就是要確保業務運營成本的合理。為此，我們必須對應用吞吐性能、業務容量規劃和運營成本都要有相應的管理辦法。
吞吐性能
DevOps持續交付方法論中，在測試階段進行的非功能需求測試，其中很重要一點便是對架構吞吐性能的壓測，並以此確保應用上線後業務容量的健康。
在騰訊的實踐中，不僅限於測試階段會做性能壓測，我們會結合路由組件的功能，對業務模塊、業務SET進行真實請求的壓測，以此建立業務容量模型的基準。也從側面提供數據論證該業務架構的吞吐性能是否達到成本考核的要求，利用不同業務間性能數據的對比，來推動架構性能的不斷提高。
容量規劃
英文capacity一詞可以翻譯成：應用性能、服務容量、業務總請求量，運維的容量規劃是指在應用性能達標的前提下，基於業務總請求量的合理的服務容量規劃。
運營成本
減少運營成本，是為公司減少現金流的投入，對企業的價值絲毫不弱於質量與效率的提升。
騰訊以社交、UGC、雲計算、游戲、視頻等富媒體業務為主，每年消耗在帶寬、設備等運營成本的金額十分巨大。運維想要優化運營成本，常常會涉及到產品功能和業務架構的優化。因此，運維理想的業務架構設計需要有足夠的成本意識，
小結
本文純屬個人以運維視角整理的對微服務架構設計的一些愚見，要實現運維價值最大化，要確保業務質量、效率、成本的全面提高，業務架構這塊硬骨頭是不得不啃的。
運維人需要有架構意識，能站在不同角度對業務架構提出建議或需求，這也是DevOps 精神所提倡的，開發和運維聯手，持續優化出最好的業務架構。

⑵ 如何設計一個支持高並發的高可用服務

服務程序最為關鍵的設計是並發服務模型，當前有以下幾種典型的模型：-單進程服務，使用非阻塞IO使用一個進程服務多個客戶，通常與客戶通信的套接字設置為非阻塞的，阻塞只發生在select()、poll()、epoll_wait()等系統調用上面。這是一種行之有效的單進程狀態機式服務方式，已被廣泛採用。缺點是它無法利用SMP(對稱多處理器)的優勢，除非啟動多個進程。此外，它嘗試就緒的IO文件描述符後，立即從系統調用返回，這會導致大量的系統調用發生，尤其是在較慢的位元組傳輸時。select()本身的實現也是有局限的：能打開的文件描述符最多不能超過FD_SETSIZE，很容易耗盡；每次從select()返回的描述符組中掃描就緒的描述符需要時間，如果就緒的描述符在末尾時更是如此（epoll特別徹底修復了這個問題）。-多進程服務，使用阻塞IO也稱作accept/fork模型，每當有客戶連線時產生一個新的進程為之服務。這種方式有時是必要的，比如可以通過操作系統獲得良好的內存保護，可以以不同的用戶身份運行程序，可以讓服務運行在不同的目錄下面。但是它的缺點也很明顯：進程比較占資源，進程切換開銷太大，共享某些信息比較麻煩。Apache1.3就使用了這種模型，MaxClients數很容易就可以達到。-多線程服務，使用阻塞IO也稱之accept/pthread_create模型，有新客戶來時創建一個服務線程而不是服務進程。這解決了多進程服務的一些問題，比如它佔用資源少，信息共享方便。但是麻煩在於線程仍有可能消耗光，線程切換也需要開銷。-混合服務方式所謂的混合服務方式，以打破服務方和客戶方之間嚴格的1:1關系。基本做法是：新客戶到來時創建新的工作線程，當該工作線程檢測到網路IO會有延遲時停止處理過程，返回給Server一個延遲處理狀態，同時告訴Server被延遲的文件描述符，延遲超時時間。Server會在合適的時候返回工作線程繼續處理。注意這里的工作線程不是通過pthread_create()創建的，而是被包裝在專門用於處理延遲工作的函數里。這里還有一個問題，工作線程如何檢測網路IO會有延遲？方法有很多，比如設置較短的超時時間調用poll()，或者甚至使用非阻塞IO。如果是套接字，可以設置SO_RCVTIMEO和SO_SNDTIMEO選項，這樣更有效率。除了延遲線程，Server還應提供了未完成線程的支持。如有有特別耗費時間的操作，你可以在完成部分工作後停止處理，返回給Server一個未完成狀態。這樣Server會檢查工作隊列是否有別的線程，如果有則讓它們運行，否則讓該工作線程繼續處理，這可以防止某些線程挨餓。典型的一個混合服務模型開源實現ServerKitServerkit的這些線程支持功能可簡化我們的服務程序設計，效率上應該也是有保證的。2.隊列(queue)ServerKit提供的隊列是一個單向鏈表，隊列的存取是原子操作，如果只有一個執行單元建議不要用，因為原子操作的開銷較大。3.堆(heap)malloc()分配內存有一定的局限，比如在多線程的環境里，需要序列化內存分配操作。ServerKit提供的堆管理函數，可快速分配內存，可有效減少分配內存的序列化操作，堆的大小可動態增長，堆有引用計數，這些特徵比較適合多線程環境。目前ServerKit堆的最大局限是分配單元必須是固定大小。4.日誌記錄日誌被保存在隊列，有一個專門的線程處理隊列中的日誌記錄：它或者調用syslog()寫進系統日誌，或者通過UDP直接寫到遠程機器。後者更有效。5.讀寫鎖GNUlibc也在pthreads庫里實現了讀寫鎖，如果定義了__USE_UNIX98就可以使用。不過ServerKit還提供了讀寫鎖互相轉換的函數，這使得鎖的應用更為彈性。比如擁有讀鎖的若干個線程對同一個hash表進行檢索，其中一個線程檢索到了數據，此時需要修改它，一種法是獲取寫鎖，但這會導致釋放讀鎖和獲取寫鎖之間存在時間窗，另一種法是使用ServerKit提供的函數把讀鎖轉換成寫鎖，無疑這種方式更有效率。除了以上這些功能，ServerKit還提供了資料庫連接池的管理（當前只支持MySQL）和序列化（Sequences），如感興趣可參見相關的API文檔。二、ServerKit服務模塊編寫ServerKit由3部分組成：server程序，負責載入服務模塊、解析配置文件、建立資料庫連接池；libserver，動態鏈接庫，提供所有功能的庫支持，包括server本身也是調用這個庫寫的；API，編程介面，你編寫的服務模塊和ServerKit框架進行對話的介面。ServerKit需要libConfuse解析配置文件，所以出了安裝ServerKit，還需要安裝libConfuse。關於libConfuse可參考。下面我們看一個簡單的服務模塊FOO：#include#includestaticlongintsleep_ration;staticintFOO_construct(){fprintf(stderr,"FOO_construct\n");return1;}staticintFOO_prestart(cfg_t*configuration){fprintf(stderr,"FOO_prestart\n");return1;}staticvoid*FOO_operator(void*foobar){fprintf(stderr,"FOO_operator\n");for(;;)sleep(sleep_ration);returnNULL;}staticvoidFOO_report(void){fprintf(stderr,"FOO_report\n");}staticcfg_opt_tFOO_config[]={CFG_SIMPLE_INT("sleep_ration",&sleep_ration),CFG_END()};staticchar*FOO_authors[]={"VitoCaputo",NULL};SERVER_MODULE(FOO,0,0,1,"")按以下方法編譯：$gcc-c-fPIC-pthread-D_REENTRANT-gFOO.c$gcc-shared-lserver-lconfuse-lpthread-g-e__server_mole_main-oFOO.soFOO.o-e選項指定程序運行入口，這使得你可以直接在命令行敲./FOO.so運行模塊。server程序根據環境變數SERVER_PERSONALITY_PATH定位主目錄，並查找主目錄下的c11n作為配置文件，動態載入的模塊需放在主目錄下的moles目錄。$exportSERVER_PERSONALITY_PATH=`pwd`$mkdirmoles$cpFOO.somoles$vic11nc11n的內容：identity="any_id"FOO{sleep_ration=1;}identity標識server實例，用ps可看到程序名稱形如server.identity，本例為server.any_id。執行server啟動服務程序。三、ServerKit其他功能缺陷缺乏daemon模式；只能運行在linuxbox；DBpool只支持MySQL；Heap管理內存的功力有限

⑶ 靜脈葯物配置中心如何設計建設

喜格實驗室工程：靜脈葯物配置中心設計建設，如下
1靜脈葯物配置中心的建立
1.1某院PIVAS位於醫院醫技樓六樓，便於葯品運輸和成品配送，便於配製管理和環境控制，水電等基礎條件符合規定。其面積309m2，設計合理，流程順暢。主要功能區域包括排葯、貯葯、充配、信息、核發、更衣、洗潔等;配有6台生物安全櫃和先進的空氣凈化系統。無菌工作間有嚴密的隔離措施及消毒設備，進入工作間，必須經過兩道隔離門，並安裝了空調設備。工程完工後由具有檢測資質的單位對凈化系統進行靜態檢測，沉降菌、微粒、噪音、照度、換氣次數、溫濕度等各項指標達標後，方才投入使用。保證了潔凈室的潔凈度，從而確保臨床用葯安全。
1.2某院PIVAS的管理模式採用以葯為主，由葯劑科負責日常工作管理，護理部負責護理人員的配備，現有葯師5名，護師13名，工友2名，為醫院19個病區進行服務，每天提供約1 500袋靜脈液體。葯學人員主要負責審方、排葯、加葯、核對、葯品管理等;護理人員職責為復核、沖配、幫助排葯;工勤人員需及時運送葯品與打掃衛生等。
1.3信息系統是實現靜脈葯物配製的基礎，分管院長多次召集葯劑科、護理部、醫務處、信息科的相關人員協調工作、統一認識確定電腦程序。電腦信息系統包括處方傳輸、標簽列印、葯費支付、葯品管理、咨詢服務、葯歷生成;標簽內容應包括患者基本信息、葯品處方信息、配製核對信息等，是葯師審核用葯與記錄配製過程的重要憑證。信息管理系統應設置管理許可權，完善數據統計的功能，自動生成批次，實行配置全程化管理。另外還將在系統中嵌入配伍監控系統，對用葯實施合理用葯監控。
2靜脈葯物配置中心工作流程設計
2.1醫生按照《處方管理辦法》有關規定開具靜脈用葯處方，由專人將處方輸入醫院的信息系統中。處方可分為兩類：長期處方與臨時處方。病區負責按規定時間將患者次日需要靜脈輸液的長期處方傳送至PIVAS，臨時處方按照醫院的相關規定和要求傳入PIVAS。
2.2 PIVAS的葯師接收到處方後，逐一核對患者處方信息，審核確認其正確性、合理性與完整性。對於處方存在錯誤的，及時與醫生溝通，請其調整並簽名。對於處方存在錯誤而醫生拒絕不同意修改的，拒絕調配，並報請相關部門協調解決。
2.3經葯師審核通過的處方列印成處方標簽，標簽上需有患者姓名、病區、床號、日期、處方組成、自動生成的編號等內容，且要有各個工序簽名或蓋章的空間，標簽需能貼到輸液瓶(袋)上。
2.4葯師接到審方合格的標簽，應仔細核查標簽內容是否准確、完整，如有錯誤或不全應告知審方葯師校對糾正。葯師根據審核後的標簽上所列葯物的順序，按照其性質、不同的用葯時間，分批次將葯品放置於不同顏色的容器中，並在標簽上簽名或蓋章，按照病區、葯物的不同性質放置於不同的配置間內。
2.5配置間為潔凈間，潔凈級別為萬級，按照配置葯物的種類不同可分為普通葯物與全靜脈營養葯配置間、抗生素與細胞毒性葯物配置間。普通葯物與全靜脈營養葯配置間需配備凈化層流台，使配置環境達到百級，從而保證葯品不被污染。抗生素與細胞毒性葯物配置間主要配置含有抗生素或細胞毒性葯物的處方，本房間配備生物安全櫃，使配置環境的潔凈級別達到百級，且為負壓，從而防止葯品對工作人員的傷害。護士嚴格遵守無菌操作原則及時充配好葯品並在其標簽上簽名或蓋章。
2.6完成沖配的葯物經傳遞窗或傳送帶等方式傳送到成品核對包裝區，進行再次核對與確認，並按照病區分類裝入密閉的容器中，並附成品隨行單，由專人送至各個病區。病區護士接收並核對，無誤後，給患者用葯。盛放葯物的容器需能密封，且定期消毒，避免沖配好的葯物受到二次污染。

⑷ 如何設定伺服器中心

這樣說的話
中心伺服器就是將兩個分公司的伺服器，通過中心伺服器來互聯，在中心服務上生成一個公鑰 和私鑰文件，生成之後會提示文件的存放位置，將公鑰文件發給要集群的伺服器，在中心伺服器上添加企業，輸入名稱和總機號碼，密碼可以設置，也可以不設置。在子公司的RTX伺服器上RCA管理器中配置中心伺服器連接，輸入中心伺服器的ip導入公鑰文件，然後配置共享的組織架構。如果有不明白的M我吧。連接是實現文檔。

⑸ 基於DNS搭建高可用Eureka注冊中心

按Alt + 回車鍵，將會生成eureka-server.zip，解壓縮後得到一個maven 項目，將該項目錄入IDE。

我們首先來看一下pom文件，可以看出項目中引用了spring-cloud-starter-netflix-eureka-server, 並且springboot 的版本號為：2.1.2.RELEASE, Spring Cloud的版本號為：Greenwich.RC2RC2 表示還沒有正式發布，只是第二個Release Candidate。
接下來我們只需要兩個步驟，
a、修改EurekaServerApplication, 在@SpringBootApplication的註解上面，加入一個新的註解：@EnableEurekaServer
b、在resources 目錄中加入application.yml 文件， 並配置以下信息：

一個簡單的Eureka 注冊中心就已經可以使用了，我們運行一下這個spring boot 應用，找開瀏覽器：localhost:8761，即可看到我們的注冊中心就已經運行啟來了。並且EUREKA-SERVER也注冊到自己的注冊中心了。

單節點的注冊中心已經搭建完畢，但單節點的注冊中心存在單點故障的可能，不能用於生產環境。生產環境的Eureka一般採用集群方式進行部署。

通過client.serviceUrl.defaultZone配置多個peer節點，因為是在單機上測試，所以修改了host文件，並且使用不同的埠號來啟動注冊中心。正式的生產環境請根據自己的實際情況進行配置，比如：第一台Eureka的IP地址為：192.168.0.100，則defaultZone配置其他三台注冊中心http://192.168.0.101:8761/eureka/,http://192.168.0.102:8761/eureka/,http://192.168.0.103:8761/eureka/
依次啟動4台注冊中心，打開網頁:http://localhost:8764

可以看到其它三台注冊中心已經出現在已注冊的replicas和可用的replicas列表裡邊。

如上圖所示，4台注冊中心，每台注冊中心需要配置其他三台伺服器，以Eureka 1為例，其配置如下：

注冊中心是本應該是無狀態的，可以橫向擴展。但由於每台注冊中心的配置都不一樣，所以擴展起來比較麻煩，需要修改配置文件，這樣就無法做到快速的擴容。

微服務客戶端需要配置注冊中心的地址，使用的是如下的配置：

由於配置的是固定的IP地址，如果我們要擴容注冊中心，增加新的注冊中心節點，那我們就需要修改微服務客戶端的配置文件，將新的注冊中心節點進入的伺服器列表中。試想一下，如果有幾十個微服務，每個微服務有4個節點，那將會要修改上百個配置文件。很顯然這種方式不太可取，從軟體設計角度來說，違反了開閉原則。

其實Eureka 注冊中心還有另一種高可用配置方式，基於DNS。Eureka天生就可以部署在像AWS這樣的公有雲上，並且可以跨Region，跨Available Zone部署。雖然我們不用部署在雲端，依然可以利用這一特性，我們可以把Region看作我們數據中心的機房，Avaiable Zone 看作是機房中的網路區域，結合內部DNS服務來實現高可用的注冊中心。

畫重點：
a. region: default，配置地區
b. useDnsForFetchingServiceUrls，表示基於DNS獲取服務信息
c. eurekaServerDNSName: eureka.txzq.com.cn，配置域名伺服器名稱

鍵：txt.default.eureka.txzq.com.cn 值：shenzhen.eureka.txzq.com.cn
鍵：txt.shenzhen.eureka.txzq.com.cn 值：172.18.10.1 172.18.10.2 172.18.10.3 172.18.10.4

第一條記錄表示，default 區域，包含了哪些可用區，我們用shenzhen表示是深圳機房，txt記錄的值就設置為：shenzhen.eureka.txzq.com.cn
第二第記錄表示 , shenzhen機房有哪些伺服器，多台伺服器使用空格格開。
如果在本地測試，需要搭建一台自己的DNS伺服器，可以參考我的另一篇文章： 基於Docker快速搭建DNS Server

Client View是指DNS服務應用到哪一個網段，比如：172.18.10.0/24網段的IP連接到BIND伺服器，才會解析指定的域名。

在添加域名的時候，需要指定Client View，這里我們選擇我們剛剛創建的View_172.18.10.0，指的是只有在這個網段的IP訪問這台DNS伺服器，才能解析。

添加完一級域名後我們刷一下這個ZONE，然後設置一下本地DNS伺服器

DNS域名伺服器驗證通過後，我們接下來就可以在為這個域名添加我們所需要的txt 記錄了。

到這里我們的准備工作就已經基本完成了。使用Maven將注冊中心編譯成，輸出jar包。新建一個Eureka的docker鏡像，並啟動4個容器。基於DNS的注冊中心就搭建完畢了。

你只需要對DNS記錄進行變更，就可以實現動態的、快速擴容/縮容了。

關於如何將Eureka部署到Docker，請參考另一篇文章：

⑹ 如何快速構建高可用集群

我們在信息中心的伺服器中實施了虛擬化技術，任何一台物理伺服器的斷電都會導致多個虛擬機停止工作。一個高可用的(HA)集群系統可以幫助我們預防這種情況出現，當主機故障發生後，虛擬機可以在集群系統中迅速重建。舉例來說，假設虛擬化集群中的一個物理節點失效，虛擬機可以迅速遷移到其他節點繼續運行。在這種集群模式下，即使在伺服器宕機的情況下，核心業務系統仍然可以持續地提供服務。
在Xen虛擬機可以被集群系統管理並實現在節點間自由遷移之前，所有節點必須具備訪問虛擬機的配置文件及後端存儲的能力。在本文中，TechTarget中國的特約虛擬化專家Sander van Vugt將講述如何對它們實現共享訪問。
實現對虛擬機配置文件的訪問
實現虛擬機配置文件在所有節點的共享訪問是非常簡單的。首先，把文件存放在SAN系統中的邏輯單元號LUN（logic unitnumber）上；接下來，把LUN中/etc/xen/vm目錄映射給節點中所有相關主機；最後，把配置文件設置為網路共享狀態，使其所在目錄可以被主機動態載入。或者您也可以在配置發生變化後，手動同步文件（而且這種變化並不會經常發生）。然而，為了虛擬機後端存儲的共享訪問，設置方式是完全不同的。
配置後端存儲設備
這里提供兩種不同的配置虛擬機後端存儲的方法。第一種是，虛擬機默認狀態下是把後端存儲作為一個文件來處理的。在這種情形下，設置該文件可以被集群中的每個主機訪問就可以共享了。同時，我們建議把該文件放置在安全的集群文件系統中，例如Oracle的Oracle Cluster FileSystem 2。
第二種更加簡單的方式是，設置專門的設備作為後端存儲。當創建虛擬機時，在安裝過程中把邏輯卷配置為虛擬機的後端存儲。這樣，只需確保邏輯卷是位於SAN中的LUN上，並且可以被集群中的所有主機訪問到就可以了。
配置Xen主機
在准備好多個Xen主機後，就可以開始創建集群系統了。首先，從主伺服器上啟動hb_gui終端，並認證為hacluster用戶。接下來，選擇Configuration進行配置，再選擇Resources。在這頁中，單擊Add，對Primitive相關選項進行配置。最後，為resource命名輸入其ID（在測試過程中，命名為\"Xen-node\"是個不錯的選擇）。下一步依次選擇Class OCF, ProviderHeartbeat和Type Xen進行相應配置。全部完成後，點擊Forward。
在下一個窗口中，我們可以進一步配置新Xen虛擬機的相應參數。選擇Instance Attributes頁，在xmfile參數中指定正確的Xen虛擬機配置文件。然後，提供虛擬機配置文件的完整路徑並點擊Apply。現在我們已經在集群中創建了源虛擬機。
到現在，在hb_gui終端的管理窗口中，我們已經可以看到源虛擬機了，但是它還處於非激活狀態。右鍵點擊虛擬機，選擇Start。
恭喜，現在我們已經完成第一台集群系統中虛擬機的創建。

⑺ 架構高可用高並發系統的設計原則

通過學習《億級流量網站架構核心技術》及《linux就該這么學》學習筆記及自己的感悟：架構設計之高可用高並發系統設計原則，架構設計包括墨菲定律、康威定律和二八定律三大定律，而系統設計包括高並發原則、高可用和業務設計原則等。
架構設計三大定律
墨菲定律 – 任何事沒有表面看起來那麼簡單 – 所有的事都會比預計的時間長 – 可能出錯的事情總會出錯 – 擔心某種事情發生，那麼它就更有可能發生
康威定律 – 系統架構師公司組織架構的反映 – 按照業務閉環進行系統拆分/組織架構劃分，實現閉環、高內聚、低耦合，減少溝通成本 – 如果溝通出現問題，應該考慮進行系統和組織架構的調整 – 適合時機進行系統拆分，不要一開始就吧系統、服務拆分拆的非常細，雖然閉環，但是每個人維護的系統多，維護成本高 – 微服務架構的理論基礎 – 康威定律https://yq.aliyun.com/articles/8611– 每個架構師都應該研究下康威定律http://36kr.com/p/5042735.html
二八定律 – 80%的結果取決於20%的原因
系統設計遵循的原則
1.高並發原則
無狀態
無狀態應用，便於水平擴展
有狀態配置可通過配置中心實現無狀態
實踐: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等
拆分
系統維度：按照系統功能、業務拆分，如購物車，結算，訂單等
功能維度：對系統功能在做細粒度拆分
讀寫維度：根據讀寫比例特徵拆分；讀多，可考慮多級緩存；寫多，可考慮分庫分表
AOP維度： 根據訪問特徵，按照AOP進行拆分，比如商品詳情頁可分為CDN、頁面渲染系統，CDN就是一個AOP系統
模塊維度：對整體代碼結構劃分Web、Service、DAO
服務化
服務化演進: 進程內服務-單機遠程服務-集群手動注冊服務-自動注冊和發現服務-服務的分組、隔離、路由-服務治理
考慮服務分組、隔離、限流、黑白名單、超時、重試機制、路由、故障補償等
實踐：利用Nginx、HaProxy、LVS等實現負載均衡，ZooKeeper、Consul等實現自動注冊和發現服
消息隊列
目的: 服務解耦(一對多消費)、非同步處理、流量削峰緩沖等
大流量緩沖： 犧牲強一致性，保證最終一致性(案例：庫存扣減，現在Redis中做扣減，記錄扣減日誌，通過後台進程將扣減日誌應用到DB)
數據校對: 解決非同步消息機制下消息丟失問題
數據異構
數據異構: 通過消息隊列機制接收數據變更，原子化存儲
數據閉環: 屏蔽多從數據來源，將數據異構存儲，形成閉環
緩存銀彈
用戶層:
DNS緩存
瀏覽器DNS緩存
操作系統DNS緩存
本地DNS服務商緩存
DNS伺服器緩存
客戶端緩存
瀏覽器緩存(Expires、Cache-Control、Last-Modified、Etag)
App客戶緩存(js/css/image…)
代理層：
CDN緩存(一般基於ATS、Varnish、Nginx、Squid等構建,邊緣節點-二級節點-中心節點-源站)
接入層：
Opcache： 緩存PHP的Opcodes
Proxy_cache： 代理緩存,可以存儲到/dev/shm或者SSD
FastCGI Cache
Nginx+Lua+Redis: 業務數據緩存
Nginx為例：
PHP為例：
應用層：
頁面靜態化
業務數據緩存(Redis/Memcached/本地文件等)
消息隊列
數據層：
NoSQL： Redis、Memcache、SSDB等
MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等
系統層：
CPU : L1/L2/L3 Cache/NUMA
內存
磁碟：磁碟本身緩存、dirtyratio/dirtybackground_ratio、陣列卡本身緩存
並發化
2.高可用原則
降級
降級開關集中化管理：將開關配置信息推送到各個應用
可降級的多級讀服務：如服務調用降級為只讀本地緩存
開關前置化：如Nginx+lua(OpenResty)配置降級策略，引流流量；可基於此做灰度策略
業務降級：高並發下，保證核心功能，次要功能可由同步改為非同步策略或屏蔽功能
限流
目的: 防止惡意請求攻擊或超出系統峰值
實踐：
惡意請求流量只訪問到Cache
穿透後端應用的流量使用Nginx的limit處理
惡意IP使用Nginx Deny策略或者iptables拒絕
切流量
目的：屏蔽故障機器
實踐:
DNS: 更改域名解析入口，如DNSPOD可以添加備用IP，正常IP故障時，會自主切換到備用地址;生效實踐較慢
HttpDNS: 為了繞過運營商LocalDNS實現的精準流量調度
LVS/HaProxy/Nginx: 摘除故障節點
可回滾
發布版本失敗時可隨時快速回退到上一個穩定版本
3.業務設計原則
防重設計
冪等設計
流程定義
狀態與狀態機
後台系統操作可反饋
後台系統審批化
文檔注釋
備份
4.總結
先行規劃和設計時有必要的，要對現有問題有方案，對未來有預案;欠下的技術債，遲早都是要還的。
本文作者為網易高級運維工程師

⑻ maxwell如何實現高可用

一旦我們在信息中心的伺服器中實施了虛擬化技術，任何一台物理伺服器的斷電都會導致多個虛擬機停止工作。一個高可用的(HA)集群系統可以幫助我們預防這種情況出現，當主機故障發生後，虛擬機可以在集群系統中迅速重建。舉例來說，假設虛擬化集群中的一個物理節點失效，虛擬機可以迅速遷移到其他節點繼續運行。在這種集群模式下，即使在伺服器宕機的情況下，核心業務系統仍然可以持續地提供服務。
在Xen虛擬機可以被集群系統管理並實現在節點間自由遷移之前，所有節點必須具備訪問虛擬機的配置文件及後端存儲的能力。在本文中，TechTarget中國的特約虛擬化專家Sander van Vugt將講述如何對它們實現共享訪問。
實現對虛擬機配置文件的訪問
實現虛擬機配置文件在所有節點的共享訪問是非常簡單的。首先，把文件存放在SAN系統中的邏輯單元號LUN（logic unitnumber）上；接下來，把LUN中/etc/xen/vm目錄映射給節點中所有相關主機；最後，把配置文件設置為網路共享狀態，使其所在目錄可以被主機動態載入。或者您也可以在配置發生變化後，手動同步文件（而且這種變化並不會經常發生）。然而，為了虛擬機後端存儲的共享訪問，設置方式是完全不同的。

⑼ 如何為高可用集群Hyper-V系統選擇合適的硬體配置

和其他的虛擬機技術環境中不同的是，Hyper-V不能支持內存過分配技術（memory
overcommit
）。因此，當創建的虛擬機所佔用的內存總數大於主機實際的物理內存時，您將無法啟動虛擬機。如果您在分配完可用物理內存之後，嘗試去啟動另外的虛擬機，即
使只是再多分配一台，結果只有一種可能就是返回錯誤提示信息。
如果在一台伺服器環境中，這不會是一個大問題，因為所有的虛擬機啟動過程都是由管理員人工管理的。在帶有自動故障切換技術的集群環境中，這點就會變成一個
很大的障礙。因此，搭建一個擁有足夠的可用物理內存的Hyper-V集群環境就變得非常重要，只有滿足這個條件後主機才可以成功的從發生故障的源節點切換
到集群中的可用目標節點。這也就是說，如果在一個擁有兩個節點的集群中，一半的物理內存必須預留出來；假如擁有四個節點，就意味著需要預留四分之一的物理
內存，以此類推。
簡單錯誤三：缺少支持CSV（Cluster
Shared
Volume，即集群共享卷）技術的備份方式
在Windows
Server
2008
R2中，微軟發布了一項稱為Cluster
Shared
Volume的新技術。它基於現有NTFS格式文件系統基礎上，為Hyper-V虛擬機提供特殊功能支持的技術。您可以把這項技術認為是R2版本的一個屬
性，使得分布在集群中的多個虛擬機可以同時訪問一個共享的LUN。這項新技術解決了集群中的節點失效時，磁碟子系統也作為其一部分而無法工作的情況。允許
必要情況下，虛擬機可以在一個LUN內無縫地遷移。
CSV技術面臨一項潛在的挑戰，那就是：很少有基於虛擬主機的備份產品可以支持。今天，甚至於
微軟的Windows
Server
Backup也無法實現支持。即使這樣，還是有一些像Data
Protection
Manager
2010（仍然只有測試版本）這樣的產品，可以實現對這種工作方式的支持。
簡單錯誤四：對虛擬CPU的過度分配
今天，用戶購買帶有兩個及更多物理CPU的伺服器已經很普遍。擁有更多的CPU意味著多線程應用程序可以在多個CPU之間實現負載均衡。或者當其中一個
CPU被某個單線程應用所佔用時，還可以使用剩餘的CPU來滿足其他應用的需求。這就是為什麼現在幾乎所有的伺服器都有至少兩個甚至有時是四個或更多
CPU的原因。現在的數據中心工作負載需要配備額外的處理器資源以滿足性能以及可用性方面的需求。
在Hyper-V的虛擬化環境中，對虛擬處理器的分配方式是比較特別的。Hyper-V的虛擬機環境中的最佳做法是：在初期只為一台物理機分配一個單獨的虛擬處理器，只有在需要的情況下才去分配額外的處理器資源。
雖然表面看起來增加虛擬處理器數量是一個很好的方式，但實際上這種操作反而會由於調度管理上引起的沖突而降低性能。當多個虛擬處理器被分配給虛擬機後，
這些處理器必須通過調度管理的方式，把它們的使用情況跟實際的物理資源對應起來。假設兩個虛擬處理器分配給一台虛擬機，hypervisor的調度程序
（scheler）必須等待對應的兩個物理處理器都可用後再去分配虛擬處理器。當在多個虛擬機競爭處理資源時，每個請求的響應時間會變得比普通情況長
得多。當物理處理器的個數少於所有虛擬機中分配的虛擬處理器之和時，情況甚至還會變得更糟。（關於這種情況為什麼會產生，您可以參考文章
Microsoft
Developers
Network
site中的Measuring
Processor
Performanc部分。）
還有，請時刻謹記，管理程序（hypervisor）分配的虛擬處理器需要橫跨伺服器上所有可用的物理處理器。這樣，虛擬處理器才可以充分利用所有可用的物理處理器資源。

⑽ 如何在Kubernetes中部署一個高可用的PostgreSQL集群環境

雖然 kubernetes 社區一直在努力使得有狀態應用成為一等公民，也推出了 statefulset 控制器支持 pod 的順序部署，穩定的域名訪問和存儲訪問。但鑒於 MySQL 部署運維的多樣性和復雜性，在 kubernetes 上部署 MySQL 仍然要面臨眾多挑戰。
1、業務流量入口的配置方式
傳統虛擬機環境下，我們通過虛IP的方式，讓業務應用都配置事先定義的一個虛IP為鏈接資料庫的地址，然後由高可用服務保證虛IP始終能被路由到master資料庫。在kubernetes中，出現了一層網路插件屏蔽了底層網路拓撲，高可用服務管理虛IP的方式需要隨之適應調整，比如通過service結合標簽完成虛IP的漂移，但service本身是kubernetes提供的一項功能，其可靠性和性能都取決於kubernetes服務的穩定。以性能來說，service是kubeproxy組件通過配置iptables實現的，當iptables規則較多時不可避免的會產生時延，需要我們針對性的解決。
2、容器隔離帶來的監控視野問題
在 kubernetes 中，如果將 MySQL 製作為 container 運行在一個 pod 中，container 會將 MySQL 進程和運行環境隔離在一個單獨的 namespace 中。監控組件在獲取 MySQL 的一些 metirc 時，可能不得不進入與 MySQL 同一個 namespace 中，在部署和設計監控組件時需要考慮到這些限制。
3、存儲在 kubernetes 中，支持配置各種不同的存儲。
如果使用本地存儲 local persistent volume，則需要綁定 MySQL 在一個固定的節點，這就完全浪費了 kubernetes 靈活調度的天然優勢；而如果使用遠程共享存儲，確實是將 MySQL 進程與其存儲完全解耦，使得 MySQL 進程可以在任意節點調度，然而考慮到高 I/O 吞吐量的情況，就不是那麼美好了。設計時需要考量遠程存儲是否能夠滿足 MySQL 的帶寬要求。
4、高可用/備份恢復
kubernetes 提供的 statefulset 控制器只能提供最基本的部署，刪除功能，無法實現完善的 MySQL 集群高可用/備份恢復操作。對於有狀態應用的部署，仍需要定製開發，所以多數公司提供了定製的 operator 來完成應用容器的管理。比如 etcd operator，MySQL operator，後文將為大家詳述我測試使用 MySQL operator 的一些記錄。