簡介
作為一名架構師，我們要專業，要能看懂代碼，及時光著臂膀去機房，也能獨擋一面！及時同事搞不定問題，或者撂挑子，你也能給老大一個堅定的眼神：不怕，有我在！還能在會議室上滔滔不絕，如若無人，讓不懂技術的妹子看你時眼神迷離，就好想落霞與孤鶩齊飛！
分布式架構是一個非常複雜的體系，任何技術都不是孤立的存在，任何技術都無法適應所有場景。作為一名分布式系統架構或者資深研發人員，我們必須儘可能多的學習與之相關的各種知識，掌握各種技術的演進路線，正式從一名碼農蛻變成為架構師
什麼是分布式？
網際網路應用的特點是：高並發，海量數據。網際網路應用的用戶數是沒有上限的(取決於其開放特性)，這也是和傳統應用的本質區別。高並發指系統單位時間內收到的請求數量（取決於使用的用戶數），沒有上限。海量數據包括：海量數據的存儲和海量數據的處理。這兩個工程難題都可以使用分布式系統來解決。
簡單理解，分布式系統就是把一些計算機通過網絡連接起來，然後協同工作。協同工作需要解決兩個問題：
1）任務分解
把一個問題拆解成若干個獨立任務，每個任務在一臺節點上運行，實現多任務的並發執行。
2）節點通信
節點之間互相通信，需要設計特定的通信協議來實現。協議可以採用RPC或Message Queue等方式。
分布式和集群的關係
分布式：一個業務分拆多個子業務，部署在不同的伺服器上
集群：同一個業務，部署在多個伺服器上
計算機發展歷史
1946年情人節(2.14) , 世界上第一臺電子數字計算機誕生在美國賓夕法尼亞大學大學，它的名字是：ENIAC; 這臺計算機佔地170平米、重達30噸，每秒可進行5000次加法運算。第一臺電子計算機誕生以後，意味著一個日新月異的IT時代的到來。一方面單臺計算機的性能每年都在提升：從最早的8位CPU到現在的64位CPU；從早期的MB級內存到現在的GB級別內存；從慢速的機械存儲到現在的固態SSD硬碟存儲。
|
tips: 電子計算機的問世，最重要的奠基人是英國科學家艾蘭· 圖靈（Alan Turing）和美籍匈牙利科學家馮· 諾依曼（John Von· Neumann）。圖靈的貢獻是建立了圖靈機的理論模型，奠定了人工智慧的基礎。而馮· 諾依曼則是首先提出了計算機體系結構的設想。
經典理論-馮.諾依曼體系：計算機硬體由運算器、控制器、存儲器、輸入設備、輸出設備五大部分組成。直到今天，計算機仍沒有跳出該體系的範疇。
ENIAC之後，電子計算機便進入了IBM主導的大型機時代，IBM大型機之父吉恩.阿姆達爾被認為是有史以來最偉大的計算機設計師之一。1964年4月7日，在阿姆達爾的帶領下，歷時三年，耗費50億美元，第一臺IBM大型機SYSTEM/360誕生。這使得IBM在20實際50~60年代統治整個大型計算機工業，奠定了IBM計算機帝國的江山。2.1 IBM大型機曾支撐美國航天登月計劃
2.2 IBM主機一直服務於金融等核心行業的關鍵領域
由於高可靠性和超強的計算能力，幾遍在X86和雲計算飛速發展的情況下,IBM的大型機依然牢牢佔據著一定的高端市場份額
20世紀80年代，在大型機霸主的時代，計算機架構同時向兩個方向發展以X86 CPU為架構的價格便宜的面向個人的PC
以RISC CPU為架構的價格昂貴的面向企業的小型UNIX伺服器
分布式架構發展的裡程碑
大型主機的出現。憑藉著大型機超強的計算和I/O處理能力、穩定性、安全性等，在很長一段時間內，大型機引領了計算機行業及商業計算領域的發展。
而集中式的計算機系統架構也成為了主流。
隨著計算機的發展，這種架構越來越難以適應人們的需求，比如說
由於大型主機的複雜性，導致培養一個能夠熟練運維大型主機的人的成本很高大型主機很貴，一般只有土豪(政府、金融、電信)才能用得起單點問題，一臺大型主機出現故障，那麼整個系統將處於不可用狀態。而對於大型機的使用群體來說，這種不可用導致的損失是非常大的科技在進步，技術在進步。PC機性能不斷提升，很多企業放棄大型機改用小型機及普通PC來搭建系統架構阿里巴巴在2009年發起了一項"去IOE"運動
當初指的是IBM小型機、Oracle資料庫、EMC的高端存儲
2009年「去IOE」戰略透露，到2013年5月17日最後一臺IBM小型機在支付寶下線。
為什麼要去IOE?
阿里巴巴過去一直採用的是Oracle資料庫，並利用小型機和高端存儲設備提供高性能的數據處理和存儲服務。隨著業務的不斷發展，數據量和業務量呈爆發性增長，傳統的集中式Oracle資料庫架構在擴展性方面遭遇瓶頸。
傳統的商業資料庫軟體(Oracle,DB2)，多以集中式架構為主，這些傳統資料庫軟體的最大特點就是將所有的數據都集中在一個資料庫中，依靠大型高端設備來提供高處理能力和擴展性。集中式資料庫的擴展性主要採用向上擴展(Scale up)的方式，通過增加CPU，內存，磁碟等方式提高處理能力。這種集中式資料庫的架構，使得資料庫成為了整個系統的瓶頸，已經越來越不適應海量數據對計算能力的巨大需求
架構的發展演變過程
一個成熟的大型網站系統架構並不是一開始就設計的非常完美，也不是一開始就具備高性能、高可用、安全性等特性，而是隨著用戶量的增加、業務功能的擴展逐步完善演變過來的。在這個過程中，開發模式、技術架構等都會發生非常大的變化。而針對不同業務特徵的系統，會有各自的側重點，比如像淘寶這類的網站，要解決的是海量商品搜索、下單、支付等問題；像騰訊，要解決的是數億級別用戶的實時消息傳輸；百度所要解決的是海量數據的搜索。每一個種類的業務都有自己不同的系統架構。我們簡單模擬一個架構演變過程。
什麼是大型網站
如何定義一個網站是不是大型網站，一般我們會從兩個緯度去考衡，訪問量以及數據量，二者缺一不可。
我們以javaweb為例，來搭建一個簡單的電商系統，從這個系統中來看系統的演變歷史；要注意的是，接下來的演示模型，關注的是數據量、訪問量提升，網站結構發生的變化， 而不是具體關注業務功能點。其次，這個過程是為了讓大家更好的了解網站演進過程中的一些問題和應對策略。
假如我們系統具備以下功能：
用戶模塊：用戶註冊和管理
商品模塊：商品展示和管理
交易模塊：創建交易及支付結算
階段一 ， 單應用架構
網站的初期也可以認為是網際網路發展的早起，我們經常會在單機上跑我們所有的程序和軟體。
把所有軟體和應用都部署在一臺機器上，這樣就完成一個簡單系統的搭建，這個時候的講究的是效率
階段二，應用伺服器和資料庫伺服器分離
隨著網站的上線，訪問量逐步上升，伺服器的負載慢慢提高，在伺服器還沒有超載的時候，我們應該做好規劃，提升網站的負載能力。假如代碼層面的優化已經沒辦法繼續提高，在不提高單臺機器的性能，增加機器是一個比較好的方式，投入產出比非常高。這個階段增加機器的主要目的是講web伺服器和資料庫伺服器拆分，這樣不僅提高了單機的負載能力，也提高了容災能力
階段三，應用伺服器集群-應用伺服器負載告警，如何讓應用伺服器走向集群
隨著訪問量的繼續增加，單臺應用伺服器已經無法滿足需求。在假設資料庫伺服器還沒有遇到性能問題的時候，我們可以增加應用伺服器，通過應用伺服器集群將用戶請求分流到各個伺服器中，從而繼續提升負載能力。此時多臺應用伺服器之間沒有直接的交互，他們都是依賴資料庫各自對外提供服務
架構發展到這個階段，各種問題也會慢慢呈現
用戶請求由誰來轉發到具體的應用伺服器用戶如果每次訪問到的伺服器不一樣，那麼如何維護session
階段四，資料庫壓力變大，資料庫讀寫分離
架構演變到這裡，並不是終點。上面我們把應用層的性能拉上來了，但是資料庫的負載也在慢慢增大，那麼怎麼去提高資料庫層面的負載呢？有了前面的思路以後，自然會想到增加伺服器。但是假如我們單純的把資料庫一分為二，然後對於後續資料庫的請求，分別負載到兩臺資料庫伺服器上，那麼一定會造成資料庫不統一的問題。所以我們一般先考慮讀寫分離的方式
這個架構的變化會帶來幾個問題
主從資料庫之間的數據同步 ； 可以使用mysql自帶的master-slave方式實現主從複製對應數據源的選擇 ； 採用第三方資料庫中間件，例如mycat階段五，使用搜尋引擎緩解讀庫的壓力
資料庫做讀庫的話，嘗嘗對模糊查找效率不是特別好，像電商類的網站，搜索是非常核心的功能，即便是做了讀寫分離，這個問題也不能有效解決。那麼這個時候就需要引入搜尋引擎了
使用搜尋引擎能夠大大提高我們的查詢速度，但是同時也會帶來一些附加的問題，比如維護索引的構建。
階段六，引入緩存機制緩解資料庫的壓力
隨著訪問量的持續增加，逐漸出現許多用戶訪問統一部分內容的情況，對於這些熱點數據，沒必要每次都從資料庫去讀取，我們可以使用緩存技術，比如memcache、redis來作為我們應用層的緩存；另外在某些場景下，比如我們對用戶的某些IP的訪問頻率做限制，那這個放內存中又不合適，放資料庫又太麻煩，這個時候可以使用Nosql的方式比如mongDB來代替傳統的關係型資料庫
階段七，資料庫的水平/垂直拆分
我們的網站演進的變化過程，交易、商品、用戶的數據都還在同一個資料庫中，儘管採取了增加緩存，讀寫分離的方式，但是隨著資料庫的壓力持續增加，資料庫的瓶頸仍然是個最大的問題。因此我們可以考慮對數據的垂直拆分和水平拆分
垂直拆分：把資料庫中不同業務數據拆分到不同的資料庫
水平拆分：把同一個表中的數據拆分到兩個甚至跟多的資料庫中，水平拆分的原因是某些業務數據量已經達到了單個資料庫的瓶頸，這時可以採取講表拆分到多個資料庫中
階段八，應用的拆分
隨著業務的發展，業務越來越多，應用的壓力越來越大。工程規模也越來越龐大。這個時候就可以考慮講應用拆分，按照領域模型講我們的用戶、商品、交易拆分成多個子系統
這樣拆分以後，可能會有一些相同的代碼，比如用戶操作，在商品和交易都需要查詢，所以會導致每個系統都會有用戶查詢訪問相關操作。這些相同的操作一定是要抽象出來，否則就會是一個坑。所以通過走服務化路線的方式來解決
那麼服務拆分以後，各個服務之間如何進行遠程通信呢？
通過RPC技術，比較典型的有：webservice、hessian、http、RMI等等
前期通過這些技術能夠很好的解決各個服務之間通信問題，but，網際網路的發展是持續的，所以架構的演變和優化還在持續。
總結
我們通過這個例子來講解了電商網站的架構演進。我要強調一下，這個架構的演進不是某個網站真實的例子，實際上是通過這樣一個演進過程給大家帶來一個全局的觀念和感受。以及給大家在後續課程學習過程中的一些思路。
如何把單擊擴展到分布式
前面我們講到了馮.諾依曼模型，計算機一共由5個部分組成，從用戶角度來看，分布式系統就像一臺超級計算機。理論上也應該由輸入、輸出、運算、存儲和控制這5部分組成。
存儲器
在分布式系統中，我們需要把承擔存儲功能的多個節點組織在一起，組成一個整體的存儲器；比如資料庫、redis（key-value存儲）
如果覺得本文有用，動動小手點點關注吧！
Java的的架構師學習公眾號！
一個專注分享架構乾貨的微信公眾號
覺得本文有用就把文章分享給更多的人看到吧！