ApacheShardingSphere數(shù)據(jù)脫敏全解決方案-創(chuàng)新互聯(lián)

Apache ShardingSphere數(shù)據(jù)脫敏全解決方案詳解

成都創(chuàng)新互聯(lián)是專業(yè)的鳳翔網(wǎng)站建設公司，鳳翔接單;提供成都做網(wǎng)站、網(wǎng)站建設,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行鳳翔網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

作者簡介

潘娟，京東數(shù)科高級DBA，主要負責京東數(shù)科數(shù)據(jù)庫中間件開發(fā)、數(shù)據(jù)庫運維自動化平臺開發(fā)、生產(chǎn)數(shù)據(jù)庫運維工作。多次參與京東6.18、11.11等大促活動的護航工作。曾負責京東數(shù)科數(shù)據(jù)庫自動化平臺設計與開發(fā)項目，現(xiàn)專注于Apache ShardingSphere分布式數(shù)據(jù)庫中間件開發(fā)。樂于在數(shù)據(jù)庫、自動化、分布式、中間件等相關領域進行學習和探索。

一、背景

安全控制一直是治理的重要環(huán)節(jié)，數(shù)據(jù)脫敏屬于安全控制的范疇。對互聯(lián)網(wǎng)公司、傳統(tǒng)行業(yè)來說，數(shù)據(jù)安全一直是極為重視和敏感的話題。數(shù)據(jù)脫敏是指對某些敏感信息通過脫敏規(guī)則進行數(shù)據(jù)的變形，實現(xiàn)敏感隱私數(shù)據(jù)的可靠保護。涉及客戶安全數(shù)據(jù)或者一些商業(yè)性敏感數(shù)據(jù)，如手機號、卡號、客戶號等個人信息按照相關部門規(guī)定，都需要進行數(shù)據(jù)脫敏。

在真實業(yè)務場景中，相關業(yè)務開發(fā)團隊則往往需要針對公司安全部門需求，自行實行并維護一套加解密系統(tǒng)，而當脫敏場景發(fā)生改變時，自行維護的脫敏系統(tǒng)往往又面臨著重構(gòu)或修改風險。此外，對于已經(jīng)上線的業(yè)務，如何在不修改業(yè)務邏輯、業(yè)務SQL的情況下，透明化、安全低風險地實現(xiàn)無縫進行脫敏改造呢？

Apache ShardingSphere根據(jù)業(yè)界對脫敏的需求及業(yè)務改造痛點，提供了一套完整、安全、透明化、低改造成本的數(shù)據(jù)脫敏整合解決方案。

二、前序

Apache ShardingSphere是一套開源的分布式數(shù)據(jù)庫中間件解決方案組成的生態(tài)圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（規(guī)劃中）這3款相互獨立，卻又能夠混合部署配合使用的產(chǎn)品組成。它們均能夠提供標準化的數(shù)據(jù)分片、分布式事務和分布式治理功能，可適用于如Java同構(gòu)、異構(gòu)語言、容器、云原生等各種多樣化的應用場景。

數(shù)據(jù)脫敏模塊屬于ShardingSphere分布式治理這一核心功能下的子功能模塊。它通過對用戶輸入的SQL進行解析，并依據(jù)用戶提供的脫敏配置對SQL進行改寫，從而實現(xiàn)對原文數(shù)據(jù)進行加密，并將原文數(shù)據(jù)(可選)及密文數(shù)據(jù)同時存儲到底層數(shù)據(jù)庫。在用戶查詢數(shù)據(jù)時，它又從數(shù)據(jù)庫中取出密文數(shù)據(jù)，并對其解密，最終將解密后的原始數(shù)據(jù)返回給用戶。Apache ShardingSphere分布式數(shù)據(jù)庫中間件自動化&透明化了數(shù)據(jù)脫敏過程，讓用戶無需關注數(shù)據(jù)脫敏的實現(xiàn)細節(jié)，像使用普通數(shù)據(jù)那樣使用脫敏數(shù)據(jù)。此外，無論是已在線業(yè)務進行脫敏改造，還是新上線業(yè)務使用脫敏功能，ShardingSphere都可以提供一套相對完善的解決方案。

三、需求場景分析

對于數(shù)據(jù)脫敏的需求，在現(xiàn)實的業(yè)務場景中一般分為兩種情況：

1. 新業(yè)務上線，安全部門規(guī)定需將涉及用戶敏感信息，例如銀行、手機號碼等進行加密后存儲到數(shù)據(jù)庫，在使用的時候再進行解密處理。因為是全新系統(tǒng)，因而沒有存量數(shù)據(jù)清洗問題，所以實現(xiàn)相對簡單。

2. 已上線業(yè)務，之前一直將明文存儲在數(shù)據(jù)庫中。相關部門突然需要對已上線業(yè)務進行脫敏整改。這種場景一般需要處理三個問題：

   a) 歷史數(shù)據(jù)需要如何進行脫敏處理，即洗數(shù)。

   b) 如何能在不改動業(yè)務SQL和邏輯情況下，將新增數(shù)據(jù)進行脫敏處理，并存儲到數(shù)據(jù)庫；在使用時，再進行解密取出。

   c) 如何較為安全、無縫、透明化地實現(xiàn)業(yè)務系統(tǒng)在明文與密文數(shù)據(jù)間的遷移。

四、處理流程詳解

整體架構(gòu)

ShardingSphere提供的Encrypt-JDBC和業(yè)務代碼部署在一起。業(yè)務方需面向Encrypt-JDBC進行JDBC編程。由于Encrypt-JDBC實現(xiàn)所有JDBC標準接口，業(yè)務代碼無需做額外改造即可兼容使用。此時，業(yè)務代碼所有與數(shù)據(jù)庫的交互行為交由Encrypt-JDBC負責。業(yè)務只需提供脫敏規(guī)則即可。作為業(yè)務代碼與底層數(shù)據(jù)庫中間的橋梁，Encrypt-JDBC便可攔截用戶行為，并在改造行為后與數(shù)據(jù)庫交互。

Encrypt-JDBC將用戶發(fā)起的SQL進行攔截，并通過SQL語法解析器進行解析、理解SQL行為，再依據(jù)用戶傳入的脫敏規(guī)則，找出需要脫敏的字段和所使用的加解密器對目標字段進行加解密處理后，再與底層數(shù)據(jù)庫進行交互。

ShardingSphere會將用戶請求的明文進行加密后存儲到底層數(shù)據(jù)庫；并在用戶查詢時，將密文從數(shù)據(jù)庫中取出進行解密后返回給終端用戶。

ShardingSphere通過屏蔽對數(shù)據(jù)的脫敏處理，使用戶無需感知解析SQL、數(shù)據(jù)加密、數(shù)據(jù)解密的處理過程，就像在使用普通數(shù)據(jù)一樣使用脫敏數(shù)據(jù)。

脫敏規(guī)則

在詳解整套流程之前，我們需要先了解下脫敏規(guī)則與配置，這是認識整套流程的基礎。脫敏配置主要分為四部分：數(shù)據(jù)源配置，加密器配置，脫敏表配置以及查詢屬性配置，其詳情如下圖所示：

數(shù)據(jù)源配置：是指DataSource的配置。

加密器配置：是指使用什么加密策略進行加解密。目前ShardingSphere內(nèi)置了兩種加解密策略：AES/MD5。用戶還可以通過實現(xiàn)ShardingSphere提供的接口，自行實現(xiàn)一套加解密算法。

脫敏表配置：用于告訴ShardingSphere數(shù)據(jù)表里哪個列用于存儲密文數(shù)據(jù)（cipherColumn）、哪個列用于存儲明文數(shù)據(jù)（plainColumn）以及用戶想使用哪個列進行SQL編寫（logicColumn）。

如何理解用戶想使用哪個列進行SQL編寫（logicColumn）？

我們可以從Encrypt-JDBC存在的意義來理解。Encrypt-JDBC最終目的是希望屏蔽底層對數(shù)據(jù)的脫敏處理，也就是說我們不希望用戶知道數(shù)據(jù)是如何被加解密的、如何將明文數(shù)據(jù)存儲到plainColumn，將密文數(shù)據(jù)存儲到cipherColumn。換句話說，我們不希望用戶知道plainColumn和cipherColumn的存在和使用。所以，我們需要給用戶提供一個概念意義上的列，這個列可以脫離底層數(shù)據(jù)庫的真實列，它可以是數(shù)據(jù)庫表里的一個真實列，也可以不是，從而使得用戶可以隨意改變底層數(shù)據(jù)庫的plainColumn和cipherColumn的列名。或者刪除plainColumn，選擇永遠不再存儲明文，只存儲密文。只要用戶的SQL面向這個邏輯列進行編寫，并在脫敏規(guī)則里給出logicColumn和plainColumn、cipherColumn之間正確的映射關系即可。

為什么要這么做呢？答案在文章后面，即為了讓已上線的業(yè)務能無縫、透明、安全地進行數(shù)據(jù)脫敏遷移。

查詢屬性的配置：當?shù)讓訑?shù)據(jù)庫表里同時存儲了明文數(shù)據(jù)、密文數(shù)據(jù)后，該屬性開關用于決定是直接查詢數(shù)據(jù)庫表里的明文數(shù)據(jù)進行返回，還是查詢密文數(shù)據(jù)通過Encrypt-JDBC解密后返回。

脫敏處理過程

舉個栗子，假如數(shù)據(jù)庫里有一張表叫做t_user，這張表里實際有兩個字段pwd_plain，用于存放明文數(shù)據(jù)、pwd_cipher，用于存放密文數(shù)據(jù)，同時定義logicColumn為pwd。那么，用戶在編寫SQL時應該面向logicColumn進行編寫，即INSERT INTO t_user SET pwd = '123'。ShardingSphere接收到該SQL，通過用戶提供的脫敏配置，發(fā)現(xiàn)pwd是logicColumn，于是便對邏輯列及其對應的明文數(shù)據(jù)進行脫敏處理?？梢钥闯鯯hardingSphere將面向用戶的邏輯列與面向底層數(shù)據(jù)庫的明文列和密文列進行了列名以及數(shù)據(jù)的脫敏映射轉(zhuǎn)換。如下圖所示：

這也正是Encrypt-JDBC核心意義所在，即依據(jù)用戶提供的脫敏規(guī)則，將用戶SQL與底層數(shù)據(jù)表結(jié)構(gòu)割裂開來，使得用戶的SQL編寫不再依賴于真實的數(shù)據(jù)庫表結(jié)構(gòu)。而用戶與底層數(shù)據(jù)庫之間的銜接、映射、轉(zhuǎn)換交由ShardingSphere進行處理。為什么我們要這么做？還是那句話：為了讓已上線的業(yè)務能無縫、透明、安全地進行數(shù)據(jù)脫敏遷移。

為了讓讀者更清晰了解到Encrypt-JDBC的核心處理流程，下方圖片展示了使用Encrypt-JDBC進行增刪改查時，其中的處理流程和轉(zhuǎn)換邏輯，如下圖所示。

五、解決方案詳解

在了解了ShardingSphere脫敏處理流程后，即可將脫敏配置、脫敏處理流程與實際場景進行結(jié)合。所有的設計開發(fā)都是為了解決業(yè)務場景遇到的痛點。那么面對之前提到的業(yè)務場景需求，又應該如何使用ShardingSphere這把利器來滿足業(yè)務需求呢？

新上線業(yè)務

業(yè)務場景分析：新上線業(yè)務由于一切從零開始，不存在歷史數(shù)據(jù)清洗問題，所以相對簡單。

解決方案說明：選擇合適的加密器，如AES后，只需配置邏輯列（面向用戶編寫SQL）和密文列（數(shù)據(jù)表存密文數(shù)據(jù)）即可，邏輯列和密文列可以相同也可以不同。建議配置如下（Yaml格式展示）：

encryptRule:
??encryptors:
????aes_encryptor:??????type:?aes
??????props:
????????aes.key.value:?123456abc
??tables:
????t_user:
??????columns:????????pwd:
??????????cipherColumn:?pwd
??????????encryptor:?aes_encryptor

使用這套配置，Encrypt-JDBC只需將logicColumn和cipherColumn進行轉(zhuǎn)換，底層數(shù)據(jù)表不存儲明文，只存儲了密文，這也是安全審計部分的要求所在。如果用戶希望將明文、密文一同存儲到數(shù)據(jù)庫，只需添加plainColumn配置即可。整體處理流程如下圖所示：

已上線業(yè)務改造

業(yè)務場景分析：由于業(yè)務已經(jīng)在線上運行，數(shù)據(jù)庫里必然存有大量明文歷史數(shù)據(jù)。現(xiàn)在的問題是如何讓歷史數(shù)據(jù)得以加密清洗、如何讓增量數(shù)據(jù)得以加密處理、如何讓業(yè)務在新舊兩套數(shù)據(jù)系統(tǒng)之間進行無縫、透明化遷移。

解決方案說明：在提供解決方案之前，我們先來頭腦風暴一下：首先，既然是舊業(yè)務需要進行脫敏改造，那一定存儲了非常重要且敏感的信息。這些信息含金量高且業(yè)務相對基礎重要。如果搞錯了，整個團隊KPI就再見了。所以不可能一上來就停業(yè)務，禁止新數(shù)據(jù)寫入，再找個加密器把歷史數(shù)據(jù)全部加密清洗，再把之前重構(gòu)的代碼部署上線，使其能把存量和增量數(shù)據(jù)進行在線加密解密。如此簡單粗暴的方式，按照歷史經(jīng)驗來談，一定涼涼。

那么另一種相對安全的做法是：重新搭建一套和生產(chǎn)環(huán)境一模一樣的預發(fā)環(huán)境，然后通過相關遷移洗數(shù)工具把生產(chǎn)環(huán)境的存量原文數(shù)據(jù)加密后存儲到預發(fā)環(huán)境，而新增數(shù)據(jù)則通過例如MySQL主從復制及業(yè)務方自行開發(fā)的工具加密后存儲到預發(fā)環(huán)境的數(shù)據(jù)庫里，再把重構(gòu)后可以進行加解密的代碼部署到預發(fā)環(huán)境。這樣生產(chǎn)環(huán)境是一套以明文為核心的查詢修改的環(huán)境；預發(fā)環(huán)境是一套以密文為核心加解密查詢修改的環(huán)境。在對比一段時間無誤后，可以夜間操作將生產(chǎn)流量切到預發(fā)環(huán)境中。此方案相對安全可靠，只是時間、人力、資金、成本較高，主要包括：預發(fā)環(huán)境搭建、生產(chǎn)代碼整改、相關輔助工具開發(fā)等。除非無路可走，否則業(yè)務開發(fā)人員一般是從入門到放棄。

業(yè)務開發(fā)人員最希望的做法是：減少資金費用的承擔、最好不要修改業(yè)務代碼、能夠安全平滑遷移系統(tǒng)。于是，ShardingSphere的脫敏功能模塊便應用而生?？煞譃槿竭M行：

1. 系統(tǒng)遷移前

   假設系統(tǒng)需要對t_user的pwd字段進行脫敏處理，業(yè)務方使用Encrypt-JDBC來代替標準化的JDBC接口，此舉基本不需要額外改造（我們還提供了SpringBoot，SpringNameSpace，Yaml等接入方式，滿足不同業(yè)務方需求）。另外，提供一套脫敏配置規(guī)則，如下所示：

   encryptRule:??encryptors:????aes_encryptor:??????type:?aes
   ??????props:????????aes.key.value:?123456abc
   ??tables:????t_user:??????columns:????????pwd:??????????plainColumn:?pwd
   ??????????cipherColumn:?pwd_cipher
   ??????????encryptor:?aes_encryptorprops:????query.with.cipher.column:?false

   依據(jù)上述脫敏規(guī)則可知，首先需要在數(shù)據(jù)庫表t_user里新增一個字段叫做pwd_cipher，即cipherColumn，用于存放密文數(shù)據(jù)，同時我們把plainColumn設置為pwd，用于存放明文數(shù)據(jù)，而把logicColumn也設置為pwd。由于之前的代碼SQL就是使用pwd進行編寫，即面向邏輯列進行SQL編寫，所以業(yè)務代碼無需改動。通過Encrypt-JDBC，針對新增的數(shù)據(jù)，會把明文寫到pwd列，并同時把明文進行加密存儲到pwd_cipher列。此時，由于query.with.cipher.column設置為false，對業(yè)務應用來說，依舊使用pwd這一明文列進行查詢存儲，卻在底層數(shù)據(jù)庫表pwd_cipher上額外存儲了新增數(shù)據(jù)的密文數(shù)據(jù)，其處理流程如下圖所示：

   

   新增數(shù)據(jù)在插入時，就通過Encrypt-JDBC加密為密文數(shù)據(jù)，并被存儲到了cipherColumn。而現(xiàn)在就需要處理歷史明文存量數(shù)據(jù)。由于Apache ShardingSphere目前并未提供相關遷移洗數(shù)工具，此時需要業(yè)務方自行將pwd中的明文數(shù)據(jù)進行加密處理存儲到pwd_cipher。

2. 系統(tǒng)遷移中

   新增的數(shù)據(jù)已被Encrypt-JDBC將密文存儲到密文列，明文存儲到明文列；歷史數(shù)據(jù)被業(yè)務方自行加密清洗后，將密文也存儲到密文列。也就是說現(xiàn)在的數(shù)據(jù)庫里即存放著明文也存放著密文，只是由于配置項中的query.with.cipher.column=false，所以密文一直沒有被使用過?，F(xiàn)在我們?yōu)榱俗屜到y(tǒng)能切到密文數(shù)據(jù)進行查詢，需要將脫敏配置中的query.with.cipher.column設置為true。在重啟系統(tǒng)后，我們發(fā)現(xiàn)系統(tǒng)業(yè)務一切正常，但是Encrypt-JDBC已經(jīng)開始從數(shù)據(jù)庫里取出密文列的數(shù)據(jù)，解密后返回給用戶；而對于用戶的增刪改需求，則依舊會把原文數(shù)據(jù)存儲到明文列，加密后密文數(shù)據(jù)存儲到密文列。

   雖然現(xiàn)在業(yè)務系統(tǒng)通過將密文列的數(shù)據(jù)取出，解密后返回；但是，在存儲的時候仍舊會存一份原文數(shù)據(jù)到明文列，這是為什么呢？答案是：為了能夠進行系統(tǒng)回滾。因為只要密文和明文永遠同時存在，我們就可以通過開關項配置自由將業(yè)務查詢切換到cipherColumn或plainColumn。也就是說，如果將系統(tǒng)切到密文列進行查詢時，發(fā)現(xiàn)系統(tǒng)報錯，需要回滾。那么只需將query.with.cipher.column=false，Encrypt-JDBC將會還原，即又重新開始使用plainColumn進行查詢。處理流程如下圖所示：

   

3. 系統(tǒng)遷移后

   由于安全審計部門要求，業(yè)務系統(tǒng)一般不可能讓數(shù)據(jù)庫的明文列和密文列永久同步保留，我們需要在系統(tǒng)穩(wěn)定后將明文列數(shù)據(jù)刪除。即我們需要在系統(tǒng)遷移后將plainColumn，即pwd進行刪除。那問題來了，現(xiàn)在業(yè)務代碼都是面向pwd進行編寫SQL的，把底層數(shù)據(jù)表中的存放明文的pwd刪除了，換用pwd_cipher進行解密得到原文數(shù)據(jù)，那豈不是意味著業(yè)務方需要整改所有SQL，從而不使用即將要被刪除的pwd列？還記得我們Encrypt-JDBC的核心意義所在嗎？

   這也正是Encrypt-JDBC核心意義所在，即依據(jù)用戶提供的脫敏規(guī)則，將用戶SQL與底層數(shù)據(jù)庫表結(jié)構(gòu)割裂開來，使得用戶的SQL編寫不再依賴于真實的數(shù)據(jù)庫表結(jié)構(gòu)。而用戶與底層數(shù)據(jù)庫之間的銜接、映射、轉(zhuǎn)換交由ShardingSphere進行處理。

   是的，因為有l(wèi)ogicColumn存在，用戶的編寫SQL都面向這個虛擬列，Encrypt-JDBC就可以把這個邏輯列和底層數(shù)據(jù)表中的密文列進行映射轉(zhuǎn)換。于是遷移后的脫敏配置即為：

   encryptRule:??encryptors:????aes_encryptor:??????type:?aes
   ??????props:????????aes.key.value:?123456abc
   ??tables:????t_user:??????columns:????????pwd:?#?pwd與pwd_cipher的轉(zhuǎn)換映射??????????cipherColumn:?pwd_cipher
   ??????????encryptor:?aes_encryptor
   ?props:????query.with.cipher.column:?true

   其處理流程如下：

   

至此，已在線業(yè)務脫敏整改解決方案全部敘述完畢。我們提供了Java、Yaml、SpringBoot、SpringNameSpace多種方式供用戶選擇接入，力求滿足業(yè)務不同的接入需求。該解決方案目前已在京東數(shù)科不斷落地上線，提供對內(nèi)基礎服務支撐。鄭州治療不孕不育哪里好：http://www.zzfkyy120.com/

六、中間件脫敏服務優(yōu)勢

1. 自動化&透明化數(shù)據(jù)脫敏過程，用戶無需關注脫敏中間實現(xiàn)細節(jié)。

2. 提供多種內(nèi)置、第三方(AKS)的脫敏策略，用戶僅需簡單配置即可使用。

3. 提供脫敏策略API接口，用戶可實現(xiàn)接口，從而使用自定義脫敏策略進行數(shù)據(jù)脫敏。焦作國醫(yī)胃腸醫(yī)院好不好：http://jz.lieju.com/zhuankeyiyuan/37756433.htm

4. 支持切換不同的脫敏策略。

5. 針對已上線業(yè)務，可實現(xiàn)明文數(shù)據(jù)與密文數(shù)據(jù)同步存儲，并通過配置決定使用明文列還是密文列進行查詢?？蓪崿F(xiàn)在不改變業(yè)務查詢SQL前提下，已上線系統(tǒng)對加密前后數(shù)據(jù)進行安全、透明化遷移。

七、適用場景說明

1. 用戶項目使用Java語言進行編程。

2. 后端數(shù)據(jù)庫為MySQL、Oracle、PostgreSQL、SQLServer。

3. 用戶需要對數(shù)據(jù)庫表中某個或多個列進行脫敏(數(shù)據(jù)加密&解密)。

4. 兼容所有常用SQL；

八、限制條件

1. 用戶需要自行處理數(shù)據(jù)庫中原始的存量數(shù)據(jù)、洗數(shù)。

2. 使用脫敏功能+分庫分表功能，部分特殊SQL不支持，請參考SQL使用規(guī)范。

3. 脫敏字段無法支持比較操作，如：大于小于、ORDER BY、BETWEEN、LIKE等

4. 脫敏字段無法支持計算操作，如：AVG、SUM以及計算表達式

九、后續(xù)

本篇文章介紹了如何使用ShardingSphere產(chǎn)品之一的Encrypt-JDBC進行接入，接入形式還可以選擇使用SpringBoot、SpringNameSpace等，這種形態(tài)的接入端主要面向JAVA同構(gòu)，并與業(yè)務代碼共同部署在生產(chǎn)環(huán)境中。面向異構(gòu)語言，ShardingSphere還提供Encrypt-Proxy客戶端。Encrypt-Proxy是一款實現(xiàn)MySQL、PostgreSQL的二進制協(xié)議的服務器端產(chǎn)品，用戶可獨立部署Encrypt-Proxy服務，并且像使用普通MySQL、PostgreSQL數(shù)據(jù)庫一樣，使用例如Navicat第三方數(shù)據(jù)庫管理工具、JAVA連接池、命令行的方式訪問這臺具有脫敏功能的虛擬數(shù)據(jù)庫服務器。

脫敏功能屬于Apache ShardingSphere分布式治理的功能范疇。事實上，Apache ShardingSphere這個生態(tài)還擁有其他更強大的能力，例如數(shù)據(jù)分片、讀寫分離、分布式事務、監(jiān)控治理等。您甚至可以選擇任意多種功能模塊進行疊加使用，例如同時使用數(shù)據(jù)脫敏+數(shù)據(jù)分片，或是數(shù)據(jù)分片+讀寫分離，再或者是監(jiān)控治理+數(shù)據(jù)分片等。除了在功能層面的疊加選擇，ShardingSphere還提供了各種接入端形式，例如Sharding-JDBC或Sharding-Proxy等以滿足大家不同場景需求。

十、寫在最后

ShardingSphere從最初的僅支持分庫分表功能，到現(xiàn)在已形成包括數(shù)據(jù)分片、分布式治理、分布式事務等核心功能為主的生態(tài)圈。這也標識著它不僅僅是一款分布式數(shù)據(jù)庫中間件，不僅僅擁有分庫分表的能力，更是形成以數(shù)據(jù)分片、分布式治理、分布式事務為核心的全方位解決方案生態(tài)體系，歡迎大家在官網(wǎng)了解更多內(nèi)容，在gitHub關注我們?！

另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

文章名稱：ApacheShardingSphere數(shù)據(jù)脫敏全解決方案-創(chuàng)新互聯(lián)
URL分享：http://m.jiaotiyi.com/article/cdpsid.html