我所理解的架構
什麼是架構？
個人所理解的架構的含義應該是：定義一個完整系統中所需的元件以及實現元件間的互動策略。那麼很明顯，架構設計應該是考慮如何定義和劃分好每個元件，然後考慮它們是如何基於不同的互動策略來實現我們業務需要的場景。
什麼是元件？
個人認為，只要是隸屬於完整系統中的組成部分，都可以看成是元件。這就意味著，架構中不僅要考慮的是我們常見的基礎元件，包括應用服務，資料庫，網路，物理機等，還有很大的可能需要引入包括快取，MQ，容器，Nginx等技術元件來支撐業務的完整描述。
什麼是框架？
框架可以理解為元件實現的一種規範，比如我們經常說的開源框架，這是可以拿來直接使用的或者在此基礎上進行二次開發的，這些應該是關乎程式碼層面的，規範著元件的具體實現方式。
設計架構的出發點？
對於設計而言，我們首先需要知道，設計的這個架構是做什麼的？所以對於我們而言，首先要明確架構的作用是什麼？
架構是系統的骨架，通過各個元件的互動連結，支撐起對所有業務的整體抽象描述。所以在個人的理解中，所有架構的出發點都是為業務服務，所以我們的架構設計的一個出發點是 - 業務！
從日PV上千到日PV上億的業務數量級演變，驅動著單體式系統到分散式系統的架構技術演變，技術不會平白無故的出現和自驅動發展的，都是受到不同的刺激因素的影響進行發展，就好比如果不是人類看到了火，才知道可以取火，那麼人類是永遠不會平白無故發明火。而我們架構的發展恰好是基於業務的驅動。
什麼才是好的架構設計？
上面已經說了，在架構設計過程中當我們系統已經明確了所有的元件，那麼剩下的就是考慮的是元件和元件間的互動。
這裡的互動不僅僅是理解為基於不同的網路協議通訊，還有比如元件間的快取如何互動（分散式快取），訊息佇列進行資料互動，是分散式呼叫還是程序間呼叫。元件如何能進行良好的互動呢？這就是好的架構設計體現了。
那麼好的架構設計是什麼呢？
- 能解決當下業務問題
- 能以優雅且可複用的方式解決當下所有業務問題
- 能在未來一段時間都能以第2種方式滿足業務
這其實就是健壯的系統體現的特性了，高可用、高效能，安全性、可擴充套件性、可維護性、可伸縮性，而這恰好是一個架構設計需要考慮的東西。
- 高效能：使用者量的保證前提
前端優化
應用優化
資料庫優化 - 高可用：保證伺服器不宕機
資料備份
自動釋出
灰度釋出
監控報警 - 可擴充套件：分散式系統，叢集
負載均衡
快取負載均衡
分散式訊息
服務化 - 安全性：預防網站的各種攻擊
XSS攻擊
SQL注入快取負載均衡
CSRF攻擊
防火牆漏洞
什麼是差的架構？
差的架構其實大家都可以顯而易見，就是如果大家都抱怨很多地方有牽一髮而動全身，那這裡的設計肯定有問題，耦合性這些是可以通過很多設計思想和原則來避免的。
我最想提到的是風險這點，是很重要也是很容易被大家忽略的一點，而且是起到指數級作用的。選擇的方案再好，如果都是一些掌控不住的技術，那麼風險就是無窮大，導致減號右側無限趨近於0，最終的結果就是收益是負數，投入的成本打水漂，甚至還要加上其它額外的付出。
架構師是做什麼的？
架構師應該是基於自己對該行業的理解，對所要設計的系統能夠給出總體設計進而進行全域性把控的人，並能解決關鍵問題、指導其他人員落實設計。
好的架構師最重要的並不僅僅是在技術方面的深厚積累，更多的是需要懂得在各種情況權衡各種影響因素之後選擇合適的技術實現業務。架構師不會在確定了架構藍圖之後任務就結束了，因為架構不是空中樓閣和水中鏡月，架構是要落地的，如果架構師不著手去主導實現自己提出的恢巨集藍圖，那這些好看的藍圖能否能穩當落地呢？
在我的個人觀察下，市面上比較多公司的架構師可能都比較侷限於某些開源框架的應用以及個人的一個技術棧影響而對架構定了型，我碰到過這樣的架構師，憑著對技術的狂熱，把市面上流行的技術輕易引入專案中，這就會容易引入風險，這是我們所有後續要往技術方面進階的同學都要注意的地方。
總結
我們需要知道，沒有完美的架構，只有合適的架構，架構是需要演變的。在當前的業務驅動下，架構的設計出發點是解決現有需求和問題，那麼我們的架構設計就止於此了嗎？不是的，雖然我們不提倡過度設計，但是如果作為架構師在這個業務所屬的行業中沒一點前瞻性的話，其實是不合格的，公司需要的是架構師的技術能力以及經驗，從而不會每次當業務進行演變時，導致架構翻天覆地的變化。