架構師速成-架構體系

通過這段時間的反思和整理，終於對架構有了一個較爲明確的理解。架構是產品從無到有以及慢慢壯大過程當中所須要的所有技術體系總稱，架構過程：

1. 配置、編碼、測試、運維、監控分析、安全、運營等一系列技術體系的選型、取捨
2. 技術選型基礎上進行規劃、設計、實現、迭代、制定相關規範
3. 相關技術及規範運用到產品開發的整個過程當中，並在產品迭代過程當中對架構進行迭代優化

架構不止包含技術的框架，好比有人用了spring就以爲我已是架構師了，其實架構並非這麼簡單。咱們以作一個新浪微博相似產品爲例，現實應該是這樣的：

1. 產品初期，經典的LAMP快速開發實現第一個版本，功能也無比簡單就是加好友，發消息，開發人員也只有一個小的隊伍。此時的架構就體現爲純的技術選型及實現，包含了
   • 配置：代碼經過git管理，暫時無其餘
   • 編碼：技術選型爲LAMP，基於LAMP的開發框架封裝，並在開發團隊內製定開發規範
   • 測試：技術人員手工測試
   • 運維：手工發佈，主備2臺，mysql也作主備
   • 監控：暫不須要
   • 安全：發帖過濾、屏蔽
   • 運營：後臺刪帖
2. 隨着用戶的暴增以及功能的增長，產品須要迭代，架構也須要迭代。產品功能加強，性能須要優化，開發人員的增長，此時架構就發生了一個較大的變革：
   • 配置：代碼經過git管理，要分爲多個模塊，不一樣團隊開發不一樣模塊
   • 編碼：技術選型增長緩存、消息隊列、搜索引擎等，框架封裝更加複雜，抽象出基礎層和服務層。分團隊進行代碼的維護，制定不一樣模塊之間通訊標準。推拉模型也提煉出來。
   • 測試：單元測試+自動化測試
   • 運維：批量自動化發佈、回滾、支持灰度發佈
   • 監控：增長流量監控，機器監控
   • 安全：發帖過濾、屏蔽，防範其餘攻擊
   • 運營：後臺刪帖、大V管理等等
3. 用戶和流量再次增長後，產品再次發生變革，架構也再次變革。
   • 配置：代碼經過git管理，服務化，每一個服務單獨一個模塊，不一樣團隊開發不一樣模塊
   • 編碼：技術選型須要考慮異地容災，層次繼續抽取，服務粒度細化，增長開放api，改進推送架構。
   • 測試：單元測試+自動化測試
   • 運維：批量自動化發佈、回滾、支持灰度發佈，異地數據同步
   • 監控：增長流量監控，機器監控，增長緩存等監控
   • 安全：發帖過濾、屏蔽，防範其餘攻擊，開放api權限管理oauth2，防止惡意調用
   • 運營：後臺刪帖、大V管理等等

從上面的例子能夠看出，架構是跟隨產品進行迭代的，並且隨着產品的愈來愈複雜，不可避免的須要不斷拆分，多團隊合做，運維自動化。架構也變成團隊的工做，而不是一個架構師就搞定一切了。

阿里發展到如今架構也有些相似，有不少不一樣團隊負責底層設施（中間件）的開發迭代及其架構的革新。業務也有不一樣的團隊負責開發不一樣的業務模塊，這個都使用統一的架構體系。技術保障部門維護統一的自動化運維工具，安所有門維護安全工具。不一樣部門都有本身的架構師，負責本部分的架構，不過比較遺憾的是沒有一個總架構師的角度去推進整體架構演進及各個部門架構的優化。