一元东北麻将怎么算钱

在系統中放一只隨機殺死服務的“猴子”,落地的六個步驟


來源:InfoQ   時間:2019-12-03 09:00:11


作者丨焦振清、杜賓

策劃丨田曉旭

編輯丨小智

1 Chaos Monkey:系統中的猴子

只要你有過在生產環境中實際運行過分布式系統的經歷,你就應該清楚,各種不可預期的突發事件一定會發生。分布式系統天生包含大量的交互、依賴點,可以出錯的地方數不勝數。硬盤故障、網絡不通、流量激增壓垮某些組件,我們可以一直列舉下去。這都是每天要面臨的常事兒,處理不好就會導致業務停滯,性能低下,或者是其他各種無法預期的異常行為。

在復雜的分布式系統中,人力并不能夠阻止這些故障的發生,我們應該致力于在這些異常行為被觸發之前,盡可能多地識別出會導致這些異常的,在系統中脆弱的,易出故障的環節。當我們識別出這些風險,我們就可以有針對性地進行加固,防范,從而避免故障發生時所帶來的嚴重后果。我們能夠在不斷打造更具彈性(彈性:系統應對故障、從故障中恢復的能力)系統的同時,樹立運行高可用分布式系統的信心。

2008 年 Netflix 開始從數據中心遷移到云上,之后就開始嘗試在生產環境開展一些系統彈性的測試。過了一段時間這個實踐過程才被稱之為混沌工程。最早被大家熟知的是“混亂猴子”(Chaos Monkey),以其在生產環境中隨機關閉服務節點而“惡名遠揚”。不久以后,“混亂猴子”進化成為“混亂金剛”(Chaos Kong),能力進一步提升。

2 混沌工程:未來系統標配

Netflix 隨后確立了混沌工程的若干原則,用以將這個實踐規范的學科化 ,同時推出了混沌工程自動化平臺,能夠在微服務體系架構上,24*7 不間斷地自動運行混沌工程實驗。

在開發這些工具和實踐的過程中, Netflix 逐漸意識到,混沌工程并非是簡單的制造服務中斷等故障。當然,嘗試破壞系統和服務很簡單,但并不是全都可以有建設性、高效地發現問題。混沌工程的意義在于,能讓復雜系統中根深蒂固的混亂和不穩定性浮出表面,讓 Netflix 可以更全面地理解這些系統性固有現象,從而在分布式系統中實現更好的工程設計,不斷提高系統彈性。

除了適配于互聯網場景,混沌工程也同樣適用于傳統行業,如大型金融機構,制造業和醫療機構。交易依賴復雜系統嗎?有大型銀行正在使用混沌工程來驗證交易系統是否有足夠的冗余。是否有人命懸一線?在美國,混沌工程在許多方面被當做模型應用在了臨床試驗系統中,從而形成了美國醫療驗證的黃金標準。橫跨金融、醫療、保險、火箭制造、農業機械、工具制造、再到數字巨頭和創業公司,混沌工程正在成為復雜系統改進學科的立足點。

未來,混沌工程或將成為系統的標配。屆時,你可能在每個系統中都找到這只“猴子”。

3 混沌工程六個階段

從筆者所在團隊的實踐出發,我們將混沌工程總結為六個階段,并對各個階段的落地過程加以總結,希望能夠對大家落地混沌工程有所幫助。今天主要是拋磚引玉,后續針對每個階段,陸續會有專門的文章進行介紹。而混沌工程理論相關的部分,大家可以參考由 Netflix 出版的《混沌工程》迷你書。

上述各階段涉及的部門和人員的數量,遠遠超過了當初的預估,因此該部分成為我們確定順序的最主要因素,強烈建議大家實施混沌工程,一定要爭取來自于管理層的支持以及周邊團隊的理解和配合,否則很容易導致項目虎頭蛇尾。

4 單機破壞

重要性說明

以集群選主機制為例說明單機破壞的優先級和重要性,如果單機在某些場景異常后,集群無法選主,進而導致系統整體不可用。該問題如果在單機房破壞場景時才發現,那系統整體不可用了,你還能找出啥別的問題呢?一個機房的破壞場景,往往涉及多個部門的聯動,大部分業務團隊的各類角色均會參與其中,難道最后就得到一個結論:選主機制有問題。如果真是這樣,你還打算繼續干下去嗎?

排序考慮

單機破壞能夠在測試環境中發現絕大多數問題,并能掃清后續階段的阻塞點,因此排在首位可謂是當之無愧。

破壞手段

在測試環境下,先從重啟服務器開始,然后是關機,資源異常(如 CPU 打滿)等場景。注意單機破壞場景不要把自己”拒之門外”。舉個例子,把機器的 CPU 打滿,但是沒有設置打滿的時長,結果自己也無法登錄機器了,只能重啟。

https://github.com/Netflix/SimianArmy/tree/master/src/main/resources/scripts

落地建議

初期僅在測試環境中進行,僅進行重啟場景的驗證就足以發現很多問題;

給出單機破壞的全部場景和驗收方法,由各個團隊自行落地;

不戀戰,只要問題不阻塞單機房破壞環節,不影響黃金流程即可進入下階段。

5 單機房破壞

重要性說明

單機房故障是造成服務整體崩潰的主要原因之一,全球互聯網巨頭大多發生過單機房故障導致服務崩潰的情形。諸如外網出口異常,內網跨機房專線異常,機房核心交換機異常,各種網絡抖動和擁塞,IDC 供電設備異常等等,相信大家都不陌生,因此其重要性可見一斑。

排序考慮

高頻故障場景,故障后影響較為嚴重,業界有較多的最佳實踐可供參考,模擬單機房破壞的難度和風險均較低,因此緊隨單機破壞其后。

破壞手段

將跨機房的專線端口關閉即可,恢復則是將端口重新 up 即可,整個耗時可以控制在秒級。演練前,業務方需要提前將流量遷移到其他機房,觀察跨機房的殘余流量符合預期后再進行操作,否則就對殘余流量進行排查,從而避免發生較為嚴重的故障。

落地建議

如果近期公司內部發生類似的單機房故障,那是單機房破壞發起的最佳時機;

通過數據分析來揭示風險,如跨機房交互的模塊數量及比例,跨機房的流量帶寬的增長趨勢、使用率和成分分析,每次機房級網絡調整各個業務受影響程度的統計,各個業務方對較大網絡操作的接受度等;借助網絡調整的機會,來間接實現第一次單機房破壞;

如果僅僅破壞部分機房(如所有在線機房)是不足以發現所有的問題和隱患的,需要對所有機房逐一進行一次演練,才能發現一些潛藏的依賴和問題;

單機房破壞的時間點盡量參照網絡調整的時間點,大多數在凌晨 1 點左右進行。

6 依賴治理

重要性說明

依賴主要是第三方依賴和基礎設施,包括但不限于 Mysql、Redis、K8S、DNS、LB、ELK、Hadoop 等,上述任何服務的故障,對業務影響都極為嚴重。以近期發生的 AWS 的 DNS 故障為例,持續 15 小時,多個業務受損。

排序考慮

基礎設施可謂是牽一發動全身,故障頻率低,故障影響大,因此依賴治理放在了單機和單機房之后。

破壞手段

基礎服務和一般的業務場景無區別,主要也是通過單機破壞和單機房破壞等通用手段來進行快速的問題識別。

落地建議

對于依賴的破壞,為了減少對業務方的影響,初期可以通過業務方的測試 / 預發環境 + 依賴的正式環境組合來進行破壞,也可以在離線機房對基礎設施進行破壞;

基礎設施很大占比是開源軟件,進行 Trace 的改造成本較高,因此要了解第三方依賴內部的關鍵點,并針對性的進行破壞演練。以 Mysql 為例來說,一般 Mysql 前面都會有一層 Proxy,如果 Proxy 正常,而 Mysql 異常會發生什么問題呢?事實證明,很多坑都在這個地方,而要想發現這個坑,那必然需要對 Mysql 的業務有一定的理解,也就是所謂的白盒;

攘外必先安內,各類依賴大部分都是其他部門提供的服務,溝通成本和配合度上會有區別,因此需要先搞定自身的問題,然后再來進行第三方的依賴治理,不然很容易被人懟回去,畢竟很多依賴屬于基礎設施,牽一發動全身,人家配合的成本也是極大的;

對于循環依賴需要在架構層面明確原則,然后再進行整體的改造。

7 全鏈路故障注入

重要性說明

所謂的精準注入,只影響特定的客戶 ID、地域、設備類型、接口,還可以對注入的行為和比例等進行精準控制,從而大幅縮小故障范圍,將故障的風險收斂到最小。因為是精準注入,因此必須具備全鏈路的觀測能力,才能夠將上述的細微的注入影響進行描述,否則,你可能很難回答,延時增加了 3s,是哪些模塊的作用導致的。

傳統的破壞方式,粒度只能控制在單機級別,很多影響非預期且及不可控。以 TC 命令為例,如果是按照一定比例進行破壞,你無法精準控制哪些請求會受到影響,運氣足夠差的情況下,也許你不希望被影響的請求全軍覆沒,而你期望被影響的請求則無一命中。另外,傳統的破壞方式也沒有統一的標準,有些需要用 tc 命令,有些是 iptables 命令,有些是寫死 /etc/hosts 文件,沒有方便易用的方式,且本身存在較大的風險,很難進行大范圍推廣。下面是兩者的對比:

tc qdisc add dev eth0 root netem delay 1000ms500mstc qdisc add dev eth0 root netem loss7%25iptables -A INPUT -p udp -m udp --dport 53 -j DROPiptables -A INPUT -p tcp -s 10.0.0.0/8-m limit --limit 500/s --limit-burst 100 -j ACCEPTecho "127.0.0.1 s3.amazonaws.com" >> /etc/hosts

排序考慮

全鏈路追蹤能力是故障注入的基礎,需要所有的模塊全部進行適配改造,否則調用鏈就會在某個階段中斷,進而導致不可完全追蹤。同時對于一些開源軟件,也需要進行適配,其成本是前四個階段中最高的,耗時最長的,因此,故障注入往往會放在后期。

破壞手段

微服務化一般是基于 Istio 進行注入,或者在接入層進行注入均可。此處我們也在 Istio 的緊張改造中,后面可以給大家寫專門的文章進行分享。

落地建議

對系統進行分級,首先將黃金流程進行改造,確保最核心的功能具備了能力,然后慢慢外擴到所有功能

8 CI/CD 整合

上述的四個手段,只能解決線上的存量問題,但無法阻止增量問題。因此,還需要將上述的各種能力,整合在 CI/CD 過程當中,在測試階段進行攔截,從而徹底杜絕這類問題在線上發生的可能性。該部分目前我們也正在逐步建設和完善中,因此各種坑后續慢慢交流。

產品化

雖然通過 CI/CD 階段的整合,可以將問題攔截在測試階段,但這時候,每次都是測試階段發現問題后讓研發返工,對于研發就造成了極大的資源浪費。因此,需要將混沌工程形成的各種標準和規范,以產品化的形式交給研發同學使用,進而讓大家都滿意。

以單機起停腳本為例進行說明,每個模塊的研發不同,可能存在的問題也不一樣,這時候,發現問題后進行修改,不如提供一個統一的服務起停管理工具給研發使用,從而徹底解決該問題。開源軟件類似 Systemd,Supervisor 和 Monit 都可以很好的解決這類問題,且對程序沒有侵入性,不存在什么改造成本。

再高階一些,就可以參考 Netflix 開源的各種軟件:

https://github.com/Netflix/

InfoQ 讀者交流群上線啦!各位小伙伴可以掃描下方二維碼,添加 InfoQ 小助手,回復關鍵字“進群”申請入群。大家可以和 InfoQ 讀者一起暢所欲言,和編輯們零距離接觸,超值的技術禮包等你領取,還有超值活動等你參加,快來加入我們吧!

今日薦文

異構微服務數據無損通信:Apache ServiceComb syncer 完整示例實踐

大會推薦

國內外一線互聯網資深技術專家現身教學,京東物流首席數據分析官吳盛楠博士、Google 研究院主任工程師 & 技術主管經理程致遠博士等技術大咖的實踐經驗必須讓你知道!

ArchSummit 全球架構師峰會(北京站)報名倒計時 5 天,沒上車的要抓緊了哦!了解詳情請聯系票務經理灰灰:15600537884 (同微信)。

點個在看少個 bug

  版權及免責聲明:凡本網所屬版權作品,轉載時須獲得授權并注明來源“環球光伏網”,違者本網將保留追究其相關法律責任的權力。凡轉載文章,不代表本網觀點和立場。

延伸閱讀

最新文章

2019-2020年煤炭中長期合同簽訂履行有關工作要點 2019-2020年煤炭中長期合同簽訂履行有關工作要點

精彩推薦

產業新聞

差點定名法拉第?馬斯克:商標持有者不愿賣,長時間才說服對方 差點定名法拉第?馬斯克:商標持有者不愿賣,長時間才說服對方

熱門推薦

一元东北麻将怎么算钱 广西快乐十分 安徽11选5 股票推荐_天牛宝 今日股市最新消息上证指数上证指数2020年预测 内蒙古11选5 东方6+1 11选5 河北十一选五 急速赛车 股票行情 牛市快讯每天推送 急速赛车 私募基金配资比例 基金配资地址 25选5 nba比分表火箭队 中小板块股票推荐