架構師嘔心瀝血的成長之路：單體架構演變成分布式架構
一、前言
隨着互聯網時代的發展，之前的大型機架構很顯然由於高成本、難維護等原因漸漸地變得不再那么主流了，替代它的就是當下最火的分布式架構，從大型機到分布式，經歷了好幾個階段，我們弄明白各個階段的架構，才能更好地理解和體會分布式架構的好處，那么我們就來聊聊分布式架構的演變過程。
二、背景
我們都知道一個成熟的大型網站系統架構並非一開始就設計的非常完美，也沒有一開始就具備高性能、高並發、高可用、安全性等特性，而是隨着用戶量的增加、業務功能的擴展逐步優化，擴展過來的。 在這個過程中，開發模式、技術架構等都會隨着需求迭代發生非常大的變化。 而針對不同業務特征的系統，各自都會有自己的側重點，例如像淘寶這類的網站，要解決的重點問題就是海量商品搜索、下單、支付等問題，同時電商項目會涉及到一些交易，財產，那么意味着安全性也需要非常高; 像騰訊這類的網站，要解決的是數億級別用戶的實時消息傳輸;而像百度這類的公司所要解決的又是海量數據的搜索。每一個種類的業務都有自己不同的系統架構。
下面我們來講講架構師的成長之路，從一個初級程序員到一個系統架構師我們需要去成長到具備什么樣的能力。首先，我們簡單的來搭建一個的電商系統，從這個系統中來看系統的演變過程，這也是我們成為架構是需要去關注的一些系統業務架構的優化。同時要注意的是接下來的演示模型，關注的是數據量、訪問量提升，網站結構的變化，而不關注具體業務的功能點。其次，這個過程是為了讓大家能更好的了解網站演進過程中的一些問題和應對策略。
假如我們系統具備以下功能:
用戶模塊:用戶注冊和管理。
商品模塊:商品展示和管理。
交易模塊:創建交易及支付結算。
三、單體架構
這個階段是網站的初期，也可以認為是互聯網發展的早期，系統架構如上圖所示。我們經常會在單台服務器上運行我們所有的程序和軟件。 把所有軟件和應用都部署在一台機器上，這樣就完成一個簡單系統的搭建，這個階段一般是屬於業務規模不是很大的公司使用，因為機器都是單台的話，隨着我們業務規模的增長，慢慢的我們的網站就會出現一些瓶頸和隱患問題，那么接下來我們就會來講講系統項目的發展。
四、應用服務器和數據庫服務器分離
隨着網站的上線，訪問量逐步上升，服務器的負載慢慢提高，我們應該在服務器還沒有超載的時候就做好規划、提升網站的負載能力。假設此時已經沒辦法在代碼層面上去繼續優化提高了，那么在單台機器的性能遇到瓶頸的時候，增加機器是一個比較簡單好用的方式，但是增加機器的方式相對來說成本會比較高。這個階段增加機器的主要目的是將 web 服務器和數據庫服務器拆分開來，這樣做的話不僅提高了單機的負載能力，也提高了整個系統的容災能力。
這個階段的系統架構如上圖所示，應用服務器和數據庫服務器完全隔離開來，相互互不影響，大大減少了網站宕機的風險，此階段我們已經開始關注到應用服務器的管理了。
五、應用服務器高可用集群
這個階段，隨着訪問量的繼續不斷增加，單台應用服務器已經無法滿足我們的需求。 假設我的數據庫服務器還沒有遇到性能問題，那我們可以通過增加應用服務器的方式來將應用服務器集群化，這樣就可以將用戶請求分流到各個服務器中，從而達到繼續服務器高可用、提升系統負載能力的目的。此時各個應用服務器之間沒有直接的交互，他們都是依賴數據庫各自對外提供服務。
系統架構業務發展到這個階段，各種問題也會接踵而至：
用戶請求交由誰來轉發到具體的應用服務器上(誰來負責負載均衡)
用戶如果每次訪問到的服務器不一樣，那么如何維護
這里可以使用session入庫，達到session會話數據共享的目的。
那么此時，系統架構又會變成如下方式：
負載均衡又可以分為軟負載和硬負載。軟負載我們可以選擇Nginx、Apache等，硬負載我們可以選擇F5等。而session會話數據共享問題我們可以存儲在公共nosql，比如redis、memcached 。
六、數據庫主從復制、讀寫分離
系統架構演變到上面的階段，並不是終點。通過上面的設計，應用層的性能被我們拉上來了，但數據庫的負載也在逐漸增大，那如何去提高數據庫層面的性能呢？有了前面的設計思路以后，我們自然也會想到通過增加服務器來提高性能。但假如我們單純的把數據庫一分為二，然后對於數據庫的請求，分別負載到兩台數據庫服務器上，那必定會造成數據庫數據不統一的問題。 所以我們一般先考慮將數據庫主從復制或者讀寫分離，但是在讀寫分離的時候會有一些數據的延遲性，所以也並不是說所有場景都適合讀寫分離。
這個架構設計的變化會帶來如下幾個問題：
主從數據庫之間的數據需要同步(可以使用 mysql自帶的 master-slave 方式實現主從復制 )，主從模式最大的特點就是從機可以做一個備份，解決單點問題。
讀寫分離模式一般會有一些數據延遲性，根據業務場景選擇讀寫分離模式，需要能夠去接受一定的數據延遲的場景可以選擇讀寫分離來做到數據庫的高可用。
應用中需要根據業務進行對應數據源的選擇(采用第三方數據庫中間件，例如 mycat )
七、引入搜索引擎緩解讀庫的壓力
我們都知道數據庫常常對模糊查找效率不是很高，像電商類的網站，搜索是非常核心的功能，即使是做了讀寫分離，這個問題也不能得到有效解決。那么這個時候我們就需要引入搜索引擎了，使用搜索引擎能夠大大提升我們系統的查詢速度，比如es搜索引擎，但同時多了一些技術那么肯定也會帶來一些附加的問題，比如維護索引的構建、數據同步到搜索引擎等。
八、引入緩存機制緩解數據庫的壓力
然后又隨着訪問量的持續不斷增加，慢慢的我們的系統項目會出現許多用戶訪問同一內容的情況，比如秒殺活動，搶購活動等。那么對於這些熱點數據的訪問，沒必要每次都從數據庫重讀取，這時我們可以使用到緩存技術，比如 redis、memcache 來作為我們應用層的緩存。此外，在某些場景下，我們也需要對用戶的某些 IP 的訪問頻率做限制或者做黑白名單。那這個放內存中就又不合適，放數據庫又太麻煩了，那這個時候可以使用 Nosql 的方式比如 mongDB 來代替傳統的關系型數據庫。
九、數據庫水平/垂直拆分
我們的系統架構從單機演變到這個階段，交易、商品、用戶的數據都還在同一個數據庫中，盡管采取了增加緩存，主從、讀寫分離的方式，但是隨着數據庫的壓力持續增加，數據庫的瓶頸仍然是個最大的問題。因此我們可以考慮對數據的垂直拆分和水平拆分。
垂直拆分:把數據庫中不同業務數據拆分到不同的數據庫。
水平拆分:把同一個表中的數據拆分到兩個甚至更多的數據庫中，水平拆分的原因是某些業務數據量已經達到了單個數據庫的瓶頸，這時可以采取將表拆分到多個數據庫中。
十、服務應用的拆分
隨着業務的發展，業務量越來越大，應用的壓力越來越大。網站規模也越來越龐大。這個時候就可以考慮將應用拆分，按照領域模型將我們的用戶、商品、交易拆分成多個子系統。
這樣拆分以后，可能會有一些相同的代碼，比如用戶操作，在商品和交易都需要查詢，所以會導致每個系統都會有用戶查詢訪問相關操作。這樣就會產生代碼榮譽，就會造成很多系統資源的浪費，畢竟我們的資源也是很貴的。所以這些相同的操作一定是要抽取出來，否則就是一個很大的坑。所以我們可以通過走服務化路線的方式來解決。
那么服務拆分以后，各個服務之間如何進行遠程通信呢? 通過 RPC 技術，比較典型的有:webservice、http等等。前期通過這些技術能夠很好的解決各個服務之間通信問題，但是， 互聯網的發展是持續的，所以架構的演變和優化也還在持續。
十一、總結
這里我們通過一個電商網站的案例，我們了解到了分布式架構的發展演變過程，哪里有需求問題，哪里就會出現新的方案解決問題。都是通過業務量和訪問量的提升來考慮重構項目系統架項構設計，以便能夠適應當前的環境。不可一蹴而就，因為也要考慮到公司的發展和項目系統的設計成本，根據公司的發展可以考慮到項目未來的擴展性。