眾所周知，架構師的角色，更偏向于策劃、而非指揮，塑造、而非支配，其存在的意義，在于引導大家討論、而非自己主宰一切。

但是，具體應該如何執行呢?本文作者整理了 30 個公認的架構原則，來幫助大家解決此問題。也許有的原則，你從未聽說，但你看完就能快速學會。

[[279708]]

相信你學會了，工作起來也會事半功倍，或許還可幫你避免很多無用的加班!

本文作者叫 Srinath Perera，是一位計算機科學家、軟件架構師、作家。他是 Apache 的核心成員，擁有 15 年分布式系統編程經驗，設計了 Apache Axis2 以及 WSO2 流處理器。

在 WSO2，我參與架構評審的時間已長達八年之久。WSO2 的產品非常豐富，比如 WSO2 ESB 、WSO2 API Manager 以及 WSO2 SP 都人盡皆知。在過去八年中，我們對許多產品和功能進行了討論、設計、改進和重新設計。

我們在設計軟件的過程中，把握的一個關鍵點是：軟件架構并非由架構師負責設計。我們的架構不是由架構師制定，然后交給其他人來實施。

相反，架構的設計任務由真正編寫代碼的團隊負責。架構師負責對工程師設計的架構進行修復、完善和改進。我們的架構團隊是指導員和把關人，而非獨裁者。

在短期內，由一位架構師來制定架構的確既快捷又實惠。但是，從長遠來看，我們會組建一個團隊，讓他們自己不斷思考、改善架構，并從他們的錯誤中來提升自己。

當我們專注于團隊時，他們自然會隨著時間的推移而變得更好。架構團隊的首要任務是：盡可能保證架構容易執行。此外，架構評審也存在缺陷。

就像 Paul (@pzfreo)描述的架構評審那樣：架構師參與進來，聽一會，發表一點評論然后就走了。作為一名架構師，你對架構發表自己的看法和意見無可厚非。但是，如果你不夠投入和細心，你的意見可能會讓團隊感到困惑，團隊就無法確定正確的做法到底是什么。

接下來我會將 30 個架構原則一一列出，其中一些原則是眾所周知的，而有些則源于我的個人經驗和心血。

基本原則

• 原則1：KISS (Keep it simple,sutpid) 和保持每件事情都盡可能的簡單，用最簡單的解決方案來解決問題。
•  
• 原則 2：YAGNI(你不需要它)原則 ，只在需要時構建。
• 原則 3：先學會爬，然后再學會走，最后學會跑。換句話說，先保證能夠正常運行，然后優化它使其更好，最后逐漸讓它變得完美。使用迭代開發，采用敏捷開發模式。為每個功能制定一個開發周期(最多 2 周)，然后不斷迭代。
• 原則 4：自動化測試是構建穩定、高質量產品的唯一方法。通過自動化測試提升創造力，所有一切都可以自動化!在設計時應當好好考慮自動化。
• 原則 5：注重投資回報率(ROI)并將最多的注意力放在最重要的地方。
• 原則 6：了解用戶并相應地平衡資源。大多數產品都有數千個最終用戶，大致需要 20 個開發人員和 100 個 DevOps 人員。不要花費數月的時間來構建一個不太可能使用 DevOps 的用戶界面(他們更喜歡腳本)。這是原則 5 的特例。
• 原則 7：功能的設計和測試盡可能獨立。如果在設計時考慮到這一點，長遠來看，它將省去很多麻煩，否則只有一切構建完成時你才可以開始測試整個系統。此外，遵循這個原則，版本發布也會更加順利。
• 原則 8：警惕搜索引擎中花里胡哨的架構方案。我們天生都喜歡令人奪目的設計。如果你按捺不住， 就可能把太多根本不需要的功能和解決方案引入到你的架構中。

功能選擇

• 原則 9：想要準確知道用戶如何使用我們的產品是很難的。所以我們要推行 MVP(最小可行產品)。該理念的核心在于：先制定一些用例，完成用例所涉及的相關功能，立即發布產品，然后根據反饋和經驗對產品進行優化。
• 原則 10：盡可能減少功能，如有疑問則將其刪除。許多功能可能從未使用，你只需為其留一個擴展接口即可。
• 原則 11：聽取客戶的意見，看他們想要什么功能。
• 原則 12：當客戶要求的功能影響到其他模塊時，要勇于和客戶辯論。從大局出發，嘗試找到另一種方法來處理問題。就像 Fords 所說的那樣“每當我問顧客需要什么的時候,他們總是會說需要跑得更快的馬”。請記住，你才是專家。你應該主導一切，做出正確和專業的決定。雖然用戶可能當時有些疑惑，但最終他們會感謝你的。

服務端設計和并發

• 原則 13：要知道一個 Server 是如何運行的，從硬件到操作系統，直到編程語言。優化 IO 調用的數量是你通往較好架構的首選之路。
• 原則 14：遵循 Amdhal 的同步定律。線程之間共享的可變數據會降低程序速度。如果可以，請使用并發數據結構，并且僅在必要時使用同步。盡可能少地使用鎖。如果你打算在線程鎖期間阻塞，請確保自己足夠了解具體細節，因為這里存在極大的隱患。
• 原則 15：如果你的設計是基于事件驅動的非阻塞架構，那就不要阻塞線程或者在線程中執行 IO 操作。一旦這樣做，系統將慢如蝸牛。

分布式系統

• 原則 16：無狀態系統具有良好的擴展性。我們要盡可能了解和使用無分享架構。
• 原則 17：除非你能夠掌控客戶端和服務器的所有代碼，否則消息傳遞失敗的情況在所難免。盡量減少你的系統依賴的因素(例如使用原則 18 )。
• 原則 18：盡可能實施冪等操作。這樣它就很容易恢復，你至少可以保證交付沒問題。
• 原則 19：了解 CAP 定理。可擴展的事務(分布式事務)是很難的 。盡可能使用補償，基于 RDBMS 的事務很難擴展。
• 原則 20：分布式系統共識不支持擴展，也無法進行組通信，不支持群集范圍內的可靠消息傳遞。其最大節點限制大約是八個節點。
• 原則 21：在分布式系統中，你很難隱藏分布式系統中的延遲和故障。(參見分布式計算的謬誤解釋 )。

用戶體驗

• 原則 22：了解你的用戶以及他們的目標：他是新手、專家還是臨時用戶?他對計算機科學了解多少?極客看重擴展功能，開發人員關注示例和腳本，普通人則更在乎界面。
• 原則 23：好的產品應當不需要用戶手冊，用戶應該一看就會用。
• 原則 24：當你無法在兩個選項之間做出決定時，請不要通過配置選項的方式來呈現問題。這會給用戶和架構師帶來麻煩。對于系統如何運作的細節，他們沒有你了解，他們怎么能做出決定呢?比較好的方案是找到一個每次都有效的選擇;其次是自動做出選擇;第三個方案是添加配置參數并設置合理的默認值。
• 原則 25：始終具有合理的配置默認值。
• 原則 26：設計不良的配置會制造麻煩，始終配置幾個示例值。
• 原則 27：詢問用戶配置值的時候，注意選擇用戶無需即可設置的值(例如，不要問用戶需要的最大緩存條目數量，而是要問他想要用于緩存的內存數量)
• 原則 28：如果發現未知配置，則拋出錯誤。永遠不要忽視它。在調試過程中，無提示的配置錯誤會浪費我們很多調試時間。

難點

• 原則 29：嘗試新語言很容易，但要正確使用卻很難。除非公司愿意組建一個十人團隊并花一年的時間來學習，否則盡量不要這樣做。如果你仍不死心，請閱讀有關語言設計的五個問題后再做定奪。
• 原則 30：可組合的拖放 UI 很難實現，除非團隊準備投入 10 人/年的資源，否則不要去做。

最后，談一下我的感受。在理想情況下，一個平臺應當由多個正交組件組成，每個組件負責一個方面(例如，安全性、消息傳遞、注冊、調解、分析，等等)。使用這些功能構建的系統將是很好的。

不幸的是，現實中我們很難達到這樣的狀態。因為在項目初始狀態時，很多事情是不確定的，你無法做到這樣的獨立性，現在我認為在開始的時候適當的重復是必要的，當你嘗試鏟除他們的時候，你會發現引入了新的復雜性，分布本身就意味著復雜。有時候治愈的過程要比疾病本身更加的糟糕。

總結

作為一個架構師，我們應該像園丁一樣思考、塑造、策劃和去除雜草而不是定義和構建。雖然在短期內，由一位架構師來制定架構的確既快捷又實惠。但是，從長遠來看，團隊的力量才是強大的。

如果你不夠投入和細心，你只指出錯誤，但是不道明錯誤原因，那么你的意見可能會讓團隊感到困惑。避免這種情況的一種方法是擁有一套普遍接受的原則，這些原則是討論架構時遵循的基本點，也是初學者學習架構的好資源。所以想成為一名優秀的架構師，還是需要長期的磨練以及時間的驗證，當然隨時保持學習的狀態也是非常重要的。當你學會更多知識，你便會更清晰的解決各種復雜的架構問題。