最近開始接觸分布式，就寫下自己學到筆記整理。學自咕泡學院。
分布式架構的常見概念
單機：一台伺服器處理整個項目所有的服務。
例：一個飯店有一個廚師，這個廚師負責切菜炒菜全幹。
叢集：把單機複制到多個伺服器，多個伺服器互相不依賴的為項目提供服務。
例：後來客人多了，一個廚師忙不過來，又請來了一個或者2個廚師，這些廚師都幹一樣的活就是切菜炒菜。這些廚師的關系是叢集。
分布式：多個服務互相依賴共同為項目提供服務，每個伺服器隻為項目中其中一個功能提供服務。
例如：為了讓廚師專心炒菜，把菜做到極緻，又請了個配菜師負責切 菜，備菜，備料，廚師和配菜師的關系是分布 式，一個配菜師 也忙不過來了，又請了個配菜師，兩個配菜師關系是叢集。
架構的發展過程
一個成熟的大型網站系統架構并不是一開始就設計的非常完 美，也不是一開始就具備高性能、高可用、安全性等特性，而 是随着使用者量的增加、業務功能的擴充逐漸完善演變過來的。
我們簡單模拟一個架構演變過程。 我們以javaweb為例，來搭建一個簡單的電商系統，從這個系 統中來看系統的演變曆史；要注意的是，接下來的示範模型， 關注的是資料量、通路量提升，網站結構發生的變化， 而不是 具體關注業務功能點。
假如我們系統具備以下功能： 使用者子產品：使用者注冊和管理 商品子產品：商品展示和管理 交易子產品：建立交易及支付結算
階段一：單應用架構
網站的初期，我們經常會在單機上跑我們所有的程式和軟體。 把所有軟體和應用都部署在一台機器上，這樣就完成一個簡單 系統的搭建，這個時候的講究的是效率。
階段二：應用伺服器和資料庫伺服器分離
随着業務發展，通路量的逐漸上升，伺服器的複制慢慢提高。這個時候一台伺服器已經沒辦法滿足正常的使用者通路。加入代碼層面的優化沒有辦法繼續提高，在不提高單台伺服器的性能的情況下是一個比較好的方式。
這個階段增加伺服器的主要目的就是将wen伺服器和資料庫伺服器拆分，這樣不僅能提高單台伺服器的負載能力，也提高了容災能力。
階段三：應用伺服器叢集
随着通路量的繼續增加，單台應用伺服器已經無法滿足需求。在假設資料伺服器還沒有遇到性能問題的時候，我們可以增加應用伺服器，通過應用伺服器叢集來把使用者的請求分流到各個伺服器中，進而繼續提升負載能力，此時多台應用伺服器之間沒 有直接的互動，他們都是依賴資料庫各自對外提供服務。
架構發展到這個階段，各種問題也會慢慢呈現
1. 使用者請求由誰來轉發到具體的應用伺服器
2. 使用者如果每次通路到的伺服器不一樣，那麼如何維護 session
階段四：資料庫壓力變大，資料庫讀寫分離
應用伺服器的提升帶來的問題就是資料庫的負載也在慢慢變大，如何來提高資料庫的負載呢？既然一台資料庫伺服器不行，那就增加伺服器。但是假如我 們單純的把資料庫一分為二，然後對于後續資料庫的請求，分别負 載到兩台資料庫伺服器上，那麼一定會造成資料庫不統一的問題。 是以我們一般先考慮讀寫分離的方式。因為應用中百分之80的情況是在讀資料，隻有百分之20在寫資料。
這個架構的變化會帶來幾個問題 ：
1. 主從資料庫之間的資料同步 ； 可以使用 mysql 自帶的 master-slave方式實作主從複制
2. 對應資料源的選擇 ； 采用第三方資料庫中間件，例如mycat
階段五：使用搜尋引擎緩解讀庫的壓力
資料庫做讀庫的話，嘗嘗對模糊查找效率不是特别好，像電商類的 網站，搜尋是非常核心的功能，即便是做了讀寫分離，這個問題也 不能有效解決。那麼這個時候就需要引入搜尋引擎了 使用搜尋引擎能夠大大提高我們的查詢速度，但是同時也會帶來一 些附加的問題，比如維護索引的建構。
階段六：引入緩存機制緩解資料庫的壓力
随着通路量的持續增加，逐漸出現許多使用者通路統一部分内容的情 況，對于這些熱點資料，沒必要每次都從資料庫去讀取，我們可以 使用緩存技術，比如memcache、redis來作為我們應用層的緩存； 另外在某些場景下，比如我們對使用者的某些IP的通路頻率做限制， 那這個放記憶體中又不合适，放資料庫又太麻煩，這個時候可以使用 Nosql的方式比如mongDB來代替傳統的關系型資料庫
階段七：資料庫的水準/垂直拆分
我們的網站演進的變化過程，交易、商品、使用者的資料都還在同一 個資料庫中，盡管采取了增加緩存，讀寫分離的方式，但是随着數 據庫的壓力持續增加，資料庫的瓶頸仍然是個最大的問題。是以我 們可以考慮對資料的垂直拆分和水準拆分
垂直拆分：把資料庫中不同業務資料拆分到不同的資料庫
水準拆分：把同一個表中的資料拆分到兩個甚至跟多的資料庫中， 水準拆分的原因是某些業務資料量已經達到了單個資料庫的瓶頸， 這時可以采取講表拆分到多個資料庫中
階段八：應用的拆分
随着業務的發展，業務越來越多，應用的壓力越來越大。工程規模 也越來越龐大。這個時候就可以考慮講應用拆分，按照領域模型講 我們的使用者、商品、交易拆分成多個子系統
這樣拆分以後，可能會有一些相同的代碼，比如使用者操作，在商品 和交易都需要查詢，是以會導緻每個系統都會有使用者查詢通路相關 操作。這些相同的操作一定是要抽象出來，否則就會是一個坑。所 以通過走服務化路線的方式來解決 。
那麼服務拆分以後，各個服務之間如何進行遠端通信呢？ 通過RPC技術，比較典型的有：webservice、hessian、http、RMI 等等 前期通過這些技術能夠很好的解決各個服務之間通信問題，but， 網際網路的發展是持續的，是以架構的演變和優化還在持續。
學自咕泡學院。