這是我參與8月更文挑戰的第4天,活動詳情查看:8月更文挑戰html
事情是這樣的,最近學委竟然被水痘病毒拿下了。。。前端
哎,以前生活做息沒把握好節奏,寫文章後太興奮了有時候睡不着,休息不足免疫力就降低,只能說寫文章是一把雙刃劍。(也奉勸各位讀者朋友們注意休息,身體健康最重要!)java
好,暫時放下這把劍,去看醫生。被告知這是常見病毒,只是偶爾有些人免疫力降低沒抵抗住,就會被感染。編程
不是說系統架構嗎???先看下圖,請帶着這個問題繼續看吧。
(學委就是裏面那個冒紅的塊,其餘都是正常健康的同事們)
後端
水痘是一種急性高度傳染性疾病,症狀就是會發癢發紅,一般得過一次就通常不會再感染。(學委不是水痘專家,這裏只是簡單摘述)markdown
我小時候確定是打過疫苗的,可是沒想到N年後竟然被再次攻擊了!架構
得了水痘以後周圍發生了什麼?下面是整個事件。運維
公司其實就像一個系統,部門就像一個服務羣,而學委就是裏面的一個微服務。固然這個平臺也有幾個相似學委這樣的微服務(就像下圖同樣,藍色框內爲一個公司,裏面不少打工人,箭頭爲服務間交互)。
上圖,除了學委這個服務變紅了,其餘服務仍是綠色的,正常運轉的狀態。(請再看一眼這個圖,後文會繼續講學委跟幾個同事交互以後的變化)分佈式
遇到問題,讓系統儘可能不崩潰,保持正常或者近乎正常的運行,是每一個架構師必須作好的事情。微服務
所謂系統思惟(System Thinking),就是把某個疑問、某種情況或某個難題明確地視爲一個系統,也便是視爲一組相互關聯的實體,而不是孤立的一個對象。
在公司,每一個職能部門,處理應對業務,應對一個一個問題。這就像及了應對一個問題的總體架構!
系統思惟的初級目標是理解系統是什麼,更進一層的目標是爲了預測系統在發生某些變化以後的狀況。而最高級的目標,則是用部件來合成一個系統,這個過程就是系統架構。
每一個員工個體就是部門裏面的一個個服務,固然職能還有前端,後端,業務分析人員,架構師,和其餘管理等等,這些至關於不一樣類型的實例。
這些公共協做對外爲處理系列問題的一個系統!
相似的,咱們能夠看到在公司作了上面的一些措施,遏制病毒的進一步擴散,避免感染影響更多的微服務。
同時把問題上報,公佈問題,帶來更高級別的關注和避免了更多可能的服務交互。
這些行爲就像微服務裏面進行業務隔離(下圖的虛線和實線包起來進行不一樣級別的隔離),警告展現在大面板(羣發公告這個事件),實現中央化統籌一個樣啊。
就像雷學委微服務同樣,一開始覺得長痱子,沒多想跟其餘服務交互(好比更哥們吃吃飯,回去公司跟小夥伴交流技術)。
可是,服務內部有設置狀態監控,學委生病一開始覺得是腰上長了一點點痱子,沒理會,第四天發現尚未好。
看病前4天已經約了朋友吃飯,也不知道是啥,因此就去吃飯了。但也沒有猶豫下午就請假去看醫生了。
而後跟確認病情後,通知部門,而後公司安排系列後續處理。
我則在家上班,也避免影響其餘人。
這是一種服務的組件自治的體現,自我管理,自我故障處理,不行再向上彙報。
那麼就像下圖同樣,紅色爲被傳播水痘病毒的同事,在系統中體現爲多個服務沒法正常運轉致使整個系統在外部看來是崩潰的。
也就是咱們常說的掛機了,相似以前B站崩了。
有些讀者跟着文章讀,很容易被帶入了,覺不是很天然嗎?
那麼,你能夠想一想下面的問題?
要是沒有去看醫生呢;
要是看醫生後忘記及時告訴公司了呢;
要是告訴同事,他們沒有理會約束呢;
要是告訴部門沒有任何舉動等等。
雖然水痘也不是那麼嚇人,但遇到抵抗力低的照樣傳播開來,那就影響更多部門,甚至更多系統(公司與公司之間業務交互的影響)。因此,若沒有上述處理,這個事情可能影響更大。
相似問題可再想一想,從新審視一下你所接觸過的系統或者項目。
好比某一次提交代碼,小八(他是新加入項目的)就寫了一個for循環,本地測試好好的。
放到線上後運行了一段時間後致使一個查單服務Java進程發生OOM。
結果調用服務不斷重試,天然地把其餘查單服務壓垮了,最後全部調用方不斷重試,還把網關壓垮,全員緊急加班查問題。
答案是沒有。生活仍是有其餘萬一的,咱們沒法都考慮進來。不少技術人員會聽到6個9,也就是一年掛機不超過31秒,很難達到吧。
(1-99.9999%)*365*24*60*60=31.5秒(向下取整數)
複製代碼
只能說架構應該具備相對的適用性,超前性(N倍性能的彈性設計,但不多是百倍性能的規劃),演化性(平臺不是第一天就成爲平臺)。這不就跟公司成長同樣嘛。
相似水痘這個bug是沒法避免的,由於消除不了,但不屬於那種致命問題,有時候也不會被重視。
作系統也同樣不能說徹底沒有Bug,只是多數狀況下還不是主要矛盾,能夠忍受(再沒有遇到那個狀況觸發下)。
自我感知,告警,熔斷,健壯性等等。這對應於員工則是招聘培訓高素質員工
流量銷峯,加緩衝隊列,業務隔離,服務隔離,多個服務實例,還有支持伸縮。這對應於公司則是針對故障的一系列高效處理流程:好比合理業務線劃分,分佈式團隊帶來錯峯彈性,和支持移動辦公等等。
這裏簡單談了一些,固然更加彈性更加可用,那麼系統的成本就越高了。對應的就是企業增長了管理成本,高素質員工帶來的支付更高的薪酬。
對新手來講,看書估計是很難的,你沒有到那些問題,看到一些文字估計停留在淺嘗輒止!
學委以爲最好的方式就是,觀察,模仿,找到團隊裏最厲害的人(能夠是架構師,能夠是最牛的那個技術)。
多跟他交流,思考爲何,他也不必定都對(除了技術,還有工期,團隊能力,預算等外界因素)。這個思考的過程,再去看資料,纔是更加實戰的學習架構經驗之道!
好了,旨在引起思考。此次水痘經歷,讓咱們看到這個一連串的事情和一系列處理。靈機一動,學委用來類比了系統和微服務的監控,運維,架構設計,也沒有全面涵蓋!
另外更加感興趣的朋友,可自行去看《系統架構:複雜系統的產品設計與開發》,超級經典的一本,更多仍是實戰。
對了,學委還有這個能夠關注長期閱讀 =>雷學委趣味編程故事彙編
或者=> 雷學委NodeJS系列
持續學習持續開發,我是雷學委! 編程頗有趣,關鍵是把技術搞透徹講明白。 創做不易,請多多支持,點贊收藏支持學委吧!