引言

　　昨天和剛入行就帶我的老領導相約北京酒吧，4年師徒情，7年未見，從老公司境況到老熟人的現狀，到現在的工作，未來的發展。從當下的技術到新技術的展望，聊到資料庫架構，我說我現在還是在做傳統的資料庫架構，而老領導滿心的分散式，好像不是分散式都是比較LOW了，這裡面依然存在著這樣一個問題，什麼是“分散式”，因為每個人說的都不一樣，理解的也都不一樣。

 　　而分散式又是怎樣一步一步演變的，不同情況下又該如何設計規劃自己的架構，文章篇幅有限內容太多，這裡只能粗淺的說一說啦。

------------------本文純屬個人觀點，如有錯誤、不足望指教----------------

架構的演變

　　架構演變一定是根據當時要求的場景、壓力下性能的需要、安全性、連續性的要求、技術的發展.....

　　我把架構的發展分為大概4個階段：

　　1.單機模式

 　　IT建設初期，高速建設階段，大家要做的只有一件事，我需要什麼構建什麼，我需要ERP我買軟體，需要HIS買HIS，這個時期按需構建大量的系統基本在這個時期產生，當然那個時候也沒什麼高可用的要求。

　　2.雙機熱備 和 鏡像

　　基本是20年前的技術了，在高速構建後，一堆的系統運行中，用戶發現我們的核心業務如果壞掉業務受影響，停機幾個小時做恢復 這是無法接受的，那麼雙機熱備或鏡像，Active-Standby的模式出現，這樣一臺機器工作，一臺備用壞了在短時間可以接管業務，造成的損失會低很多！

　　那麼問題也很明顯，備機資源浪費，依賴存儲，數據還是單點，成本較高。產品也很多：RoseHA/RoseMirrorHA、NEC ExpressCluster、微軟MSCS、Symantec VCS、Legato、RHCS 太多太多了。

　　隨後為瞭解決數據單點的問題有出現了 存儲的主備，存儲的雙活這廠商也太多了，這裡就不介紹了

　　基本上傳統企業依然停留在第一和第二階段，也就是要麼單機，要麼雙機熱備

　　3.節點多活 

　　隨著業務量越來越大，數據量不斷飈升，系統高效性的矛盾顯現出來，系統卡慢、報表、介面業務無法分離OLAP OLTP業務混合導致系統鎖情況嚴重，資源消耗極其龐大，光靠升級硬體已經無法滿足要求，橫向擴展已經成為大勢所趨。

　　同時切換時間、備機無法啟動的問題也困擾著用戶。

　　那麼節點多活，多台機器同時對外提供訪問的技術登上舞臺，代表的ORACLE RAC、微軟ALWAYSON 、MOEBIUS集群

　　多活的兩種模式也是從第二帶架構的演變

　　oracle rac 把雙機熱備的輔助節點變的可以訪問，關鍵點數據在多節點記憶體中的調配

　　Microsoft awo、Moebius 則是把鏡像的輔助節點變的可以訪問，關鍵點數據多節點同步

　　這樣橫向擴展來分擔壓力，並且可以在業務上進行分離。

　　 4.分散式架構 

 　　分散式架構真的不知道從何說起，概念太大，每個人理解的都不一樣，只能意會不能言傳：

　　比如說一份數據分開存成多份

　　比如說拆分，水平拆分、垂直拆分、分庫、分表、分業務

　　比如說....

　　其實說到底就是在第三代橫向擴展也無法滿足的情況下，繼續“拆”，根據不同需求各種“拆”，拆到什麼樣呢？ 大家都知道可以說最慢的環節在資料庫，傳統的做法複雜語句，大存儲過程運行非常慢，那我們就把這些拆到表數據量足夠小、語句足夠簡單、業務粒度小、訪問壓力儘量的小！

　　這樣細化的設計一切為業務服務，也是精細化設計產物，但這也存在一個問題，傳統企業在缺少高端人才，人力的情況下根本無法做到。現在的互聯網公司為業務的需要同時對IT團隊的大力建設，這是傳統企業根本無法達到的。

　　當然如果有第五代那也許可以說是雲，未來業務一切的技術都是雲端，雲端看不見摸不到，傳統行業人回歸業務，而IT 建設與管理也必然由專業的人做專業的事兒。

　　個人總結的架構演變，主架構演變不包含其他輔助技術，僅供參考

其他技術漫談

 　　在這四代架構之間也有很多技術出現，主要以數據複製、存儲同步為代表，如DG、OGG、LOGSHIPPING、Replication等等，這些都是不同場景下的數據複製，讓一個副本變成多個，基本目的在於副本讀或者本/異災備，而這些技術也在不同的場景中扮演這重要的角色，每種技術都有自己的優缺點，不能一概而論。

　　當然這裡面還包含現在所謂的虛擬化、超融合、存儲雙活，這些技術首先不是資料庫本身技術，在很多企業所謂資料庫的高可用中扮演著擦邊球的角色，虛擬化、超融合、存儲雙活都有自己適用的場景，而說到資料庫的架構，這些方案只是基礎架構層面。

如何選架構

• 　　選架構

　　首先你該選的是幾代架構？

　　四代架構是按照業務不斷細分，以冗餘 和 拆分、細化為主線大體過程

　　二代冗餘

　　三代粗拆分

　　四代細拆分

　　當然這是只是大概的意思，實際中拆分的場景，條件，擴展性一系列複雜的過程。

　　 我曾經無數次遇到幾十G的庫 幾百併發的應用就要規劃分片，領導最求高大上，底下技術人員叫苦。

• 　　構建

　　構建中主要是對建構的細節瞭解和熟練，這和企業的人員配置有很大的關係，傳統企業中很多在架構方案中選擇第三方產品？這是為什麼，構建需要專業的人，而企業最少的就是這部分人，而維護管理，責任劃分也是不得不考慮的事情。

　　當然架構越複雜投入的經歷也就越大，這也不是一個架構師可以主導的事情。

• 　　維護

　　維護才是關鍵，業務變動後的靈活性、壓力下的擴展性、出問題的排查、技術力量的支持，一系列漫長的過程開始了.....

題外篇

　　自己在傳統行業玩的太久了，寫這片文章的過程中也和PingCAP 聯合創始人& CTO 黃東旭，聊了一些未來技術的發展，tidb做的風聲水起，對未來資料庫大家都是未知，但隨著技術的不斷涌現更牛的架構，更牛的理念也必將一一實現。

　　比如依靠智能化的機制集群自我修複，性能自提升，架構自適應等等

總結

 　　架構方案是幾代不重要，重要的是適合自己的業務，保證穩定、安全、高效、持續，單機適合簡單業務，沒有那麼高的安全性、連續性依然可以，雙機熱備可以保障基本的高可用，節點多活的集群適合業務壓力較大簡單粗暴的分離和壓力分擔，至於分散式如果企業有能力有資源，業務壓力龐大自然會考慮，但在我接觸的客戶中太多認為自己業務只能通過分散式方案構建，但是其實只是簡單優化+三代多活，讀寫分離負載均衡即可滿足。

　　所以根據自己業務評估最為重要，一個好的架構規劃，不但解決現有問題節省成本，更會避免步子太大激進帶來的不必要損失。