有了《系統架構的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三個單詞中首字母的大寫 ）即應急操作流程，用于規范應急操作程序中的流程及操作步驟，確保人員可以迅速啟動，確保有序、有效地組織實施各項應對措施，
這兩種操作流程需要平時就整理好，避免緊急情況下思慮不周導致操作時的二次故障，
考慮八：故障隔離
隔離是行之有效的故障規避措施，有以下隔離手段，
-
領域拆分隔離方面
-
ACL防止損壞層
-
有界背景關系
-
提煉核心、支撐和通用域
-
分層架構
-
CRUD增刪改查簡單架構
-
CQRS命令查詢隔離
-
依賴消弱控
-
服務部署隔離方面
-
環境拆分
-
機房隔離
-
通道隔離
-
單元化
-
泳道
-
熱點隔離
-
讀寫隔離
-
容器隔離
-
拆庫拆表
-
動靜隔離
-
非核心流量隔離
-
服務間互動隔離方面
-
超時熔斷
-
失敗率超限降級
-
服務內資源隔離方面
-
執行緒池隔離
-
信號量隔離
考慮九：風險巡檢
核心系統穩定之后，更多的從邊緣進行優化，避免影響核心系統的穩定，風險巡檢是優化的重要方面，常見的有以下內容，
-
請求系統錯誤統計
-
請求業務錯誤統計
-
請求內部錯誤統計
-
慢查詢統計巡檢
-
資料一致性巡檢
-
流程執行情況巡檢
審計和安全
考慮十：合法合規
合法合規是企業生死存亡的大事，近年來，由于政策影響，很多教育機構面臨了巨大的危機甚至倒閉，
對于金融類企業，太多合規操作，比如：行業要求金融交易類系統不能與其他系統混合部署；平臺沒有清結算資質可能面臨二清問題，提到資質，不得不說說金融牌照，在我國，需要審批的金融牌照主要包括銀行、信托、保險、券商、期貨、基金、基金子公司、基金銷售、金融租賃、小額貸款、第三方支付牌照、典當12種，業務的牌照要對口，
考慮十一：嚴格準入
做需求有個常識，對于用戶輸入的每個欄位都需要和產品經理討論一下：什么型別、長度多少、允許的字符集范圍、格式是否合法，這么做一方面是設計問題，包括產品設計、資料庫設計，還有一部分是安全問題：一個數值型的欄位肯定比一個粗放的文本型欄位被攻擊的可能性小，起碼不會傳到后端之后被當成腳本被執行，
操作合理性準入也是考慮的重要方面，比如一個普通用戶不能編輯另一個用戶的個人資訊，比如i申請公司服務器，一次申請1萬臺機器，比如流量準入，一臺機器以超快的速度頻繁訪問一個網站的資訊資訊，就可能不是真實用戶操作而是爬蟲，以上都會對系統安全性產生極大的影響，
總結
一張圖總結今天的內容：
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/464086.html
標籤：架構設計
下一篇：行為型：十. 訪問者模式