系統架構的11條原則
基本原則
原則一：價值為王
解析：
價值為王的另一種說法叫做YAGNI。YAGNI 是 You aren』t gonna need it 的縮寫。該原則的基本含義就是，不應該開發任何當前不使用的功能。因為這些佔用開發成本的功能，可能根本沒有人用。而且不僅僅是開發成本打了水漂，你還要不斷投入維護成本，來保證這些無人使用的功能可以正常運行。
要了解阿姆達爾定律，它告訴我們，我們不可能無限制的提升系統某一部分的效率。要提升的總體效果有沒有產生相應的價值。
原則二：以終為始
解析：
以終為始是一種思維模式，最早出自《黃帝內經》，先人是在告誡後人要在人生的春天就認真思考人生終點的意義和價值。其引申義有三：一是凡事要有目標；二是凡事要有計劃；三是凡事要有原則。正所謂「凡事預則立，不預則廢」。
白話來說，以終為始，就是在做事之前，先想想結果是什麼樣子的，這個結果是否能達到最初的目標。小心X-Y問題：為了解決 X問題，覺得用 Y 可以解，於是研究 Y 問題，結果搞到最後，發現原來要解決的 X 問題。
原則三：分治原則
解析：
做架構時不要想著一次性把所有的功能都做好，要擁抱 MVP（Minimal Viable Product），最小可運行版本。先讓程式完成最基本功能上線，根據回饋調整和決定下一步的迭代。
迭代著去做事情，敏捷開發的思路。對於每個功能點，創建里程碑，然後去迭代。
原則四：服務自治
解析：
在系統設計時，要考慮服務上線後，對於問題要自感知、自修復、自優化、自運維及自安全。
原則五：擁抱變化
解析：
重視架構擴展性和可運維性。無狀態的系統的是可擴展的和直接的。任何時候都要考慮這一點，不要搞個不可擴展的，有狀態的東東出來。否則，一旦需要改變，成本很高。
原則六：簡單即正義
解析：
簡單即正義的另一種說法叫做KISS。KISS(Keep it simple,sutpid)保持每件事情都儘可能的簡單。用最簡單的解決方案來解決問題。
原則七：盡量自動化
解析：
人力成本既慢又貴，還有經常不斷的人工失誤。如果不能降低人力成本，反而需要更多的人，那麼這個架構設計一定是失敗的。
穩定性原則
原則八：依賴最簡
解釋：
依賴原則是去除依賴、弱化依賴、控制依賴。多一個依賴多一分風險。能不依賴則不依賴，能非同步弱依賴不要同步強依賴。實在不能弱依賴的，比如必須要調用加密存儲來獲取資料庫的密碼，不然無法連接資料庫，可以控制獲取密碼在服務啟動時進行，如果獲取不到則服務啟動失敗，因為現在都是集群部署，一台無法啟動不影響整體提供服務。
原則九：不作不死
解釋：
儘可能的做較少的功能。當有疑問的時候，就不要去做，甚至幹掉。很多功能從來不會被使用。最多留個擴展點就夠了。
等到有人提出再說（除非是影響核心流程，否則就等到需要的時候再去做）。
原則十：容災容錯
解析：
Everything fails! 人都是要死的，機器都是要壞的。如果一件事情有可能發生則在生產環境中一定會發生，架構中要做好容錯設計。
原則十一：用成熟的技術
解析：
不要給別人的技術當小白鼠，不要因技術本身的問題影響系統的穩定。儘可能的使用紅利大的主流技術，而不要自己發明輪子，更不要魔改。在技術選型上，千萬不要被——「你看某個公司也在用這個技術」，或是一些在論壇上看到的一些程式設計師吐槽技術的觀點（沒有任何的數據，只有自己的喜好）來決定自己的技術，還是看看主流大多數公司實際在用的技術棧，會更靠譜一些。
總結
一張圖總結今天的內容：
編程一生
因為公眾號平台更改了推送規則，如果不想錯過內容，記得讀完點一下「在看」，加個「星標」，這樣每次新文章推送才會第一時間出現在你的訂閱列表裡。
PDCA方法論，檢查自己是否錯過更新：每周三晚上8點左右，我都會更新文章，如果你沒有收到，記得點開【編程一生】公眾號找一下(*^▽^*)
