我的所理解的架構的含義應該是:定義一個完整系統中所需的組件以及實現組件間的交互策略。那麼很明顯,架構設計應該是考慮如何定義和劃分好每一個組件,而後考慮它們是如何基於不一樣的交互策略來實現咱們業務須要的場景。 前端
我的認爲,只要是隸屬於完整系統中的組成部分,均可以當作是組件。這就意味着,架構中不只要考慮的是咱們常見的基礎組件,包括應用服務,數據庫,網絡,物理機等,還有很大的可能須要引入包括緩存,MQ,容器,Nginx等技術組件來支撐業務的完整描述。數據庫
框架能夠理解爲組件實現的一種規範,好比咱們常常說的開源框架,這是能夠拿來直接使用的或者在此基礎上進行二次開發的,這些應該是關乎代碼層面的,規範着組件的具體實現方式。緩存
對於設計而言,咱們首先須要知道,設計的這個架構是作什麼的?因此對於咱們而言,首先要明確架構的做用是什麼?安全
架構是系統的骨架,經過各個組件的交互連接,支撐起對全部業務的總體抽象描述。因此在我的的理解中,全部架構的出發點都是爲業務服務,因此咱們的架構設計的一個出發點是 - 業務!服務器
從日PV上千到日PV上億的業務數量級演變,驅動着單體式系統到分佈式系統的架構技術演變,技術不會無緣無故的出現和自驅動發展的,都是受到不一樣的刺激因素的影響進行發展,就比如若是不是人類看到了火,才知道能夠取火,那麼人類是永遠不會無緣無故發明火。而咱們架構的發展剛好是基於業務的驅動。 網絡
上面已經說了,在架構設計過程當中當咱們系統已經明確了全部的組件,那麼剩下的就是考慮的是組件和組件間的交互。架構
這裏的交互不只僅是理解爲基於不一樣的網絡協議通信,還有好比組件間的緩存如何交互(分佈式緩存),消息隊列進行數據交互,是分佈式調用仍是進程間調用。組件如何能進行良好的交互呢?這就是好的架構設計體現了。 負載均衡
那麼好的架構設計是什麼呢?在認識層面上,我我的想要強調的是,咱們可能不少人對架構的認識有誤區,認爲架構是集合全部流行和高深的技術,這種認識是片面的,架構在強調其健壯性的同時,也須要講究其易用性,就比如編碼,好的編碼並非你用了多深多高級的思想,而是寫出能給人看得懂的代碼,而不只僅是給機器看。框架
在架構設計時咱們必須明確出發點,技術不是萬能的,不要單純爲了技術而技術,技術是爲業務服務的,單純的技術引入必定要考慮這樣是否會增長系統的複雜度(不少這樣的作法都是對系統的複雜度引發指數級別的),因此在技術層面上看,我認爲好的架構設計是如下幾點:前端優化
這其實就是健壯的系統體現的特性了,高可用、高性能,安全性、可擴展性、可維護性、可伸縮性,而這剛好是一個架構設計須要考慮的東西。
差的架構其實你們均可以顯而易見,就是若是你們都抱怨不少地方有牽一髮而動全身,那這裏的設計確定有問題,耦合性這些是能夠經過不少設計思想和原則來避免的。
我最想提到的是風險這點,是很重要也是很容易被你們忽略的一點,並且是起到指數級做用的。選擇的方案再好,若是都是一些掌控不住的技術,那麼風險就是無窮大,致使減號右側無限趨近於0,最終的結果就是收益是負數,投入的成本打水漂,甚至還要加上其它額外的付出。
架構師應該是基於本身對該行業的理解,對所要設計的系統可以給出整體設計進而進行全局把控的人,並能解決關鍵問題、指導其餘人員落實設計。
好的架構師最重要的並不只僅是在技術方面的深厚積累,更多的是須要懂得在各類狀況權衡各類影響因素以後選擇合適的技術實現業務。架構師不會在肯定了架構藍圖以後任務就結束了,由於架構不是空中樓閣和水中鏡月,架構是要落地的,若是架構師不着手去主導實現本身提出的恢宏藍圖,那這些好看的藍圖可否能妥當落地呢?
在個人我的觀察下,市面上比較多公司的架構師可能都比較侷限於某些開源框架的應用以及我的的一個技術棧影響而對架構定了型,我碰到過這樣的架構師,憑着對技術的狂熱,把市面上流行的技術輕易引入項目中,這就會容易引入風險,這是咱們全部後續要往技術方面進階的同窗都要注意的地方。
咱們須要知道,沒有完美的架構,只有合適的架構,架構是須要演變的。在當前的業務驅動下,架構的設計出發點是解決現有需求和問題,那麼咱們的架構設計就止於此了嗎?不是的,雖然咱們不提倡過分設計,可是若是做爲架構師在這個業務所屬的行業中沒一點前瞻性的話,實際上是不合格的,公司須要的是架構師的技術能力以及經驗,從而不會每次當業務進行演變時,致使架構翻天覆地的變化。