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