微服務？數據庫？它們之間到底是啥關系？

過去幾年來，“微服務架構”這個術語持續火熱，它描述了一種將軟件應用程序設計為可獨立部署的服務套件的特定方式。盡管這種架構風格沒有確切的定義，但圍繞業務能力，自動化部署，網點智能以及語言和數據的分散控制等方面存在著某些共同特征。
簡而言之，微服務架構是一種將單應用程序作為一套小型服務開發的方法，每種應用程序都在其自己的進程中運行，并與輕量級機制（通常是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 數據庫報告的數據庫廠商。