本文做者叫 Srinath，是一位科學家，軟件架構師，也是一名在分佈式系統上工做的程序員。 他是 Apache Axis2 項目的聯合創始人，也是 Apache Software 基金會的成員。 他是WSO2流處理器（wso2.com/analytics）的聯席架構師。Srinath 撰寫了兩本關於 MapReduce 和許多技術文章的書。 他來自美國印第安納大學，擁有博士學位。程序員
做者 | Srinath編程
來源 | ImportSource（importsource）緩存
Srinath 經過不懈的努力最終總結出了30條架構原則，他主張架構師的角色應該由開發團隊自己去扮演，而不是專門有個架構師團隊或部門。Srinath 認爲架構師應該扮演的角色是一個引導者，討論發起者，花草修建者，而不是定義者和構建者。Srinath 爲了解決團隊內部的架構紛爭和抉擇，制定瞭如下30條原則，這些原則被成員們普遍承認，也成爲了新手架構師的學習途徑。微信
基本原則數據結構
原則1：KISS(Keep it simple,sutpid) 和保持每件事情都儘量的簡單。用最簡單的解決方案來解決問題。架構
原則2：YAGNI(You aren’t gonna need it)-不要去搞一些不須要的東西，須要的時候再搞吧。併發
（小編點評：speculative development的例子可謂俯拾皆是。程序員們對本身說：「我確定之後會須要這項額外的功能，因此如今就提早把它實現了吧」。其實這是最考驗功力的地方，不能閉門YY須要的功能，架構上又要洞察趨勢。）編程語言
原則3：爬，走，跑。換句話說就是先保證跑通，而後再優化變得更好，而後繼續優化讓其變得偉大。迭代着去作事情，敏捷開發的思路。對於每一個功能點，建立里程碑（最大兩週），而後去迭代。分佈式
（小編點評：快速反饋，一個「拍腦殼的里程碑」也好過沒有里程碑...）學習
原則4：建立穩定、高質量的產品的惟一方法就是自動化測試。全部的均可以自動化，當你設計時，不妨想一想這一點。
（小編點評：一切自動化也要考慮ROI，好比對於特別易變的頁面層...）
原則5：時刻要想投入產出比（ROI）。就是划得來不。
原則6：瞭解你的用戶，而後基於此來平衡你須要作哪些事情。不要花了幾個月時間作了一個devops用戶界面，最後你發現那些人只喜歡命令行。此原則是原則5的一個具體表現。
原則7：設計和測試一個功能得儘量的獨立。當你作設計時，應該想一想這一條。從長遠來看這能給你解決不少問題，不然你的功能只能等待系統其餘全部的功能都就緒了才能測試，這顯然很很差。有了這個原則， 你的版本將會更加的順暢。
原則8：不要搞花哨的。咱們都喜歡高端炫酷的設計。最後咱們搞了不少功能和解決方案到咱們的架構中，而後這些東西根本不會被用到。
（小編點評：老闆喜歡ppt？）
功能選擇
原則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事務是沒法擴展的。
（小編點評：new SQL瞭解一下。。。）
原則20：分佈式一致性沒法擴展，也沒法進行組通訊，也沒法進行集羣範圍內的可靠通訊。理想狀況下最大的節點限制爲8個節點。
原則21：在分佈式系統中，你永遠沒法避免延遲和失敗。
（小編點評：嗯，對，面向fail 設計。可是你的考慮你的用戶，你的服務提供SLA。是真的須要7*24*365嗎？）
用戶體驗
原則22：要了解你的用戶和清楚他們的目標。他們是新手、專家仍是偶然的用戶？他們瞭解計算機科學的程度。極客喜歡擴展點，開發者喜歡示例和腳本，而普通人則喜歡UI。
原則23：最好的產品是不須要產品手冊的。
原則24：當你沒法在兩個選擇中作決定的時候，請不要直接把這個問題經過提供配置選項的方式傳遞給用戶。這樣只能讓用戶更加的發懵。若是連你這個專家都沒法選擇的狀況下，交給一個比你瞭解的還少的人這樣合適嗎？最好的作法的是每次都找到一個可行的選項；次好的作法是自動的給出選項，第三好的作法是增長一個配置參數，而後設置一個合理的默認值。
原則25：老是要爲配置設置一個合理的默認值。
原則26：設計不良的配置會形成一些困擾。應該老是爲配置提供一些示例值。
原則27：配置值必須是用戶可以理解和直接填寫的。好比：不能讓用戶填寫最大緩存條目的數量，而是應該讓用戶填寫可被用於緩存的最大內存。
原則28：若是輸入了未知的配置要拋出錯誤。永遠不要悄悄的忽略。悄悄的忽略配置錯誤每每是找bug花了數小時的罪魁禍首。
艱難的問題
原則29：夢想着新的編程語言就會變得簡單和明瞭，但每每要想真正掌握會很難。不要輕易的去換編程語言。
（小編點評：「技術極客」是聽不進去的，不如把「我的修煉」和「項目採用」分開看待...）
原則30：複雜的拖拉拽的界面是艱難的，不要去嘗試這樣的效果，除非你準備好了10人年的團隊。
（小編點評：我一直不太相信總體性的代碼生成，好比MDA，或者拖拉拽建模代替寫代碼...若是說有成功的，或者是在比較狹小的領域）
最後，說一個個人感覺。在一個理想的世界裏，一個平臺應該是有多個正交組件組成-每一個組件都負責一個方面（好比，security，messaging，registry，mdidation，analytics）。好像一個系統構建成這樣纔是完美的。但不幸的是，現實中咱們很難達到這樣的狀態。由於在項目初始狀態時，不少事情是不肯定的，你沒法作到這樣的獨立性，如今我更傾向於在開始的時候適當的重複是必要的，當你嘗試剷除他們的時候，你會發現引入了新的複雜性，分佈自己就意味着複雜。有時候治癒的過程要比疾病自己更加的糟糕。
（小編點評：不一樣階段採用不一樣的作法，照抄每每會東施效顰）
總結
做爲一個架構師，應該像園丁通常，更多的是修剪花草，除草而不是去定義和構建，你應該策劃而不是指揮，你應該去修剪而不是去定義，應該是討論而不是貼標籤。雖然在短時間內可能會以爲也沒什麼，但從長遠看，指導團隊找到本身的方式會帶來好處。若是你稍不留神，就很容易讓架構成爲一個空洞的詞彙。好比設計者會說他的架構是錯誤的，但不知道爲何是錯誤的。一個避免這種狀況的好辦法就是有一個原則列表，這個原則列表是被普遍接受的，這個列表是人們討論問題的錨點，也是新手架構師學習的路徑。
本文分享自微信公衆號 - 浪尖聊大數據（bigdatatip）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。