Apache的架構(gòu)師們遵循的30條設(shè)計(jì)原則

本文作者叫 Srinath，是一位科學(xué)家，軟件架構(gòu)師，也是一名在分布式系統(tǒng)上工作的程序員。 他是 Apache Axis2 項(xiàng)目的聯(lián)合創(chuàng)始人，也是 Apache Software 基金會的成員。 他是WSO2流處理器（wso2.com/analytics）的聯(lián)席架構(gòu)師。 Srinath 撰寫了兩本關(guān)于 MapReduce 和許多技術(shù)文章的書。 他獲得了博士學(xué)位。 來自美國印第安納大學(xué)。

成都創(chuàng)新互聯(lián)公司堅(jiān)持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計(jì)制作、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的塔河網(wǎng)站設(shè)計(jì)、移動媒體設(shè)計(jì)的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

Srinath 通過不懈的努力最終總結(jié)出了30條架構(gòu)原則，他主張架構(gòu)師的角色應(yīng)該由開發(fā)團(tuán)隊(duì)本身去扮演，而不是專門有個架構(gòu)師團(tuán)隊(duì)或部門。Srinath 認(rèn)為架構(gòu)師應(yīng)該扮演的角色是一個引導(dǎo)者，討論發(fā)起者，花草修建者，而不是定義者和構(gòu)建者。Srinath 為了解決團(tuán)隊(duì)內(nèi)部的架構(gòu)紛爭和抉擇，制定了以下30條原則，這些原則被成員們廣泛認(rèn)可，也成為了新手架構(gòu)師的學(xué)習(xí)途徑。

Photo by Muyuan Ma on Unsplash

基本原則

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

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

（小編點(diǎn)評：speculative development的例子可謂俯拾皆是。程序員們對自己說：“我肯定以后會需要這項(xiàng)額外的功能，所以現(xiàn)在就提前把它實(shí)現(xiàn)了吧”。其實(shí)這是最考驗(yàn)功力的地方，不能閉門YY需要的功能，架構(gòu)上又要洞察趨勢。）

原則3：爬，走，跑。換句話說就是先保證跑通，然后再優(yōu)化變得更好，然后繼續(xù)優(yōu)化讓其變得偉大。迭代著去做事情，敏捷開發(fā)的思路。對于每個功能點(diǎn)，創(chuàng)建里程碑（最大兩周），然后去迭代。

（小編點(diǎn)評：快速反饋，一個“拍腦袋的里程碑”也好過沒有里程碑...）

原則4：創(chuàng)建穩(wěn)定、高質(zhì)量的產(chǎn)品的唯一方法就是自動化測試。所有的都可以自動化，當(dāng)你設(shè)計(jì)時，不妨想想這一點(diǎn)。

（小編點(diǎn)評：一切自動化也要考慮ROI，比如對于特別易變的頁面層...）

原則5：時刻要想投入產(chǎn)出比（ROI）。就是劃得來不。

原則6：了解你的用戶，然后基于此來平衡你需要做哪些事情。不要花了幾個月時間做了一個devops用戶界面，最后你發(fā)現(xiàn)那些人只喜歡命令行。此原則是原則5的一個具體表現(xiàn)。

原則7：設(shè)計(jì)和測試一個功能得盡可能的獨(dú)立。當(dāng)你做設(shè)計(jì)時，應(yīng)該想想這一條。從長遠(yuǎn)來看這能給你解決很多問題，否則你的功能只能等待系統(tǒng)其他所有的功能都就緒了才能測試，這顯然很不好。有了這個原則， 你的版本將會更加的順暢。

原則8：不要搞花哨的。我們都喜歡高端炫酷的設(shè)計(jì)。最后我們搞了很多功能和解決方案到我們的架構(gòu)中，然后這些東西根本不會被用到。

（小編點(diǎn)評：老板喜歡ppt？）

功能選擇

原則9：不可能預(yù)測到用戶將會如何使用我們的產(chǎn)品。所以要擁抱MVP（Minimal Viable Product），最小可運(yùn)行版本。這個觀點(diǎn)主要思想就是你挑幾個很少的使用場景，然后把它搞出來，然后發(fā)布上線讓用戶使用，然后基于體驗(yàn)和用戶反饋再決定下一步要做什么。

原則10：盡可能的做較少的功能。當(dāng)有疑問的時候，就不要去做，甚至干掉。很多功能從來不會被使用。最多留個擴(kuò)展點(diǎn)就夠了。

（小編點(diǎn)評：產(chǎn)品經(jīng)理可能是聽不進(jìn)去的，最好采取數(shù)據(jù)度量說話...）

原則11：等到有人提出再說（除非是影響核心流程，否則就等到需要的時候再去做）。

原則12：有時候你要有勇氣和客戶說不。這時候你需要找到一個更好的解決方案來去解決。記住亨利福特曾經(jīng)說過的 ：”如果我問人們他們需要什么，他們會說我需要一匹速度更快的馬”。記住：你是那個專家，你要去引導(dǎo)和領(lǐng)導(dǎo)。要去做正確的事情，而不是流行的事情。最終用戶會感謝你為他們提供了汽車。

服務(wù)端設(shè)計(jì)和并發(fā)

原則13：要知道一個server是如何運(yùn)行的，從硬件到操作系統(tǒng)，直到編程語言。優(yōu)化IO調(diào)用的數(shù)量是你通往最好架構(gòu)的首選之路。

原則14：要了解Amdhal同步定律。在線程之間共享可變數(shù)據(jù)會讓你的程序變慢。只在必要的時候才去使用并發(fā)的數(shù)據(jù)結(jié)構(gòu)，只在必須使用同步（synchronization）的時候才去使用同步。如果要用鎖，也要確保盡可能少的時間去hold住鎖。如果要在加鎖后做一些事情，要確保自己在鎖內(nèi)會做哪些事情。

原則15：如果你的設(shè)計(jì)是一個無阻塞且事件驅(qū)動的架構(gòu)，那么千萬不要阻塞線程或者在這些線程中做一些IO操作，如果你做了，你的系統(tǒng)會慢的像騾子一樣。

分布式系統(tǒng)

原則16：無狀態(tài)的系統(tǒng)的是可擴(kuò)展的和直接的。任何時候都要考慮這一點(diǎn)，不要搞個不可擴(kuò)展的，有狀態(tài)的東東出來，這是起碼的。

原則17：保證消息只被傳遞一次，不管失敗，這很難，除非你要在客戶端和服務(wù)端都做控制。試著讓你的系統(tǒng)更輕便（使用原則18）。你要知道大部分的承諾exactly-once-delivery的系統(tǒng)都是做了精簡的。

原則18：實(shí)現(xiàn)一個操作盡可能的冪等。這樣的話就比較好恢復(fù)，而且你還處于至少一次傳遞（at least once delivery）的狀態(tài)。

原則19：知道CAP理論?？蓴U(kuò)展的事務(wù)（分布式事務(wù)）是很難的。如果可能的的話，盡可能的使用補(bǔ)償機(jī)制。RDBMS事務(wù)是無法擴(kuò)展的。

（小編點(diǎn)評：new SQL了解一下。。。）

原則20：分布式一致性無法擴(kuò)展，也無法進(jìn)行組通信，也無法進(jìn)行集群范圍內(nèi)的可靠通信。理想情況下最大的節(jié)點(diǎn)限制為8個節(jié)點(diǎn)。

原則21：在分布式系統(tǒng)中，你永遠(yuǎn)無法避免延遲和失敗。

（小編點(diǎn)評：嗯，對，面向fail 設(shè)計(jì)。但是你的考慮你的用戶，你的服務(wù)提供SLA。是真的需要7*24*365嗎？）

用戶體驗(yàn)

原則22：要了解你的用戶和清楚他們的目標(biāo)。他們是新手、專家還是偶然的用戶？他們了解計(jì)算機(jī)科學(xué)的程度。極客喜歡擴(kuò)展點(diǎn)，開發(fā)者喜歡示例和腳本，而普通人則喜歡UI。

原則23：最好的產(chǎn)品是不需要產(chǎn)品手冊的。

原則24：當(dāng)你無法在兩個選擇中做決定的時候，請不要直接把這個問題通過提供配置選項(xiàng)的方式傳遞給用戶。這樣只能讓用戶更加的發(fā)懵。如果連你這個專家都無法選擇的情況下，交給一個比你了解的還少的人這樣合適嗎？最好的做法的是每次都找到一個可行的選項(xiàng)；次好的做法是自動的給出選項(xiàng)，第三好的做法是增加一個配置參數(shù)，然后設(shè)置一個合理的默認(rèn)值。

原則25：總是要為配置設(shè)置一個合理的默認(rèn)值。

原則26：設(shè)計(jì)不良的配置會造成一些困擾。應(yīng)該總是為配置提供一些示例值。

原則27：配置值必須是用戶能夠理解和直接填寫的。比如：不能讓用戶填寫最大緩存條目的數(shù)量，而是應(yīng)該讓用戶填寫可被用于緩存的最大內(nèi)存。

原則28：如果輸入了未知的配置要拋出錯誤。永遠(yuǎn)不要悄悄的忽略。悄悄的忽略配置錯誤往往是找bug花了數(shù)小時的罪魁禍?zhǔn)住?/p>

艱難的問題

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

（小編點(diǎn)評：“技術(shù)極客”是聽不進(jìn)去的，不如把“個人修煉”和“項(xiàng)目采用”分開看待...）

原則30：復(fù)雜的拖拉拽的界面是艱難的，不要去嘗試這樣的效果，除非你準(zhǔn)備好了10人年的團(tuán)隊(duì)。

（小編點(diǎn)評：我一直不太相信整體性的代碼生成，比如MDA，或者拖拉拽建模代替寫代碼...如果說有成功的，或者是在比較狹小的領(lǐng)域）

最后，說一個我的感受。在一個理想的世界里，一個平臺應(yīng)該是有多個正交組件組成-每個組件都負(fù)責(zé)一個方面（比如，security，messaging，registry，mdidation，analytics）。好像一個系統(tǒng)構(gòu)建成這樣才是完美的。但不幸的是，現(xiàn)實(shí)中我們很難達(dá)到這樣的狀態(tài)。因?yàn)樵陧?xiàng)目初始狀態(tài)時，很多事情是不確定的，你無法做到這樣的獨(dú)立性，現(xiàn)在我更傾向于在開始的時候適當(dāng)?shù)闹貜?fù)是必要的，當(dāng)你嘗試鏟除他們的時候，你會發(fā)現(xiàn)引入了新的復(fù)雜性，分布本身就意味著復(fù)雜。有時候治愈的過程要比疾病本身更加的糟糕。

（小編點(diǎn)評：不同階段采用不同的做法，照抄往往會東施效顰）

總結(jié)

作為一個架構(gòu)師，應(yīng)該像園丁一般，更多的是修剪花草，除草而不是去定義和構(gòu)建，你應(yīng)該策劃而不是指揮，你應(yīng)該去修剪而不是去定義，應(yīng)該是討論而不是貼標(biāo)簽。雖然在短期內(nèi)可能會覺得也沒什么，但從長遠(yuǎn)看，指導(dǎo)團(tuán)隊(duì)找到自己的方式會帶來好處。如果你稍不留神，就很容易讓架構(gòu)成為一個空洞的詞匯。比如設(shè)計(jì)者會說他的架構(gòu)是錯誤的，但不知道為什么是錯誤的。一個避免這種情況的好辦法就是有一個原則列表，這個原則列表是被廣泛接受的，這個列表是人們討論問題的錨點(diǎn)，也是新手架構(gòu)師學(xué)習(xí)的路徑。

本文轉(zhuǎn)載自 ImportSource。

本文名稱：Apache的架構(gòu)師們遵循的30條設(shè)計(jì)原則
本文地址：http://www.muchs.cn/article12/ghjjgc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、做網(wǎng)站、域名注冊、小程序開發(fā)、ChatGPT、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)