Apache架构师总结的30条设计原则！
點擊上方“朱小廝的博客”，選擇“設為星標”
后臺回復"加群"，加入新技術
?Srinath|ImportSource
今天把 RPC 框架乞丐版差不多寫完了（斷斷續續寫了差不多一個月），下周README寫完之后就開源出來。
今天本來預留有時間寫一篇閑文的，關于時間管理的（小伙伴們問的比較多）。我尋思自己都沒管理好時間，索性就先不寫，后面等我收集點資料之后再寫吧！
今天還是安利一篇不錯的文章給小伙伴們!（流下了明日又要上班的淚水~~~）
本文作者叫 Srinath，是一位科學家，軟件架構師，也是一名在分布式系統上工作的程序員。他是 Apache Axis2 項目的聯合創始人，也是 Apache Software 基金會的成員。他是 WSO2 流處理器（wso2.com/analytics）的聯席架構師。Srinath 撰寫了兩本關于 MapReduce 和許多技術文章的書。他獲得了博士學位。來自美國印第安納大學。
Srinath 通過不懈的努力最終總結出了 30 條架構原則，他主張架構師的角色應該由開發團隊本身去扮演，而不是專門有個架構師團隊或部門。Srinath 認為架構師應該扮演的角色是一個引導者，討論發起者，花草修建者，而不是定義者和構建者。Srinath 為了解決團隊內部的架構紛爭和抉擇，制定了以下 30 條原則，這些原則被成員們廣泛認可，也成為了新手架構師的學習途徑。
基本原則
原則 1： KISS(Keep it simple,sutpid) ：保持每件事情都盡可能的簡單。用最簡單的解決方案來解決問題。
Guide：簡單即是復雜！拿你的代碼來說，你想要寫的簡單且容易理解的話，你就需要花更多的時間去思考。
原則 2： YAGNI(You aren’t gonna need it)：不要去搞一些不需要的東西，需要的時候再搞吧。
Guide : 這一點我被 diss 過好幾次，之前的時候，我總是臆想覺得某個功能以后可能會用到，然后就順手把它實現了，實際到了后面并沒用上，反而造成了代碼冗余。
原則 3： 爬，走，跑。換句話說就是先保證跑通，然后再優化變得更好，然后繼續優化讓其變得偉大。迭代著去做事情，敏捷開發的思路。對于每個功能點，創建里程碑（最大兩周），然后去迭代。
原則 4： 創建穩定、高質量的產品的唯一方法就是自動化測試。所有的都可以自動化，當你設計時，不妨想想這一點。
Guide：單側還是很有必要的，但是沒有一個恒定的標準說你應該怎么去做。
原則 5： 時刻要想投入產出比（ROI）。就是劃得來不。
原則 6： 了解你的用戶，然后基于此來平衡你需要做哪些事情。不要花了幾個月時間做了一個 devops 用戶界面，最后你發現那些人只喜歡命令行。此原則是原則 5 的一個具體表現。
Guide:是否有站在用戶的角度思考問題呢？是否是為了用新技術而用新技術？
原則 7： 設計和測試一個功能，盡可能的獨立。當你做設計時，應該想想這一條。從長遠來看這能給你解決很多問題，否則你的功能只能等待系統其他所有的功能都就緒了才能測試，這顯然很不好。有了這個原則， 你的版本將會更加的順暢。
原則 8： 不要搞花哨的。我們都喜歡高端炫酷的設計。最后我們搞了很多功能和解決方案到我們的架構中，然后這些東西根本不會被用到。
Guide:簡單點！說話的方式簡單點！
功能選擇
原則 9： 不可能預測到用戶將會如何使用我們的產品。所以要擁抱 MVP（Minimal Viable Product），最小可運行版本。這個觀點主要思想就是你挑幾個很少的使用場景，然后把它搞出來，然后發布上線讓用戶使用，然后基于體驗和用戶反饋再決定下一步要做什么。
原則 10： 盡可能的做較少的功能。當有疑問的時候，就不要去做，甚至干掉。很多功能從來不會被使用。最多留個擴展點就夠了。
原則 11： 等到有人提出再說（除非是影響核心流程，否則就等到需要的時候再去做）。
原則 12： 有時候你要有勇氣和客戶說不。這時候你需要找到一個更好的解決方案來去解決。記住亨利福特曾經說過的 ：”如果我問人們他們需要什么，他們會說我需要一匹速度更快的馬”。記住：你是那個專家，你要去引導和領導。要去做正確的事情，而不是流行的事情。最終用戶會感謝你為他們提供了汽車。
服務端設計和并發
原則 13： 要知道一個 server 是如何運行的，從硬件到操作系統，直到編程語言。優化 IO 調用的數量是你通往最好架構的首選之路。
原則 14： 要了解 Amdhal 同步定律。在線程之間共享可變數據會讓你的程序變慢。只在必要的時候才去使用并發的數據結構，只在必須使用同步（synchronization）的時候才去使用同步。如果要用鎖，也要確保盡可能少的時間去 hold 住鎖。如果要在加鎖后做一些事情，要確保自己在鎖內會做哪些事情。
原則 15： 如果你的設計是一個無阻塞且事件驅動的架構，那么千萬不要阻塞線程或者在這些線程中做一些 IO 操作，如果你做了，你的系統會慢的像騾子一樣。
分布式系統
原則 16： 無狀態的系統的是可擴展的和直接的。任何時候都要考慮這一點，不要搞個不可擴展的，有狀態的東東出來，這是起碼的。
原則 17： 保證消息只被傳遞一次，不管失敗，這很難，除非你要在客戶端和服務端都做控制。試著讓你的系統更輕便（使用原則 18）。你要知道大部分的承諾 exactly-once-delivery 的系統都是做了精簡的。
原則 18： 實現一個操作盡可能的冪等。這樣的話就比較好恢復，而且你還處于至少一次傳遞（at least once delivery）的狀態。
原則 19： 知道 CAP 理論?？蓴U展的事務（分布式事務）是很難的。如果可能的的話，盡可能的使用補償機制。RDBMS 事務是無法擴展的。
原則 20： 分布式一致性無法擴展，也無法進行組通信，也無法進行集群范圍內的可靠通信。理想情況下最大的節點限制為 8 個節點。
原則 21： 在分布式系統中，你永遠無法避免延遲和失敗。
用戶體驗
原則 22： 要了解你的用戶和清楚他們的目標。他們是新手、專家還是偶然的用戶？他們了解計算機科學的程度。極客喜歡擴展點，開發者喜歡示例和腳本，而普通人則喜歡 UI。
原則 23： 最好的產品是不需要產品手冊的。
Guide：這個是說產品易用。很多人覺得敏捷開發下不需要文檔，實際上，一個系統即是在敏捷開發的情況下，有些必要的文檔比如重大更新記錄、相關硬件設施等等還是需要的。
原則 24： 當你無法在兩個選擇中做決定的時候，請不要直接把這個問題通過提供配置選項的方式傳遞給用戶。這樣只能讓用戶更加的發懵。如果連你這個專家都無法選擇的情況下，交給一個比你了解的還少的人這樣合適嗎？最好的做法的是每次都找到一個可行的選項；次好的做法是自動的給出選項，第三好的做法是增加一個配置參數，然后設置一個合理的默認值。
原則 25： 總是要為配置設置一個合理的默認值。
原則 26： 設計不良的配置會造成一些困擾。應該總是為配置提供一些示例值。
原則 27： 配置值必須是用戶能夠理解和直接填寫的。比如：不能讓用戶填寫最大緩存條目的數量，而是應該讓用戶填寫可被用于緩存的最大內存。
原則 28： 如果輸入了未知的配置要拋出錯誤。永遠不要悄悄的忽略。悄悄的忽略配置錯誤往往是找 bug 花了數小時的罪魁禍首。
艱難的問題
原則 29： 夢想著新的編程語言就會變得簡單和明了，但往往要想真正掌握會很難。不要輕易的去換編程語言。
原則 30： 復雜的拖拉拽的界面是艱難的，不要去嘗試這樣的效果，除非你準備好了 10 人年的團隊。
最后，說一個我的感受。在一個理想的世界里，一個平臺應該是有多個正交組件組成-每個組件都負責一個方面（比如，security，messaging，registry，mdidation，analytics）。好像一個系統構建成這樣才是完美的。
但不幸的是，現實中我們很難達到這樣的狀態。因為在項目初始狀態時，很多事情是不確定的，你無法做到這樣的獨立性，現在我更傾向于在開始的時候適當的重復是必要的，當你嘗試鏟除他們的時候，你會發現引入了新的復雜性，分布本身就意味著復雜。有時候治愈的過程要比疾病本身更加的糟糕。
總結
作為一個架構師，應該像園丁一般，更多的是修剪花草，除草而不是去定義和構建，你應該策劃而不是指揮，你應該去修剪而不是去定義，應該是討論而不是貼標簽。
雖然在短期內可能會覺得也沒什么，但從長遠看，指導團隊找到自己的方式會帶來好處。如果你稍不留神，就很容易讓架構成為一個空洞的詞匯。比如設計者會說他的架構是錯誤的，但不知道為什么是錯誤的。一個避免這種情況的好辦法就是有一個原則列表，這個原則列表是被廣泛接受的，這個列表是人們討論問題的錨點，也是新手架構師學習的路徑。
想知道更多？掃描下面的二維碼關注我
后臺回復”加群“獲取公眾號專屬群聊入口
【原創系列 | 精彩推薦】
Paxos、Raft不是一致性算法嘛？
越說越迷糊的CAP
分布式事務科普——初識篇
分布式事務科普——終結篇
面試官居然問我Raft為什么會叫做Raft!
面試官給我挖坑：URI中的//有什么用
面試官給我挖坑：a[i][j]和a[j][i]有什么區別？
面試官給我挖坑：單機并發TCP連接數到底有多少？
網關Zuul科普
網關Spring Cloud?Gateway科普
Nginx架構原理科普
OpenResty概要及原理科普
微服務網關 Kong 科普
云原生網關Traefik科普
點個在看少個 bug?????
總結
以上是生活随笔為你收集整理的Apache架构师总结的30条设计原则！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： JAVA 泛型中的通配符 T，E，K，V
- 下一篇： 科普扫盲，HTTP Status Cod