任何複雜技術的架構幾乎都是隨着需求的變化以及業務的增長逐漸演化出來的，並不是一開始就是複雜的龐然大物，互聯網後端的技術架構幾乎莫不是如此。
數據庫篇
以 MySQL 爲例說明支持事務的持久化數據庫的架構演變。
單實例 single-instance
在數據量很小，業務規模也很小的時候一般使用一臺數據庫實例即可，比如業務還處於探索階段，用戶量很少的情況。
優勢
簡單，開發調試方便，維護成本低廉
缺點
缺乏可靠性，單機實例一旦故障，既不可寫，又不可讀。
主從結構 master-slave
伴隨着業務的增長，單機性能會遇到瓶頸，比如單機連接數、單機處理併發的能力都是有限的，這就需要數據庫可以做到橫向擴展，主從結構 master-slave 就是滿足這一需求的架構，有的地方又稱之爲 master-replication 架構。
優勢
可靠性得到提升，主節點故障，從節點會自動提升爲主節點，突破了單機性能瓶頸，可以做到橫向擴展。
缺點
主從節點同步有延遲，主從節點數據一致性需要一定的時間，對數據實時性要求較高的場景需要開發者自己處理同步延遲的問題，比如讀寫都在 master 節點上執行。
雙主多從
爲了保證主庫的高可用，可以設置多個主庫，多個主庫之間進行雙向同步，使用 keepalive 監測雙主的可用性隨時進行切換。
優勢
解決寫單點的問題。
缺點
主庫之間同步一致性複雜。
分片 sharding
隨着數據量的不斷增大，單機存儲所有數據會導致數據庫實例的性能開始下降，於是會考慮根據業務需求，把數據拆分成幾部分存儲，稱之爲切片分庫，每一數據庫實例存儲整體數據中的一部分，這樣單機存儲的容量會降低，能夠繼續充分發揮單機的性能。
優勢
數據分散存儲，能夠通過橫向擴展，滿足業務發展需求。
缺點
複雜度高，橫向擴展雖然能夠降低單機數據的存儲量，但是實時複雜，比如對於一般採用的 hash 方法實時的分庫，新增節點，意味着原有的數據需要重新 hash。
分片加主從
數據分片解決的是數據量過大的問題，但是單節點的可靠性並沒有得到保證，因而可以在分片的同時，對每一個分片繼續實施主從架構以保證單個片的數據可靠性。
優勢
數據分散存儲，數據可靠性有保證，支持橫向擴展，滿足業務需求。
自動分片和自動擴容
這是數據庫架構最理想的狀態，相當於支持無限擴展，只要新增節點，在保證數據可靠性的同時(多副本存儲)，集羣會自動對數據進行動態平衡（重新 hash）。
緩存篇
緩存是互聯網架構中必不可少的一個組件，以 redis 爲例說明緩存架構的演變。
單點 single-instance
緩存的重要作用就是緩解持久化 DB 的壓力，業務發展的初期用戶量少，單點足以應付
優勢
配合單點 APP 使用，和 APP 部署在同一主機，部署方便，維護方便，開發方便
主從結構 master-slave
隨着用戶量增大，請求規模的增長，單點無法滿足請求壓力，可以使用主從結構來分攤請求壓力，緩存的場景以寫少讀多最常見，主從結構能夠有效緩解單點的帶來的問題。
優勢
解決單點性能瓶頸
一致性 hash 切片 sharding
隨着單點的寫壓力以及數據量逐步增大，可以使用一致性 hash 的方式將數據進行切片分散存儲，解決單點容量的問題，一致性 hash 的方式能夠有效緩解，增減節點帶來的緩存失效問題。
優勢
解決單點容量不足的問題和壓力過大的問題
劣勢
運維複雜
一致性 hash 高可用
切片之後的數據存在單點的問題，也就是數據只在一個節點讀和寫，如果節點掛掉，緩存就失效了。如果業務需要保證緩存也要高可用，每個節點可以使用主從結構，多副本的方式存儲，配合以 sentinel 進行主從切換。
優勢
解決切片之後數據單點的問題
一致性 hash 自動伸縮
採用一致性 hash 最大的問題是縮容和擴容帶來的數據一致性難題，每增加和刪除節點都需要重新對數據進行動態調整，要做到能夠自動伸縮一般會配以 monitor 組件對每個節點的容量進行監控，在達到閾值之後，新增節點進行擴容，然後通知 router 等組件，一致性 hash 的 slot 發生了變化，對受影響的 key 進行特殊處理，保證數據的可用性，遷移完成之後，通知 router 開始正常處理請求。
APP 篇
同數據庫和緩存，後端應用服務的架構也是隨業務的發展逐步調整，不斷演化
單點
壓力很小的驗證業務時候採用的架構模式，cache、session、nginx、DB 可能都是同一主機，配合以 crontab 完成異步任務。
集羣
採用集羣一方面是爲了解決單點壓力的問題，一方面是爲了解決單點可靠性的問題，當 crontab 的任務數量成規模之後，需要採用異步任務隊列來代替實現，維護成本更低，開發更高效。
更大規模的單體應用
隨着業務的複雜度的提升，在未採用微服務之前，APP 會按照功能和服務不斷進行拆分，各個 APP 之間通過 MQ 進行通信，異步任務隊列也可以採用 MQ 來取代，緩存使用分佈式緩存，可以按照自己的需要採用 master-slave 或者一致性 hash，數據庫按照業務需要可以是 master-slave，也可以是切片分庫，外網通過 DNS 輪詢的方式進行負載均衡，靜態文件採用 CDN 進行分發。
微服務
隨着單體規模的不斷變大，單體應用的業務邊界會越來越模糊，會有很多重複的功能出現在單體應用中，這些重複功能會導致每個單體應用都會消耗一定的基礎設置資源，比如緩存、DB 資源等等，爲了減少重複功能的開發和維護，合理利用基礎設置資源，單體應用逐步演化成微服務架構。
在微服務架構中，每個服務維護着自己的數據庫，也就是說數據庫的連接資源等都是每個服務自己持有，各個服務之間通過 MQ 進行數據通信，隨着架構的複雜度提升，配套的需要有配置中心、服務註冊與發現、日誌、監控、調用鏈接追蹤等基礎設施來支持整個微服務的運行。