雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
【編者的話】本文作者叫Srinath，是一位科學家，軟體架構師，也是一名在分布式系統上工作的程式員。他是Apache Axis2項目的聯合創始人，也是Apache Software基金會的成員。他是WSO2流處理器（wso2.com/analytics）的聯席架構師。Srinath撰寫了兩本關于MapReduce和許多技術文章的書。他獲得了博士學位。來自美國印第安納大學。
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。是真的需要724365嗎？
使用者體驗
原則22：要了解你的使用者和清楚他們的目标。他們是新手、專家還是偶然的使用者？他們了解計算機科學的程度。極客喜歡擴充點，開發者喜歡示例和腳本，而普通人則喜歡UI。
原則23：最好的産品是不需要産品手冊的。
原則24：當你無法在兩個選擇中做決定的時候，請不要直接把這個問題通過提供配置選項的方式傳遞給使用者。這樣隻能讓使用者更加的發懵。如果連你這個專家都無法選擇的情況下，交給一個比你了解的還少的人這樣合适嗎？最好的做法的是每次都找到一個可行的選項；次好的做法是自動的給出選項，第三好的做法是增加一個配置參數，然後設定一個合理的預設值。
原則25：總是要為配置設定一個合理的預設值。
原則26：設計不良的配置會造成一些困擾。應該總是為配置提供一些示例值。
原則27：配置值必須是使用者能夠了解和直接填寫的。比如：不能讓使用者填寫最大緩存條目的數量，而是應該讓使用者填寫可被用于緩存的最大記憶體。
原則28：如果輸入了未知的配置要抛出錯誤。永遠不要悄悄的忽略。悄悄的忽略配置錯誤往往是找bug花了數小時的罪魁禍首。
艱難的問題
原則29：夢想着新的程式設計語言就會變得簡單和明了，但往往要想真正掌握會很難。不要輕易的去換程式設計語言。
小編點評：“技術極客”是聽不進去的，不如把“個人修煉”和“項目采用”分開看待……
原則30：複雜的拖拉拽的界面是艱難的，不要去嘗試這樣的效果，除非你準備好了10人年的團隊。
小編點評：我一直不太相信整體性的代碼生成，比如MDA，或者拖拉拽模組化代替寫代碼……如果說有成功的，或者是在比較狹小的領域
最後，說一個我的感受。在一個理想的世界裡，一個平台應該是有多個正交元件組成-每個元件都負責一個方面（比如，security，messaging，registry，mdidation，analytics）。好像一個系統建構成這樣才是完美的。但不幸的是，現實中我們很難達到這樣的狀态。因為在項目初始狀态時，很多事情是不确定的，你無法做到這樣的獨立性，現在我更傾向于在開始的時候适當的重複是必要的，當你嘗試鏟除他們的時候，你會發現引入了新的複雜性，分布本身就意味着複雜。有時候治愈的過程要比疾病本身更加的糟糕。
小編點評：不同階段采用不同的做法，照抄往往會東施效颦。
總結
作為一個架構師，應該像園丁一般，更多的是修剪花草，除草而不是去定義和建構，你應該策劃而不是指揮，你應該去修剪而不是去定義，應該是讨論而不是貼标簽。雖然在短期内可能會覺得也沒什麼，但從長遠看，指導團隊找到自己的方式會帶來好處。如果你稍不留神，就很容易讓架構成為一個空洞的詞彙。比如設計者會說他的架構是錯誤的，但不知道為什麼是錯誤的。一個避免這種情況的好辦法就是有一個原則清單，這個原則清單是被廣泛接受的，這個清單是人們讨論問題的錨點，也是新手架構師學習的路徑。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-06-04
本文作者：翔宇
本文來自：“
dockone”，了解相關資訊可以關注“dockone”
![搭建httpd服務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)