筆者做java開發已經四年多了 , 這個  架構學習  系列 , 算是對四年時間的一個積累 , 也是做一個記錄 , 

概括:

《可擴充套件的藝術》一書提出了一個更加系統的可擴充套件模型——AKF可擴充套件立方（Scalability Cube）。這個立方體中沿著三個座標軸設定分別為：X、Y、Z。
X軸擴充套件 —— 關注水平的資料和服務克隆，也就是前文提到的“加機器解決問題” Y軸擴充套件 —— 關注應用中職責的劃分，比如資料型別，交易執行型別的劃分  Z軸擴充套件 —— 關注服務和資料的優先順序劃分，如分地域劃分 
借用一下別人得總結 , 感覺挺模糊的 , 不過筆者個人感覺很有道理 . 

• X軸擴充套件 —— 關注水平的資料和服務克隆 , 也就是所謂的  加機器 , 部署多個節點 ,實現負載均衡 ;  快取叢集 ;  使用訊息佇列 ; 資料庫的主從複製,讀寫分離 , 升級硬體 等等 , 個人感覺 先升級硬體(scale up) , 再水平擴充套件(scale out)這樣的順序更好一些; 當然這只是對應一般的業務場景 , 一些特殊的業務 , 比如秒殺 之類的需要在單純的增加節點之後做一些額外的操作 , 在這裡只做一個概括  , 之後的系列會分開詳細說明
• Y軸擴充套件 —— 關注應用中職責的劃分 ; 這個通俗的來說主要就是服務化和分庫分表了 ,  著重需要注意分散式事務問題
  
• Z軸擴充套件 —— 關注服務和資料的優先順序劃分 ; 這個形象點說就是多機房了
  

上面說了架構的概括 , 接下來詳細說一下架構的具體 , 讓這篇文章幹一些 , 沒有那麼虛 , 筆者工作以來的方向主要是 網際網路社群  ,  但是架構這東西我覺得都差不多, 接下來我給大家展示幾幅圖 , 表現出架構的升級過程.
這個是筆者之前的一個公司的架構 , 相信這個簡單的架構是很多中小公司的標配了 , 當時公司的產品大概有百萬使用者 , 每天日活最高是兩萬 , 用這套架構完全可以承載使用者的請求 , 不過這裡省略了一些細節, 比如說是圖片的儲存 , 還有im訊息 , 這些都是使用的付費服務 , 主要的目的是這些產品比較完善 , cdn加速可以提高使用者體驗 ; 初期減少運維成本 , 人少 , 精力有限等.
這個是筆者目前公司的架構 , 這個只是一部分 , 涵蓋的是APP相關的架構