微服務？數據庫？它們之間究竟是啥關係？

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

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

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

微服務架構催生分佈式數據庫

王濤認爲，談論數據庫必定脫離不了應用。從應用程序開發來看，如今不少企業內部的應用開發都在從傳統中間件加數據庫的「煙囪式」開發，向微服務架構轉型。而在微服務體系架構中，幾乎每一個微服務都須要提供數據持久化的能力，而用戶也但願每一個微服務所承載的數據量可以無限的彈性擴張。可是，在採用微服務架構的過程當中，每一個微服務使用自身獨立的數據庫存儲又會使過去集中在一個地方的數據分散到不少不一樣的設備中，形成整個IT架構的數據嚴重碎片化。舉例來講，一些互聯網公司僅僅在生產系統中就維護着兩、三萬個MySQL數據庫，這樣的話，想要進行企業內部的數據整合是極爲困難的。

實際上，此前，當企業用戶採用微服務體系架構的時候，從數據管理的角度，業界有兩種作法。

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

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

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

打造適合微服務的分佈式數據庫

要打造適合微服務架構的數據庫，巨杉數據庫採用了計算存儲分離的架構。其中存儲層採用自研的原生分佈式數據庫引擎，上層計算層則能夠建立成百上千個數據庫實例，同時每一個數據庫實例對應用徹底透明，不需感知。

所以，在這種系統架構下，從單個應用來看，和傳統標準數據庫徹底一致，不需關注數據被切分在哪些不一樣物理設備上，作到彈性伸縮。同時，全部的物理設備從邏輯上進行統一管理，甚至不一樣實例裏面的數據能夠在可配置的權限下進行共享。

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

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

在對傳統技術的兼容方面來看，首先，必須支持ACID。由於從數據庫來看，儘管不少人說CAP不可兼得所以要犧牲一致性，但巨杉認爲這是不可取的。對於大部分公司來講，數據都是核心生命線，絕對不能爲了上分佈式犧牲數據的一致性和安全性，須要對用戶的財產和信息負責。所以，新型面向聯機交易的分佈式數據庫必須對傳統ACID有完美的支持，與傳統Oracle DB2的數據安全性一致性保持兼容。

其次，SQL的完整性。這個主要是從對傳統應用的兼容與開發人員能力重用的角度看。通常來講，SQL語法兼容的完整性，以及對已有標準的兼容必須具有，例如對MySQL、Oracle、DB二、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 數據庫報告的數據庫廠商。