我所理解的架構,看這篇就對了
什么是架構?
個人所理解的架構的含義應該是:定義一個完整系統中所需的組件以及實現組件間的交互策略。那么很明顯,架構設計應該是考慮如何定義和劃分好每個組件,然后考慮它們是如何基于不同的交互策略來實現我們業務需要的場景。
什么是組件?
個人認為,只要是隸屬于完整系統中的組成部分,都可以看成是組件。這就意味著,架構中不僅要考慮的是我們常見的基礎組件,包括應用服務,數據庫,網絡,物理機等,還有很大的可能需要引入包括緩存,MQ,容器,Nginx等技術組件來支撐業務的完整描述。
什么是框架?
框架可以理解為組件實現的一種規范,比如我們經常說的開源框架,這是可以拿來直接使用的或者在此基礎上進行二次開發的,這些應該是關乎代碼層面的,規范著組件的具體實現方式。
設計架構的出發點?
對于設計而言,我們首先需要知道,設計的這個架構是做什么的?所以對于我們而言,首先要明確架構的作用是什么?
架構是系統的骨架,通過各個組件的交互鏈接,支撐起對所有業務的整體抽象描述。所以在個人的理解中,所有架構的出發點都是為業務服務,所以我們的架構設計的一個出發點是 - 業務!
從日PV上千到日PV上億的業務數量級演變,驅動著單體式系統到分布式系統的架構技術演變,技術不會平白無故的出現和自驅動發展的,都是受到不同的刺激因素的影響進行發展,就好比如果不是人類看到了火,才知道可以取火,那么人類是永遠不會平白無故發明火。而我們架構的發展恰好是基于業務的驅動。
什么才是好的架構設計?
上面已經說了,在架構設計過程中當我們系統已經明確了所有的組件,那么剩下的就是考慮的是組件和組件間的交互。
這里的交互不僅僅是理解為基于不同的網絡協議通訊,還有比如組件間的緩存如何交互(分布式緩存),消息隊列進行數據交互,是分布式調用還是進程間調用。組件如何能進行良好的交互呢?這就是好的架構設計體現了。
那么好的架構設計是什么呢?
1、能解決當下業務問題
2、能以優雅且可復用的方式解決當下所有業務問題
3、能在未來一段時間都能以第2種方式滿足業務
這其實就是健壯的系統體現的特性了,高可用、高性能,安全性、可擴展性、可維護性、可伸縮性,而這恰好是一個架構設計需要考慮的東西。
- 高性能:用戶量的保證前提
- 前端優化
- 應用優化
- 數據庫優化
- 高可用:保證服務器不宕機
- 數據備份
- 自動發布
- 灰度發布
- 監控報警
- 可擴展:分布式系統,集群
- 負載均衡
- 緩存負載均衡
- 分布式消息
- 服務化
- 安全性:預防網站的各種攻擊
- XSS攻擊
- SQL注入緩存負載均衡
- CSRF攻擊
- 防火墻漏洞
什么是差的架構?
差的架構其實大家都可以顯而易見,就是如果大家都抱怨很多地方有牽一發而動全身,那這里的設計肯定有問題,耦合性這些是可以通過很多設計思想和原則來避免的。
我最想提到的是風險這點,是很重要也是很容易被大家忽略的一點,而且是起到指數級作用的。選擇的方案再好,如果都是一些掌控不住的技術,那么風險就是無窮大,導致減號右側無限趨近于0,最終的結果就是收益是負數,投入的成本打水漂,甚至還要加上其它額外的付出。

架構師是做什么的?
架構師應該是基于自己對該行業的理解,對所要設計的系統能夠給出總體設計進而進行全局把控的人,并能解決關鍵問題、指導其他人員落實設計。
好的架構師最重要的并不僅僅是在技術方面的深厚積累,更多的是需要懂得在各種情況權衡各種影響因素之后選擇合適的技術實現業務。架構師不會在確定了架構藍圖之后任務就結束了,因為架構不是空中樓閣和水中鏡月,架構是要落地的,如果架構師不著手去主導實現自己提出的恢宏藍圖,那這些好看的藍圖能否能穩當落地呢?
在我的個人觀察下,市面上比較多公司的架構師可能都比較局限于某些開源框架的應用以及個人的一個技術棧影響而對架構定了型,我碰到過這樣的架構師,憑著對技術的狂熱,把市面上流行的技術輕易引入項目中,這就會容易引入風險,這是我們所有后續要往技術方面進階的同學都要注意的地方。
總結
我們需要知道,沒有完美的架構,只有合適的架構,架構是需要演變的。在當前的業務驅動下,架構的設計出發點是解決現有需求和問題,那么我們的架構設計就止于此了嗎?不是的,雖然我們不提倡過度設計,但是如果作為架構師在這個業務所屬的行業中沒一點前瞻性的話,其實是不合格的,公司需要的是架構師的技術能力以及經驗,從而不會每次當業務進行演變時,導致架構翻天覆地的變化。