微服務？資料庫？它們之間到底是啥關係？

過去幾年來，“微服務架構”這個術語持續火熱，它描述了一種將軟體應用程式設計為可獨立部署的服務套件的特定方式。儘管這種架構風格沒有確切的定義，但圍繞業務能力，自動化部署，網點智慧以及語言和資料的分散控制等方面存在著某些共同特徵。

簡而言之，微服務架構是一種將單應用程式作為一套小型服務開發的方法，每種應用程式都在其自己的程式中執行，並與輕量級機制（通常是HTTP資源的API）進行通訊。這些服務是圍繞業務功能構建的，可以通過全自動部署機制進行獨立部署。這些微服務的將集中化管理部分降到最少，同時，微服務還可以用不同的程式語言編寫，並使用不同的資料儲存技術。

而涉及到資料儲存技術，就不得不談到資料庫，而實際上，微服務和資料庫有著微妙的關係，微服務對於資料庫也有著和傳統架構不盡相同的需求，那麼，微服務和資料庫究竟有著什麼樣的關係？資料庫又對微服務有何影響？如何選擇適合微服務的資料庫？巨杉資料庫聯合創始人兼CTO王濤向CSDN的記者分享了他的觀點。

 

微服務架構催生分散式資料庫

王濤認為，談論資料庫一定脫離不了應用。從應用程式開發來看，現在很多企業內部的應用開發都在從傳統中介軟體加資料庫的“煙囪式”開發，向微服務架構轉型。而在微服務體系架構中，幾乎每個微服務都需要提供資料持久化的能力，而使用者也希望每個微服務所承載的資料量能夠無限的彈性擴張。但是，在採用微服務架構的過程中，每個微服務使用自身獨立的資料庫儲存又會使過去集中在一個地方的資料分散到很多不同的裝置中，造成整個IT架構的資料嚴重碎片化。舉例來說，一些網際網路公司僅僅在生產系統中就維護著兩、三萬個MySQL資料庫，這樣的話，想要進行企業內部的資料整合是極為困難的。

實際上，此前，當企業使用者採用微服務體系架構的時候，從資料管理的角度，業界有兩種做法。

第一種做法，就是對應用程式進行微服務改造，底層資料庫使用傳統集中式資料庫進行儲存。這種做法對於應用程式的改造相對較小，對於DBA運維人員來說學習成本也較低，但是相應的，其存在資料緊耦合，無法彈性擴張，以及可能存在單點故障等問題。

第二種做法，可能也是現在業界使用比較多的方式，就是每一組微服務對應一個獨立的小資料庫，往往使用MySQL或PostgreSQL。這種機制能夠解決集中式儲存的問題，但是也帶來了新的挑戰，包括資料極度碎片化，在微服務之間無法共享，運維成本極其高昂。

因此，兩種辦法都不能很好的解決微服務下資料儲存管理的問題，因此分散式資料庫就是要解決上述的兩個問題。第一就是針對每個微服務做到資料彈性擴張，第二就是對整個企業IT做到資料的統一治理從而避免碎片化儲存。

 

打造適合微服務的分散式資料庫

要打造適合微服務架構的資料庫，巨杉資料庫採用了計算儲存分離的架構。其中儲存層採用自研的原生分散式資料庫引擎，上層計算層則可以建立成百上千個資料庫例項，同時每個資料庫例項對應用完全透明，不需感知。

因此，在這種系統架構下，從單個應用來看，和傳統標準資料庫完全一致，不需關注資料被切分在哪些不同物理裝置上，做到彈性伸縮。同時，所有的物理裝置從邏輯上進行統一管理，甚至不同例項裡面的資料可以在可配置的許可權下進行共享。

那麼，適合微服務的分散式資料庫都應該具有哪些特性呢？王濤認為這主要應該從兩大維度、五個方面來看。

兩大維度一是對傳統技術的相容，二是技術和架構的創新。

在對傳統技術的相容方面來看，首先，必須支援ACID。因為從資料庫來看，儘管很多人說CAP不可兼得因此要犧牲一致性，但巨杉認為這是不可取的。對於大部分公司來說，資料都是核心生命線，絕對不能為了上分散式犧牲資料的一致性和安全性，需要對使用者的財產和資訊負責。因此，新型面向聯機交易的分散式資料庫必須對傳統ACID有完美的支援，與傳統Oracle DB2的資料安全性一致性保持相容。

其次，SQL的完整性。這個主要是從對傳統應用的相容與開發人員能力重用的角度看。一般來說，SQL語法相容的完整性，以及對已有標準的相容必須具備，例如對MySQL、Oracle、DB2、PostgreSQL這種主流協議的相容。

而從新技術的前瞻性來看，首先，未來是私有云和微服務應用的時代，那麼作為分散式資料庫，就不僅僅簡單的將其定位成過去某一個資料庫的替代。分散式資料庫的核心價值在於，能夠從資料庫的層面以服務資源池的形式，向上層被從煙囪式架構向微服務架構拆散的成百上千個小服務提供資料庫訪問能力的平臺。在這個定位下，資料庫資源池在保證與傳統資料庫100%相容的基礎上，必須滿足分散式彈性擴張，當資源池裡面空間和計算能力不足時，需要通過動態增加計算儲存節點的方式進行擴容。

其次，過去的資料庫由於僅針對某一個特定應用，採用中介軟體和資料庫一對一繫結的方式，因此只需要提供自身一種模式的訪問就夠了。但是當進行資料庫資源池化的時候，上層應用自然面對來自不同開發商、不同業務型別、不同SLA級別的服務，大家採用的開發流程、SQL標準、以及安全策略各不相同，因此分散式資料庫必須能夠支援多種模式的訪問介面。

最後，HTAP，即交易分析混合處理能力。譬如一些賬務資料，可能最核心的關鍵應用來自於聯機交易業務實時使用這些資料，但是同時一些後臺的實時報表，或者安全審計機構需要進行統計分析的時候，來自不同微服務的業務可能需要對同一份資料同時以交易和分析的方式進行訪問。這種情況下，能不能在資源池內對交易與分析業務進行物理資源隔離，及時對同一份資料同時訪問並可以做到互不干擾尤為關鍵，因此，適合微服務的資料庫必須具有較強的交易分析混合處理能力。

 

巨杉資料庫，適合微服務的分散式資料庫

正如同巨杉對於分散式資料庫的技術定位和目標，巨杉資料庫SequoiaDB本身就是以分散式儲存底座與上層的資料庫例項兩層來進行構建的。底層的分散式儲存作為資源池，自身負責資料的儲存、分散式事務控制、記錄和表鎖等，都在底層原生分散式儲存實現。

資料庫例項層則提供對上層應用程式的SQL服務，使用者可以建立MySQL、PostgreSQL、Spark SQL等結構化例項，也可以建立JSON或S3檔案系統的非結構化例項。每個例項中的資料對上層應用來說完全透明。因此，在SequoiaDB中，一個MySQL表可以輕易儲存十億甚至百億級別的資料，開發者在寫SQL的時候完全不需要關注底層表到底被分散在多少臺物理裝置中。

作為業界原生分散式資料庫以及新一代分散式資料庫的代表，SequoiaDB對於分散式交易與ACID與傳統技術完全相容，架構與功能特性與傳統資料庫完全相容。同時，SequoiaDB還積極擁抱新一代微服務與雲端計算框架，在面向微服務應用開發與雲端計算基礎架構時，支援彈性擴張、資源隔離、多租戶、可配置一致性、多模式（支援各類SQL協議）、叢集內可配置容災策略等一系列功能。

事實上，傳統單點資料庫的容量瓶頸，僅僅是分散式資料庫所解決的問題之一。更重要的是在未來微服務化應用開發以及雲化平臺的趨勢下，應用不再以“煙囪式”的中介軟體加資料庫模式進行構建，而是採用數千甚至上萬的微服務程式構建成的複雜網狀模型。因此，分散式資料庫需要能夠滿足上層應用的彈性擴充套件、高併發、高吞吐量、與靈活敏捷的需求。而SequoiaDB在這些方面都有著出色的表現，包括：

完整的ACID支援，事務和一致性保證；SQL的完整支援，傳統資料庫MySQL/PostgreSQL的語法完全相容。分散式與擴充套件性，應對資料量的變化，實現儲存層和計算層的彈性擴充套件；多模式訪問介面，支援多型別資料管理和多種模式的訪問介面； HTAP交易/分析混合處理能力，複雜業務需求下，實現資料的物理隔離，互不干擾。

 

而在此次大會最新發布的 3.2版本中，巨杉通對SequoiaDB進行大幅度效能優化與提升，使得其在分散式的交易型業務下，整體效能提升2~3倍，CPU消耗節省超過30%，從而大大提升了對微服務的支援力度。

 

SequoiaDB ，不僅僅是支援微服務而已

實際上，SequoiaDB 並不僅僅是微服務的“良師益友”，其更大維度下的定位是一款真正的金融級分散式關係型資料庫。

巨杉資料庫目前在企業級應用場景主要包括分散式線上交易、資料中臺以及分散式內容管理。

線上交易是資料庫最廣泛應用的場景之一，通常用來支撐核心業務運營。分散式線上交易資料庫核心業務價值包括，分散式架構轉型，高併發、高處理能力，業務持續擴充套件能力以及自主可控與資料安全要求。SequoiaDB儲存引擎採用原生分散式架構，擴充套件便捷；完整支援分散式事務、強一致多副本高可用；無單點故障，資料庫引擎原生支援多中心容災。

資料中臺是當前十分火熱的概念，資料中臺在企業微服務架構中的角色十分重要，像齒輪一樣連通上層快速迭代的微服務應用和下層基礎架構，同時還可以提供全量資料的實時線上服務，泛指傳統核心交易以外的所有對外服務業務，基於SequoiaDB構建的資料中臺核心業務價值包括：資料高效能實時訪問，海量資料全生命週期線上，業務持續擴充套件能力。

內容管理平臺為企業提供儲存、管理和使用海量非結構化資料能力。常見應用包括影像平臺、文件管理平臺、音視訊雙錄系統等。基於SequoiaDB搭建的內容管理平臺的核心業務價值包括，海量非結構化資料管理和實時訪問，豐富的內容管理功能，海量非結構化資料全生命週期線上以及業務持續擴充套件能力。

據悉，目前巨杉資料庫已在近百家大型商業銀行核心生產業務上線，並廣泛應用於金融、電信、政府、網際網路、交通等領域，企業使用者總數超過1000家。同時，巨杉也是中國首家連續兩年入選Gartner 資料庫報告的資料庫廠商。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31534344/viewspace-2644650/，如需轉載，請註明出處，否則將追究法律責任。