規劃驅動架構和故障驅動架構

前言

在我看來架構驅動一般分爲兩種，規劃驅動的和故障驅動。

前者更能體現出架構師在業務角度和技術角度的前瞻性能力，後者可能是出如今業務高速發展階段，大部分時間只能疲於應付吧。

好比在雙十一咱們常常聽到由於流量過大形成服務癱瘓，系統不可用。

雖然咱們經過創建可靠的上線，測試，部署流程。指望在測試及灰度階段發現性能和可用性的潛在問題，但大部分仍是難以免線上的故障。

架構想要什麼

架構的關鍵詞：高可用，高併發，大數據，分佈式，自動化。

故障驅動的架構師老是但願經過系統升級迭代，搞定那些線上暴露出的問題，修復他，對於那些還未發生，認爲是不存在的。

固然大部分架構的發展是來自於業務需求，那咱們是否還須要主動驅動架構？

架構很差預估，通常在大流量下咱們才能更好的觀察咱們的系統能力。

「系統自動擴縮容」，「在流量不一樣時進行自動調整」聽上去很贊，可是每每在黑天鵝來了以後仍是啞火了，好比微博接入混合雲後，號稱自動擴縮容同時支持八對明星併發出軌，而後在鹿晗找了女友後就掛了。

規劃系統

因此咱們要明確的目標和將實施方案寫進規劃，討論，落地，執行，折騰。

每次在分佈式中間件，持續集成持續交付，DevOPS等折騰後，和行業內夥伴學習交流，關注發展歷程和技術選型，將這些計入標準細節。每次都會有收穫有啓發。

創建破壞性故障演練，制定模擬場景，好比拔網線，丟包，IO不規則波動，消息堵塞等，去不斷演練，堅固系統。