系統設計是一個不斷迭代的過程，在迭代中發現問題並修復問題，即滿足需求的系統是不斷迭代優化出來的，這是一個持續的過程，個人不相信完美架構銀彈。
一個好的設計要做到，解決現有需求和問題，把控實現和進度風險，預測和規劃未來，不要過度設計，從迭代中演進和完善。
在設計系統時，應該多思考墨菲定律。
- 1、任何事都沒有表面看起來那麼簡單。
- 2、所有的事都會比你預計的時間長。
- 3、可能出錯的事總會出錯。
- 4、如果你擔心某種情況發生，那麼它就更有可能發生。
在系統劃分時，也要思考康威定律。
- 1、系統架構是公司組織架構的反映。
- 2、應該按照業務閉環進行系統拆分/組織架構劃分，實現閉環/高內聚/低耦合，減少溝通成本。
- 3、如果溝通出現問題，那麼就應該考慮進行系統和組織架構的調整。
- 4、在合適時機進行系統拆分，不要一開始就把系統/服務拆得非常細，雖然閉環，但是每個人維護的系統多，維護成本高。
另外，也要多思考二八定律，在系統設計初期將有限的資源用到刀刃上，以最小化可行產品方式迭代推進。
一、高併發原則
1、無狀態
生產環境可能是這樣的：應用無狀態，配置文件有狀態。
2、拆分
拆分主要有如下幾種情況。
- 系統維度：按照系統功能/業務拆分
- 功能維度：對一個系統進行功能再拆分
- 讀寫維度：根據讀寫比例特徵進行拆分（有些聚合讀取的場景，如商品詳情頁，可考慮數據異構拆分系統，將分散在多處的數據聚合到一處存儲，以提升系統的性能和可靠性）
- 模塊維度：代碼結構一般按照三層架構（Web、Service、DAO）進行劃分
3、服務化
首先，判斷是不是隻需要簡單的單點遠程服務調用，隨著調用方越來越多，應該考慮使用服務自動註冊和發現，其次，還要考慮服務的分組/隔離，後期隨著調用量的增加還要考慮服務的限流、黑白名單等。還有一些細節需要注意，如超時時間、重試機制、服務路由（能動態切換不同的分組）、故障補償等，這些都會影響到服務的質量。
4、消息隊列
息隊列是用來解耦一些不需要同步調用的服務或者訂閱一些自己系統關心的變化。使用消息隊列可以實現服務解耦（一對多消費）、異步處理、流量削峰/緩衝等。使用消息隊列時，還要注意處理生產消息失敗，以及消息重複接收時的場景。
在使用了消息異步機制的場景下，可能存在消息的丟失，需要考慮進行數據校對和修正來保證數據的一致性和完整性。可以通過Worker定期去掃描原始表，通過對業務數據進行校對，有問題的要進行補償，掃描週期根據實際場景進行定義。
5、數據異構
把使用到的數據進行異構存儲，形成數據閉環：
- 數據異構：通過如MQ機制接收數據變更，然後原子化存儲到合適的存儲引擎
- 數據聚合：數據異構的目的是把數據從多個數據源拿過來，數據聚合的目的是把這些數據做個聚合
5、緩存銀彈
緩存對於讀服務來說可謂抗流量的銀彈。
7、併發化
二、高可用原則
1、降級
對於一個高可用服務，很重要的一個設計就是降級開關。
2、限流
限流的目的是防止惡意請求流量、惡意攻擊，或者防止流量超出系統峰值。原則是限制流量穿透到後端薄弱的應用層。
3、切流量
4、可回滾
版本化的目的是實現可審計可追溯，並且可回滾。
三、業務設計原則
1、防重設計
2、冪等設計
3、流程可定義
4、狀態與狀態機
5、後臺系統操作可反饋
6、後臺系統審批化
7、文檔和註釋
8、備份
閱讀更多 JAVA架構師之路 的文章
