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