網站架構演化之路

今天講點關於咱們公司技術架構演化歷程，本人在公司還沒正式成立的時候就來了，在此期間有幸經歷並參與了公司技術架構的屢次升級的改造工做，也很高興能見證一個公司的發展歷程，從中也學到了不少東西。好了廢話不說了，開噴：

1、初始階段 ：網站發展初期，咱們的架構是什麼樣子的呢？下面用一張圖還說明：

看着圖來介紹下，咱們初始階段的網站技術架構，固然看着也不錯了，開始階段就用了這麼多技術思想，感受挺不錯吧，用了反向代理、用了集羣、用了分佈式緩存、用了獨立的文件服務器和獨立的數據服務器，架構看起來貌似不錯。可是隨着用戶訪問量的增長，逐漸發現流量高峯期的時候咱們的響應時間老是很慢，甚至有幾回直接掛了，主要是訪問數據庫過於頻繁，由於讀寫操做都是操做一個庫，而咱們只有一個庫，以後呢，咱們作了數據庫讀寫分離，寫請求走主庫，讀請求走讀庫，解決了數據庫鏈接數不足的問題。

2、發展中期：網站發展中期，隨着用戶訪問量的不斷遞增，個人技術架構發展成什麼樣子了呢？入下圖所示：

隨着流量的增大，發現讀寫分離已經不能知足咱們的要求，寫庫，逐漸出現瓶頸，讀庫也由於愈來愈多的人操做，從而也開始變慢；而後咱們開始升級咱們的架構，先是按業務功能拆分代碼，獨立部署，而後抽出公共服務，作分佈式部署，即所謂的soa服務化；由於服務化以後呢，不一樣業務使用不一樣的數據庫，即所謂的垂直分庫，後來呢 針對部分業務，咱們又作了分庫、分表技術，經過這些技術手段，咱們解決數據庫因流量大二致使請求響應慢的問題。

3、發展後期：網站發展後期，咱們的技術架構各方面都逐步完善，那到後期咱們的技術架構是什麼樣呢？入下圖所示：

到後期，咱們有作了不少的技術改造，前後用了搜索引擎elasticsearch，在寫數據的時候同時把數據寫到es中，供其它應用查詢使用，這樣咱們的查詢數據就不用操做數據庫了！在後來，咱們在程序中各類作緩存，把凡是可降級的接口，均走本地緩存或者遠程緩存服務、把非關聯的服務作異步並行化調用，從而達到加快服務請求的目的，又經過zookeeper的監視器watcher功能作了統一配置管理服務！！！！寫到這裏有點累了，用到的技術要點太多，只能簡單說下，具體使用每一個技術都是爲了解決項目中遇到的一些實際問題，上邊說大的技術就是咱們目前的技術架構，固然還有一些像中間件的技術、排序算法、大數據分析、實時報表等技術，還有網關等等都給略過了，等有時間，我在詳細說下每一個細節，謝謝！！！！！！