建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
作者介紹
Srinath通過(guò)不懈的努力最終總結(jié)出了30條架構(gòu)原則，他主張架構(gòu)師的角色應(yīng)該由開(kāi)發(fā)團(tuán)隊(duì)本身去扮演，而不是專(zhuān)門(mén)有個(gè)架構(gòu)師團(tuán)隊(duì)或部門(mén)。Srinath認(rèn)為架構(gòu)師應(yīng)該扮演的角色是一個(gè)引導(dǎo)者，討論發(fā)起者，花草修建者，而不是定義者和構(gòu)建者。Srinath為了解決團(tuán)隊(duì)內(nèi)部的架構(gòu)紛爭(zhēng)和抉擇，制定了以下30條原則，這些原則被成員們廣泛認(rèn)可，也成為了新手架構(gòu)師的學(xué)習(xí)途徑。
目前創(chuàng)新互聯(lián)建站已為1000+的企業(yè)提供了網(wǎng)站建設(shè)、域名、虛擬空間、網(wǎng)站托管維護(hù)、企業(yè)網(wǎng)站設(shè)計(jì)、陵川網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶(hù)導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶(hù)和合作伙伴齊心協(xié)力一起成長(zhǎng)，共同發(fā)展。
一、基本原則
原則1
KISS(Keep it simple,sutpid) 和保持每件事情都盡可能的簡(jiǎn)單。用最簡(jiǎn)單的解決方案來(lái)解決問(wèn)題。
原則2
YAGNI(You aren’t gonna need it)，不要去搞一些不需要的東西，需要的時(shí)候再搞吧。
原則3
爬，走，跑。換句話(huà)說(shuō)就是先保證跑通，然后再優(yōu)化變得更好，然后繼續(xù)優(yōu)化讓其變得偉大。迭代著去做事情，敏捷開(kāi)發(fā)的思路。對(duì)于每個(gè)功能點(diǎn)，創(chuàng)建里程碑(最大兩周)，然后去迭代。
原則4
創(chuàng)建穩(wěn)定、高質(zhì)量的產(chǎn)品的唯一方法就是自動(dòng)化測(cè)試。所有的都可以自動(dòng)化，當(dāng)你設(shè)計(jì)時(shí)，不妨想想這一點(diǎn)。
原則5
時(shí)刻要想投入產(chǎn)出比(ROI)，即是否劃得來(lái)。
原則6
了解你的用戶(hù)，然后基于此來(lái)平衡你需要做哪些事情。不要花了幾個(gè)月時(shí)間做了一個(gè)devops用戶(hù)界面，最后你發(fā)現(xiàn)那些人只喜歡命令行。此原則是原則5的一個(gè)具體表現(xiàn)。
原則7
設(shè)計(jì)和測(cè)試一個(gè)功能得盡可能的獨(dú)立。當(dāng)你做設(shè)計(jì)時(shí)，應(yīng)該想想這一條。從長(zhǎng)遠(yuǎn)來(lái)看這能給你解決很多問(wèn)題，否則你的功能只能等待系統(tǒng)其他所有的功能都就緒了才能測(cè)試，這顯然很不好。有了這個(gè)原則， 你的版本將會(huì)更加的順暢。
原則8
不要搞花哨的。我們都喜歡高端炫酷的設(shè)計(jì)。最后我們搞了很多功能和解決方案到我們的架構(gòu)中，然后這些東西根本不會(huì)被用到。
二、功能選擇
原則9
不可能預(yù)測(cè)到用戶(hù)將會(huì)如何使用我們的產(chǎn)品。所以要擁抱MVP(Minimal Viable Product)，最小可運(yùn)行版本。這個(gè)觀點(diǎn)主要思想就是你挑幾個(gè)很少的使用場(chǎng)景，然后把它搞出來(lái)，然后發(fā)布上線讓用戶(hù)使用，然后基于體驗(yàn)和用戶(hù)反饋再?zèng)Q定下一步要做什么。
原則10
盡可能的做較少的功能。當(dāng)有疑問(wèn)的時(shí)候，就不要去做，甚至干掉。很多功能從來(lái)不會(huì)被使用。最多留個(gè)擴(kuò)展點(diǎn)就夠了。
原則11
等到有人提出再說(shuō)(除非是影響核心流程，否則就等到需要的時(shí)候再去做)。
原則12
有時(shí)候你要有勇氣和客戶(hù)說(shuō)不。這時(shí)候你需要找到一個(gè)更好的解決方案來(lái)去解決。記住亨利福特曾經(jīng)說(shuō)過(guò)的 ：”如果我問(wèn)人們他們需要什么，他們會(huì)說(shuō)我需要一匹速度更快的馬”。記住：你是那個(gè)專(zhuān)家，你要去引導(dǎo)和領(lǐng)導(dǎo)。要去做正確的事情，而不是流行的事情。最終用戶(hù)會(huì)感謝你為他們提供了汽車(chē)。
三、服務(wù)端設(shè)計(jì)和并發(fā)
原則13
要知道一個(gè)server是如何運(yùn)行的，從硬件到操作系統(tǒng)，直到編程語(yǔ)言。優(yōu)化IO調(diào)用的數(shù)量是你通往最好架構(gòu)的首選之路。
原則14
要了解Amdhal同步定律。在線程之間共享可變數(shù)據(jù)會(huì)讓你的程序變慢。只在必要的時(shí)候才去使用并發(fā)的數(shù)據(jù)結(jié)構(gòu)，只在必須使用同步(synchronization)的時(shí)候才去使用同步。如果要用鎖，也要確保盡可能少的時(shí)間去hold住鎖。如果要在加鎖后做一些事情，要確保自己在鎖內(nèi)會(huì)做哪些事情。
原則15
如果你的設(shè)計(jì)是一個(gè)無(wú)阻塞且事件驅(qū)動(dòng)的架構(gòu)，那么千萬(wàn)不要阻塞線程或者在這些線程中做一些IO操作，如果你做了，你的系統(tǒng)會(huì)慢的像騾子一樣。
四、分布式系統(tǒng)
原則16
無(wú)狀態(tài)的系統(tǒng)的是可擴(kuò)展的和直接的。任何時(shí)候都要考慮這一點(diǎn)，不要搞個(gè)不可擴(kuò)展的，有狀態(tài)的東東出來(lái)，這是起碼的。
原則17
保證消息只被傳遞一次，不管失敗，這很難，除非你要在客戶(hù)端和服務(wù)端都做控制。試著讓你的系統(tǒng)更輕便(使用原則18)。你要知道大部分的承諾exactly-once-delivery的系統(tǒng)都是做了精簡(jiǎn)的。
原則18
實(shí)現(xiàn)一個(gè)操作盡可能的冪等。這樣的話(huà)就比較好恢復(fù)，而且你還處于至少一次傳遞(at least once delivery)的狀態(tài)。
原則19
知道CAP理論?？蓴U(kuò)展的事務(wù)(分布式事務(wù))是很難的。如果可能的的話(huà)，盡可能的使用補(bǔ)償機(jī)制。RDBMS事務(wù)是無(wú)法擴(kuò)展的。
原則20
分布式一致性無(wú)法擴(kuò)展，也無(wú)法進(jìn)行組通信，也無(wú)法進(jìn)行集群范圍內(nèi)的可靠通信。理想情況下最大的節(jié)點(diǎn)限制為8個(gè)節(jié)點(diǎn)。
原則21
在分布式系統(tǒng)中，你永遠(yuǎn)無(wú)法避免延遲和失敗。
五、用戶(hù)體驗(yàn)
原則22
要了解你的用戶(hù)和清楚他們的目標(biāo)。他們是新手、專(zhuān)家還是偶然的用戶(hù)?他們了解計(jì)算機(jī)科學(xué)的程度。極客喜歡擴(kuò)展點(diǎn)，開(kāi)發(fā)者喜歡示例和腳本，而普通人則喜歡UI。
原則23
最好的產(chǎn)品是不需要產(chǎn)品手冊(cè)的。
原則24
當(dāng)你無(wú)法在兩個(gè)選擇中做決定的時(shí)候，請(qǐng)不要直接把這個(gè)問(wèn)題通過(guò)提供配置選項(xiàng)的方式傳遞給用戶(hù)。這樣只能讓用戶(hù)更加的發(fā)懵。如果連你這個(gè)專(zhuān)家都無(wú)法選擇的情況下，交給一個(gè)比你了解的還少的人這樣合適嗎?最好的做法的是每次都找到一個(gè)可行的選項(xiàng);次好的做法是自動(dòng)的給出選項(xiàng)，第三好的做法是增加一個(gè)配置參數(shù)，然后設(shè)置一個(gè)合理的默認(rèn)值。
原則25
總是要為配置設(shè)置一個(gè)合理的默認(rèn)值。
原則26
設(shè)計(jì)不良的配置會(huì)造成一些困擾。應(yīng)該總是為配置提供一些示例值。
原則27
配置值必須是用戶(hù)能夠理解和直接填寫(xiě)的。比如：不能讓用戶(hù)填寫(xiě)最大緩存條目的數(shù)量，而是應(yīng)該讓用戶(hù)填寫(xiě)可被用于緩存的最大內(nèi)存。
原則28
如果輸入了未知的配置要拋出錯(cuò)誤。永遠(yuǎn)不要悄悄的忽略。悄悄的忽略配置錯(cuò)誤往往是找bug花了數(shù)小時(shí)的罪魁禍?zhǔn)住?/p>
六、艱難的問(wèn)題
原則29
夢(mèng)想著新的編程語(yǔ)言就會(huì)變得簡(jiǎn)單和明了，但往往要想真正掌握會(huì)很難。不要輕易的去換編程語(yǔ)言。
原則30
復(fù)雜的拖拉拽的界面是艱難的，不要去嘗試這樣的效果，除非你準(zhǔn)備好了10人年的團(tuán)隊(duì)。
最后，說(shuō)一個(gè)我的感受。在一個(gè)理想的世界里，一個(gè)平臺(tái)應(yīng)該是有多個(gè)正交組件組成-每個(gè)組件都負(fù)責(zé)一個(gè)方面(比如，security，messaging，registry，mdidation，analytics)。好像一個(gè)系統(tǒng)構(gòu)建成這樣才是完美的。但不幸的是，現(xiàn)實(shí)中我們很難達(dá)到這樣的狀態(tài)。因?yàn)樵陧?xiàng)目初始狀態(tài)時(shí)，很多事情是不確定的，你無(wú)法做到這樣的獨(dú)立性，現(xiàn)在我更傾向于在開(kāi)始的時(shí)候適當(dāng)?shù)闹貜?fù)是必要的，當(dāng)你嘗試鏟除他們的時(shí)候，你會(huì)發(fā)現(xiàn)引入了新的復(fù)雜性，分布本身就意味著復(fù)雜。有時(shí)候治愈的過(guò)程要比疾病本身更加的糟糕。
七、總結(jié)
作為一個(gè)架構(gòu)師，應(yīng)該像園丁一般，更多的是修剪花草，除草而不是去定義和構(gòu)建，你應(yīng)該策劃而不是指揮，你應(yīng)該去修剪而不是去定義，應(yīng)該是討論而不是貼標(biāo)簽。雖然在短期內(nèi)可能會(huì)覺(jué)得也沒(méi)什么，但從長(zhǎng)遠(yuǎn)看，指導(dǎo)團(tuán)隊(duì)找到自己的方式會(huì)帶來(lái)好處。如果你稍不留神，就很容易讓架構(gòu)成為一個(gè)空洞的詞匯。比如設(shè)計(jì)者會(huì)說(shuō)他的架構(gòu)是錯(cuò)誤的，但不知道為什么是錯(cuò)誤的。一個(gè)避免這種情況的好辦法就是有一個(gè)原則列表，這個(gè)原則列表是被廣泛接受的，這個(gè)列表是人們討論問(wèn)題的錨點(diǎn)，也是新手架構(gòu)師學(xué)習(xí)的路徑。
本文題目：Apache架構(gòu)師都遵循的30條設(shè)計(jì)原則
網(wǎng)頁(yè)URL：http://www.dlmjj.cn/article/cdicdde.html
