Apache的架構師們遵循的30條設計原則

本文作者叫Srinath,是一位科學家,軟體架構師,也是一名在分散式系統上工作的程式設計師。 他是Apache Axis2專案的聯合創始人,也是Apache Software基金會的成員。 他是WSO2流處理器(wso2.com/analytics)的聯席架構師。 Srinath撰寫了兩本關於MapReduce和許多技術文章的書。 他獲得了博士學位。 來自美國印第安納大學。

Srinath通過不懈的努力最終總結出了30條架構原則,他主張架構師的角色應該由開發團隊本身去扮演,而不是專門有個架構師團隊或部門。Srinath認為架構師應該扮演的角色是一個引導者,討論發起者,花草修建者,而不是定義者和構建者。Srinath為了解決團隊內部的架構紛爭和抉擇,制定了以下30條原則,這些原則被成員們廣泛認可,也成為了新手架構師的學習途徑。

Apache的架構師們遵循的30條設計原則


基本原則


原則1:KISS(Keep it simple,sutpid) 和保持每件事情都儘可能的簡單。用最簡單的解決方案來解決問題。

原則2:YAGNI(You aren’t gonna need it)-不要去搞一些不需要的東西,需要的時候再搞吧。

原則3:爬,走,跑。換句話說就是先保證跑通,然後再優化變得更好,然後繼續優化讓其變得偉大。迭代著去做事情,敏捷開發的思路。對於每個功能點,建立里程碑(最大兩週),然後去迭代。

原則4:建立穩定、高質量的產品的唯一方法就是自動化測試。所有的都可以自動化,當你設計時,不妨想想這一點。

原則5:時刻要想投入產出比(ROI)。就是划得來不。

原則6:瞭解你的使用者,然後基於此來平衡你需要做哪些事情。不要花了幾個月時間做了一個devops使用者介面,最後你發現那些人只喜歡命令列。此原則是原則5的一個具體表現。

原則7:設計和測試一個功能得儘可能的獨立。當你做設計時,應該想想這一條。從長遠來看這能給你解決很多問題,否則你的功能只能等待系統其他所有的功能都就緒了才能測試,這顯然很不好。有了這個原則, 你的版本將會更加的順暢。

原則8:不要搞花哨的。我們都喜歡高階炫酷的設計。最後我們搞了很多功能和解決方案到我們的架構中,然後這些東西根本不會被用到。

功能選擇

原則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理論。可擴充套件的事務(分散式事務)是很難的。如果可能的的話,儘可能的使用補償機制。RDBMS事務是無法擴充套件的。

原則20:分散式一致性無法擴充套件,也無法進行組通訊,也無法進行叢集範圍內的可靠通訊。理想情況下最大的節點限制為8個節點。

原則21:在分散式系統中,你永遠無法避免延遲和失敗。

使用者體驗

原則22:要了解你的使用者和清楚他們的目標。他們是新手、專家還是偶然的使用者?他們瞭解電腦科學的程度。極客喜歡擴充套件點,開發者喜歡示例和指令碼,而普通人則喜歡UI。

原則23:最好的產品是不需要產品手冊的。

原則24:當你無法在兩個選擇中做決定的時候,請不要直接把這個問題通過提供配置選項的方式傳遞給使用者。這樣只能讓使用者更加的發懵。如果連你這個專家都無法選擇的情況下,交給一個比你瞭解的還少的人這樣合適嗎?最好的做法的是每次都找到一個可行的選項;次好的做法是自動的給出選項,第三好的做法是增加一個配置引數,然後設定一個合理的預設值。

原則25:總是要為配置設定一個合理的預設值。

原則26:設計不良的配置會造成一些困擾。應該總是為配置提供一些示例值。

原則27:配置值必須是使用者能夠理解和直接填寫的。比如:不能讓使用者填寫最大快取條目的數量,而是應該讓使用者填寫可被用於快取的最大記憶體。

原則28:如果輸入了未知的配置要丟擲錯誤。永遠不要悄悄的忽略。悄悄的忽略配置錯誤往往是找bug花了數小時的罪魁禍首。

艱難的問題

原則29:夢想著新的程式語言就會變得簡單和明瞭,但往往要想真正掌握會很難。不要輕易的去換程式語言。

原則30:複雜的拖拉拽的介面是艱難的,不要去嘗試這樣的效果,除非你準備好了10人年的團隊。

最後,說一個我的感受。在一個理想的世界裡,一個平臺應該是有多個正交元件組成-每個元件都負責一個方面(比如,security,messaging,registry,mdidation,analytics)。好像一個系統構建成這樣才是完美的。但不幸的是,現實中我們很難達到這樣的狀態。因為在專案初始狀態時,很多事情是不確定的,你無法做到這樣的獨立性,現在我更傾向於在開始的時候適當的重複是必要的,當你嘗試剷除他們的時候,你會發現引入了新的複雜性,分佈本身就意味著複雜。有時候治癒的過程要比疾病本身更加的糟糕。

總結

作為一個架構師,應該像園丁一般,更多的是修剪花草,除草而不是去定義和構建,你應該策劃而不是指揮,你應該去修剪而不是去定義,應該是討論而不是貼標籤。雖然在短期內可能會覺得也沒什麼,但從長遠看,指導團隊找到自己的方式會帶來好處。如果你稍不留神,就很容易讓架構成為一個空洞的詞彙。比如設計者會說他的架構是錯誤的,但不知道為什麼是錯誤的。一個避免這種情況的好辦法就是有一個原則列表,這個原則列表是被廣泛接受的,這個列表是人們討論問題的錨點,也是新手架構師學習的路徑。

相关推荐