有了《系統架構的11條原則》，真正到設計階段還有另外11個考慮。 系統正確性 考慮一：負負得正 假如我們看到某個代碼，明顯有邏輯錯誤，想隨手改改。你就要考慮一件事情：這段明顯有問題的代碼為什麼線上上運行著沒有人來報bug？有一種正常運行叫做【負負得正】。如果把錯誤的邏輯改對了反而可能引起問題。 這種 ...
有了《系統架構的11條原則》，真正到設計階段還有另外11個考慮。
系統正確性
考慮一：負負得正
假如我們看到某個代碼，明顯有邏輯錯誤，想隨手改改。你就要考慮一件事情：這段明顯有問題的代碼為什麼線上上運行著沒有人來報bug？有一種正常運行叫做【負負得正】。如果把錯誤的邏輯改對了反而可能引起問題。
這種問題要避免最好的時機是初版設計和開發階段就避免。除了設計階段邏輯要清晰，代碼要做好審查、加上單體測試等測試手段外，可以將中間結果用debug日誌列印。建議自測階段多用debug級別日誌跑幾遍，進行觀察。
考慮二：終態設計
在分散式系統中，由於系統是分佈在不同機器上的。還可能有一種狀態叫：超時。成功、失敗和超時是分散式系統調用的三態。
超時不是終態，而是一種中間狀態：最終有可能下游是成功了，也有可能是失敗了。這時候我們需要在超時之後推定一種狀態，推定成功或者失敗。究竟是成功還是失敗因功能而異。
比如付款操作，需要推定失敗。如果不知道是否成功就推定是成功的，那用戶可能沒有付款就拿到了商品或者享受了服務，商家就會資金損失。推定失敗讓用戶再次支付，最終通過查詢或者對賬發現用戶實際是支付成功的，可以再把錢給用戶退回去，保證交易的公平性。
退款恰恰相反，需要推定成功。告訴用戶，錢退給你了。最終通過查詢或者對賬發現實際是退款失敗了，可以系統重新發起退款，直到真正退成功為止。
後臺管理系統也很需要這種終態設計。比如發佈系統，發佈了一個功能，發佈系統如果出現了問題，這次發佈沒有結束。用戶可能沒有辦法進行下一次發佈。這時候可以設置超時自動結束，防止未結束的流程始終在那裡。
考慮三：長尾效應
如上圖，隨便找了一個調用的耗時。從上面可以看到平均耗時13.9ms，百分之99的耗時在30ms內，最大耗時有488ms。那對於超過100ms的請求來說，是不是在30ms內還不返回就直接丟棄這個請求重新發起一個，新請求有99%的概率在30ms內返回結果，從時間上更划算？
而之所以對同一個請求性能差距很大，原因很多，常見的有服務過載和隊列過長。如果長尾處理不好，有可能上游判定超時，導致請求失敗，影響正確性。需要系統處理好超時和重試。
系統容量
考慮四：存儲周期
資料庫、應用系統的磁碟都是寶貴的資源。數據不能無限期存儲不做清理。清理的周期是一個重要的考慮方面。因為這涉及對用戶的承諾。
對資料庫來說，比如交易庫數據半年清理一次。那就要跟用戶說清楚半年以上的交易不允許退款。因為原交易已經不在資料庫，而是歸檔到大數據了。
對磁碟來說，如果應用日誌是30天清理一次。那就要跟用戶達成一致，非重大問題30天以上的不予追溯。為什麼這裡說重大問題呢，其實很多公司磁碟清理了，數據在hbase等大數據設備里還是有留存的。只是查詢沒有磁碟日誌便利。
考慮五：AKF擴展
AKF擴展立方體（Scalability Cube），是《架構即未來》一書中提出的可擴展模型，這個立方體有三個軸線，每個軸線描述擴展性的一個維度：
X軸 —— 代表無差別的克隆服務和數據，工作可以很均勻的分散在不同的服務實例上；
Y軸 —— 關註應用中職責的劃分，比如數據類型，交易執行類型的劃分；
Z軸 —— 關註服務和數據的優先順序劃分，如分地域劃分。
白話來說：X軸拆分就是通過加機器水平拆分，就是橫向擴展；Y軸拆分就是按業務邏輯垂直拆分；Z軸拆分就是按照演算法進行分片，這個演算法比如按地域，不同地域訪問不同的分片或者服務。
舉個例子，比如一般公司的redis集群會有一個團隊來進行統一維護。redis集群有主有從，數據都是一樣的，多副本容災，這是X軸水平的拆分。一個公司很多業務，redis團隊會對不同的業務提供不同的集群，這是Y軸垂直拆分；集群內部數據會通過sharding做分片，這是Z軸演算法拆分。
系統運維
考慮六：服務自治
當一個服務的邏輯單元由自身的領域邊界內所控制，不受其他外界條件的影響（外界條件帶有不可預測性），且運行環境是自身可控，完全自給自足，我們認為這個服務是自治的。
在系統設計時，要考慮服務上線後，對於問題要自感知、自修複、自優化、自運維及自安全。
考慮七：應急預案
SOP（Standard Operating Procedure三個單詞中首字母的大寫 ）即標準作業程式，就是將某一事件的標準操作步驟和要求以統一的格式描述出來，用來指導和規範日常的工作。
EOP（Emergency Operating Procedure三個單詞中首字母的大寫 ）即應急操作流程，用於規範應急操作過程中的流程及操作步驟。確保人員可以迅速啟動，確保有序、有效地組織實施各項應對措施。
這兩種操作流程需要平時就整理好，避免緊急情況下思慮不周導致操作時的二次故障。
考慮八：故障隔離
隔離是行之有效的故障規避措施。有以下隔離手段。
-
領域拆分隔離方面
-
提煉核心、支撐和通用域
-
-
服務部署隔離方面
-
環境拆分
-
機房隔離
-
通道隔離
-
單元化
-
泳道
-
熱點隔離
-
讀寫隔離
-
容器隔離
-
拆庫拆表
-
動靜隔離
-
非核心流量隔離
-
服務間交互隔離方面
考慮九：風險巡檢
核心系統穩定之後，更多的從邊緣進行優化，避免影響核心系統的穩定。風險巡檢是優化的重要方面。常見的有以下內容。
-
請求系統錯誤統計
-
請求業務錯誤統計
-
請求內部錯誤統計
-
慢查詢統計巡檢
-
數據一致性巡檢
-
流程執行情況巡檢
審計和安全
考慮十：合法合規
合法合規是企業生死存亡的大事。近年來，由於政策影響，很多教育機構面臨了巨大的危機甚至倒閉。
對於金融類企業，太多合規操作。比如：行業要求金融交易類系統不能與其他系統混合部署；平臺沒有清結算資質可能面臨二清問題。提到資質，不得不說說金融牌照。在我國，需要審批的金融牌照主要包括銀行、信托、保險、券商、期貨、基金、基金子公司、基金銷售、金融租賃、小額貸款、第三方支付牌照、典當12種。業務的牌照要對口。
考慮十一：嚴格準入
做需求有個常識，對於用戶輸入的每個欄位都需要和產品經理討論一下：什麼類型、長度多少、允許的字元集範圍、格式是否合法。這麼做一方面是設計問題，包括產品設計、資料庫設計，還有一部分是安全問題：一個數值型的欄位肯定比一個粗放的文本型欄位被攻擊的可能性小，起碼不會傳到後端之後被當成腳本被執行。
操作合理性準入也是考慮的重要方面。比如一個普通用戶不能編輯另一個用戶的個人信息。比如i申請公司伺服器，一次申請1萬台機器。比如流量準入，一臺機器以超快的速度頻繁訪問一個網站的資訊信息，就可能不是真實用戶操作而是爬蟲。以上都會對系統安全性產生極大的影響。
總結
一張圖總結今天的內容：
