眾所周知,架構師的角色,更偏向于策劃、而非指揮,塑造、而非支配,其存在的意義,在于引導大家討論、而非自己主宰一切。
但是,具體應該如何執(zhí)行呢?本文作者整理了 30 個公認的架構原則,來幫助大家解決此問題。也許有的原則,你從未聽說,但你看完就能快速學會。
相信你學會了,工作起來也會事半功倍,或許還可幫你避免很多無用的加班!
在 WSO2,我參與架構評審的時間已長達八年之久。WSO2 的產(chǎn)品非常豐富,比如 WSO2 ESB 、WSO2 API Manager 以及 WSO2 SP 都人盡皆知。在過去八年中,我們對許多產(chǎn)品和功能進行了討論、設計、改進和重新設計。
我們在設計軟件的過程中,把握的一個關鍵點是:軟件架構并非由架構師負責設計。我們的架構不是由架構師制定,然后交給其他人來實施。
相反,架構的設計任務由真正編寫代碼的團隊負責。架構師負責對工程師設計的架構進行修復、完策劃和改進。我們的架構團隊是指導員和把關人,而非獨裁者。
在短期內(nèi),由一位架構師來制定架構的確既快捷又實惠。但是,從長遠來看,我們會組建一個團隊,讓他們自己不斷思考、改善架構,并從他們的錯誤中來提升自己。
當我們專注于團隊時,他們自然會隨著時間的推移而變得更好。架構團隊的首要任務是:盡可能保證架構容易執(zhí)行。此外,架構評審也存在缺陷。
就像 Paul (@pzfreo)描述的架構評審那樣:架構師參與進來,聽一會,發(fā)表一點評論然后就走了。作為一名架構師,你對架構發(fā)表自己的看法和意見無可厚非。但是,如果你不夠投入和細心,你的意見可能會讓團隊感到困惑,團隊就無法確定正確的做法到底是什么。
接下來我會將30個架構原則一一列出,其中一些原則是眾所周知的,而有些則源于我的個人經(jīng)驗和心血。
基本原則
原則1: KISS (Keep it simple,sutpid) 和保持每件事情都盡可能的簡單,用最簡單的解決方案來解決問題。
原則2:YAGNI(你不需要它)原則 ,只在需要時構建。
原則3:先學會爬,然后再學會走,最后學會跑。換句話說,先保證能夠正常運行,然后優(yōu)化它使其更好,最后逐漸讓它變得完美。使用迭代開發(fā),采用敏捷開發(fā)模式。為每個功能制定一個開發(fā)周期(最多2周),然后不斷迭代。
原則4:自動化測試是構建穩(wěn)定、高質量產(chǎn)品的唯一方法。通過自動化測試提升創(chuàng)造力,所有一切都可以自動化!在設計時應當好好考慮自動化。
原則5:注重投資回報率(ROI)并將最多的注意力放在最重要的地方。
原則6:了解用戶并相應地平衡資源。大多數(shù)產(chǎn)品都有數(shù)千個最終用戶,大致需要20個開發(fā)人員和100個 DevOps 人員。不要花費數(shù)月的時間來構建一個不太可能使用 DevOps 的用戶界面(他們更喜歡腳本)。這是原則5的特例。
原則7:功能的設計和測試盡可能獨立。如果在設計時考慮到這一點,長遠來看,它將省去很多麻煩,否則只有一切構建完成時你才可以開始測試整個系統(tǒng)。此外,遵循這個原則,版本發(fā)布也會更加順利。
原則8:警惕搜索引擎中花里胡哨的架構方案。我們天生都喜歡令人奪目的設計。如果你按奈不住, 就可能把太多根本不需要的功能和解決方案引入到你的架構中。
功能選擇
原則9:想要準確知道用戶如何使用我們的產(chǎn)品是很難的。所以我們要推行MVP(最小可行產(chǎn)品)。該理念的核心在于:先制定一些用例,完成用例所涉及的相關功能,立即發(fā)布產(chǎn)品,然后根據(jù)反饋和經(jīng)驗對產(chǎn)品進行優(yōu)化。
原則10:盡可能減少功能,如有疑問則將其刪除。許多功能可能從未使用,你只需為其留一個擴展接口即可。
原則11:聽取客戶的意見,看他們想要什么功能。
原則12:當客戶要求的功能影響到其他模塊時,要勇于和客戶辯論。從大局出發(fā),嘗試找到另一種方法來處理問題。就像 Fords 所說的那樣“每當我問顧客需要什么的時候,他們總是會說需要跑得更快的馬”。請記住,你才是專家。你應該主導一切,做出正確和專業(yè)的決定。雖然用戶可能當時有些疑惑,但最終他們會感謝你的。
服務端設計和并發(fā)
原則13:要知道一個server是如何運行的,從硬件到操作系統(tǒng),直到編程語言。優(yōu)化IO調用的數(shù)量是你通往最好架構的首選之路。
原則14:遵循 Amdhal 的同步定律。線程之間共享的可變數(shù)據(jù)會降低程序速度。如果可以,請使用并發(fā)數(shù)據(jù)結構,并且僅在必要時使用同步。盡可能少地使用鎖。如果你打算在線程鎖期間阻塞,請確保自己足夠了解具體細節(jié),因為這里存在極大的隱患。
原則15:如果你的設計是基于事件驅動的非阻塞架構,那就不要阻塞線程或者在線程中執(zhí)行 IO 操作。一旦這樣做,系統(tǒng)將慢如蝸牛。
分布式系統(tǒng)
原則16:無狀態(tài)系統(tǒng)具有良好的擴展性。我們要盡可能了解和使用無分享架構。
原則17:除非你能夠掌控客戶端和服務器的所有代碼,否則消息傳遞失敗的情況在所難免。盡量減少你的系統(tǒng)依賴的因素(例如使用原則18)。
原則18:盡可能實施冪等操作。這樣它就很容易恢復,你至少可以保證交付沒問題。
原則19:了解 CAP 定理??蓴U展的事務(分布式事務)是很難的 。盡可能使用補償,基于 RDBMS 的事務很難擴展。
原則20:分布式系統(tǒng)共識不支持擴展,也無法進行組通信,不支持群集范圍內(nèi)的可靠消息傳遞。其最大節(jié)點限制大約是八個節(jié)點。
原則21:在分布式系統(tǒng)中,你很難隱藏分布式系統(tǒng)中的延遲和故障。(參見分布式計算的謬誤解釋 )。
用戶體驗
原則22:了解你的用戶以及他們的目標:他是新手、專家還是臨時用戶?他對計算機科學了解多少?極客看重擴展功能,開發(fā)人員關注示例和腳本,普通人則更在乎界面。
原則23:最好的產(chǎn)品應當不需要用戶手冊,用戶應該一看就會用。
原則24:當你無法在兩個選項之間做出決定時,請不要通過配置選項的方式來呈現(xiàn)問題。這會給用戶和架構師帶來麻煩。對于系統(tǒng)如何運作的細節(jié),他們沒有你了解,他們怎么能做出決定呢?最好的方案是找到一個每次都有效的選擇;其次是自動做出選擇;第三個方案是添加配置參數(shù)并設置合理的默認值。
原則25:始終具有合理的配置默認值。
原則26:設計不良的配置會制造麻煩,始終配置幾個示例值。
原則27:詢問用戶配置值的時候,注意選擇用戶無需即可設置的值(例如,不要問用戶需要的最大緩存條目數(shù)量,而是要問他想要用于緩存的內(nèi)存數(shù)量)
原則28:如果發(fā)現(xiàn)未知配置,則拋出錯誤。永遠不要忽視它。在調試過程中,無提示的配置錯誤會浪費我們很多調式時間。
難點
原則29:嘗試新語言很容易,但要正確使用卻很難。除非公司愿意組建一個十人團隊并花一年的時間來學習,否則盡量不要這樣做。如果你仍不死心,請閱讀有關語言設計的五個問題后再做定奪。
原則30:可組合的拖放 UI 很難實現(xiàn),除非團隊準備投入10人年的資源,否則不要去做。
最后,談一下我的感受。在理想情況下,一個平臺應當由多個正交組件組成,每個組件負責一個方面(例如,安全性、消息傳遞、注冊、調解、分析,等等)。使用這些功能構建的系統(tǒng)將是最佳的。
不幸的是,現(xiàn)實中我們很難達到這樣的狀態(tài)。因為在項目初始狀態(tài)時,很多事情是不確定的,你無法做到這樣的獨立性,現(xiàn)在我認為在開始的時候適當?shù)闹貜褪潜匾?,當你嘗試鏟除他們的時候,你會發(fā)現(xiàn)引入了新的復雜性,分布本身就意味著復雜。有時候治愈的過程要比疾病本身更加的糟糕。
總結
作為一個架構師,我們應該像園丁一樣思考、塑造、策劃和去除雜草而不是定義和構建。雖然在短期內(nèi),由一位架構師來制定架構的確既快捷又實惠。但是,從長遠來看,團隊的力量才是最強的。
如果你不夠投入和細心,你只指出錯誤,但是不道明錯誤原因,那么你的意見可能會讓團隊感到困惑。避免這種情況的一種方法是擁有一套普遍接受的原則,這些原則是討論架構時遵循的基本點,也是初學者學習架構的好資源。所以想成為 一名優(yōu)秀的架構師,還是需要長期的磨練以及時間的驗證,當然隨時保持學習的狀態(tài)也是非常重要的。當你學會更多知識,你便會更清晰的解決各種復雜的架構問題。
作者 | Srinath Perera ,是一位計算機科學家、軟件架構師、作家,他是 apache 的核心成員,擁有 15 年分布式系統(tǒng)編程經(jīng)驗,設計了 Apache Axis2 以及 WSO2 流處理器。譯者:安翔。
第三十四屆CIO班招生
北達軟EXIN網(wǎng)絡空間與IT安全基礎認證培訓
北達軟EXIN DevOps Professional認證培訓
責編:yangjun
免責聲明:本網(wǎng)站(http://www.www.gypb.net/)內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿,凡在本網(wǎng)站出現(xiàn)的信息,均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性,但不保證有關資料的準確性及可靠性,讀者在使用前請進一步核實,并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏,概不負任何法律責任。
本網(wǎng)站刊載的所有內(nèi)容(包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等)版權歸原作者所有。任何單位或個人認為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時,請及時通知本站,予以刪除。