本文根據呂信老師在〖Gdevops 2017全球敏捷運維峰會廣州站〗現場演講內容整理而成。

講師介紹

呂信，京東商城資料庫技術部資深架構師，擁有多年資料產品研發及架構經驗。在京東及國內主導多種資料產品開發及社群建設，積極活躍於資料產品領域，對資料庫及大資料領域各個產品具有豐富經驗，目前在京東商城主導彈性資料庫研發及推廣使用。

京東彈性資料庫不是一個單一的產品，而是京東在對資料庫的使用、運維和開發過程中遇到的一系列問題的解決方案，和運維經驗的總結昇華進而形成的一套產品系列，主要包括三大功能模組：

1. 核心功能模組：JED，提供資料查詢和寫入的自動路由、自動彈性伸縮、自動FailOver、自動負載排程和資料庫服務智慧自治的功能。
2. 實時資料釋出與訂閱模組： BinLake，完全自助、無狀態、自動負載、完全自治、可橫向擴充套件的叢集化Binlog採集和訂閱服務。
3. 自動化運維模組：DBS，實現了京東線上所有資料庫服務申請、DDL/DML上線、資料抽取等的流程化和自動化。

分享大綱：

1、發展歷程

2、功能特性

3、整體架構

4、實現細節

5、使用情況

一、發展歷程

在我2011年加入京東之初，京東的資料庫正是處於諸侯混戰的階段，各種資料庫都有，包括：MySQL、PostGre、Oracle、SQL Sever，在2011年之後，開始去IOE，到了2014年，京東基本上完成了去IOE，所有的業務系統都遷移到了MySQL上。

在大規模使用MySQL的過程中，我們發現，隨著業務資料量的增長，很多業務開始了漫長的分庫、分表之旅，起初各個業務系統在自己的業務程式碼中維護分庫分表的路由規則，而且各個業務系統的路由規則和整體設計都不一樣，後來由於人員更迭以至於業務程式碼無法維護，不同業務使用的資料庫分庫分表模式不盡相同，導致資料庫的維護工作也難如登天。這時我們開始重新思考應該提供什麼樣的資料庫服務，得出了以下幾點：

• 統一分庫分表標準
• 路由針對業務透明
• 資料庫服務伸縮無感知
• 統一資料服務
• 業務研發自助申請服務
• 資料庫運維工作自動化

為了實現上述功能特點，我們分為兩步走：第一步是優先解決業務和運維窘境，從而爭取足夠的時間和技術buffer進一步完善產品，第二步是最終完美形態的產品研發。

因此，我們首先在2015年開發了JProxy，優先解決緊急的業務和運維難題：分庫分表規則統一化和路由透明化。在拿到充分的時間buffer後，我們從2016年開始以匠人的精神精雕細琢京東彈性資料庫。

如前面所說：京東彈性資料庫是一個產品系列，主要是解決資料庫的運維、使用和研發過程中的問題，具備動態伸縮、高可用、查詢透明路由、叢集化日誌服務和自動化運維等功能。

本章將就京東彈性資料庫三個核心模組的功能進行詳細說明。

1、JED（JD Elastic DataBase）

JED是JProxy功能的父集，它除了具備透明路由、統一分庫分表標準之外，還提供了五大功能：

（1）線上動態擴容

起初某個業務可能申請了4個分庫，後面隨著業務的發展，資料量越來越大，可能需要擴容到 8個分庫，一般的資料庫中介軟體在擴容時，需要與業務研發部門協商一個業務低谷期停業務，然後進行擴容，擴容完畢後重新啟動業務。為了解決這個問題，JED提供了線上動態擴容功能，擴容只會對業務造成秒級影響，且無需人工介入。我們現在可以觸發自動擴容，設定的策略是當磁碟的使用率達到80%，就自動進行擴容。

（2）自動Failover

Master一旦出現宕機，哨兵檢測系統就會第一時間檢測到，會自動觸發註冊在哨兵檢測系統中的Hook程式，Hook程式就會選擇一個最新的Slave替換Master，然後更新ETCD中的元資料資訊，業務方的下一次請求就會發送新的Master上。

（3）相容MySQL協議

JED是完全相容MySQL協議的，即通過MySQL的Client端或者標準的JDBC Driver都可以連線到JED的Gate層，然後進行查詢和計算。

（4）多源資料遷移

我們基於ghost進行改造，開發了京東的資料傳輸和接入工具： JTransfer，實現了業務資料的動態遷移。如果以前你的業務是執行在MySQL上的，現在要遷到JED上，你不需要停止任何業務，直接啟動JTransfer的資料遷移服務，就可以在後臺自動完成資料的同步和遷移。遷移完畢後，JTransfer會自行比對JED上的資料與原來資料的一致性和lag計算，當資料完全一致，且lag小於5秒時，就會郵件通知業務方進行復驗，複驗沒有問題，業務方直接將資料庫連線指向到JED就可以正常提供服務了。

（5） 資料庫審計

JED具有資料庫審計的功能，該功能實現在Gate層，在Gate層我們會得到應用傳送給JED的所有SQL，然後將SQL語句或者SQL模板傳送給MQ。由於是在Gate層實現的，而Gate層與MySQL服務不在一個容器上，因此對MySQL服務不會產生任何的負面影響。

2、BinLake

BinLake只做一樣工作：叢集化Binlog的採集和訂閱服務。BinLake之前，我們使用Canal進行binlog採集，但我們發現存在資源浪費等問題：若一個業務需要採集MySQL Binlog，並且還需要HA保證的話，我們至少需要兩臺伺服器。那多個業務怎麼辦？於是我們開發了BinLake，其功能特性如下：

（1）  無狀態叢集化BinLog採集

BinLake是一個叢集化的BinLog採集和訂閱服務，並且與常規意義上的叢集不一樣，我們的叢集是沒有master節點的，而且叢集中的所有工作節點都是完全平等的，這也就意味著，只要叢集中的節點沒有全部宕機，BinLake叢集可以一直提供服務。

（2）  高可用與自動故障轉移

針對於某個Mya例項的採集instance（每個instance代表一個執行緒）一旦掛掉，會在叢集中的負載最低的工作節點上重新啟動一個instance，繼續從上次掛掉的Offset進行採集，不會造成Binlog的丟失和重複。

（3）  負載自動均衡

假設所有Binlog的叢集有八個節點，其中有七個節點的負載比較高，當你在接入Binlog時，在沒有人工介入的衡量下，整個叢集會將以新接入的一個Instance採集例項，自動選擇一個健康度最高的Wave服務，然後啟動Binlog採集。

（4）  支援多種MQ

BinLake採集到的所有binlog的event會被封裝成Message傳送給MQ，目前我們支援JMQ和Kafka兩種MQ產品。

（5）  支援叢集橫向擴容

當BinLake叢集的服務能力達到了瓶頸，我們可以簡單地將新的工作節點啟動，只需要在新的工作節點配置檔案中配置上與線上的工作節點相同的ZooKeeper路徑，新的工作節點就會自動加入到已存在的BinLake叢集中。

3、DBS

DBS主要完成自動化運維的工作。它可以完成資料庫服務的自動化交付、資料庫操作的流程化管理、資料庫健康指數全面監控、資料庫自動備份及結轉，以及排程作業的多樣化排程（包括定時、依賴以及觸發三種排程模式）。

三、整體架構

這是京東資料庫的一個整體架構圖。可以看到，最底層是JDOS2.0，JDOS 2.0是京東新一代的容器技術，是Docker的管理平臺，實際上京東所有的資料庫服務現在已經完全執行在Docker之上了，這一點是讓我們比較引以為豪的工作成績，而這些都離不開京東JDOS的底層支援。

JED包括六大元件：

• JED-Gate：實現分庫分表的透明化路由和審計功能。
• JED-Ctl：命令列控制工具。
• JED-Ctld：也提供叢集控制功能，但是它是以服務的方式提供API介面。
• Topology：是整個JED的元資料管理中心，所有的元資料是通過Topology進行管理的。
• JED –Tablet：是每一個MySQL前端的Proxy，提供MySQL查詢快取和流複製等。
• JTransfer：線上資料遷移和接入工具。

BinLake的服務角色比較簡單，只有兩種服務：Wave和Tower。

BinLake整個叢集是完全無狀態的。我們所知道的大部分叢集化服務都是有狀態叢集和不對等叢集。所謂不對等叢集就是叢集裡要有Master服務角色，負責整個叢集的管理；還要有Worker服務角色，負責實際任務的執行。但整個BinLake是沒有任何Master的，只有一種服務角色：Wave，就是你的工作節點。Tower只是一個可以與叢集進行互動式操作的HTTP服務。Tower與傳統Master節點的不同之處在於：它不負責任何元資料的管理，它只是向Topology服務傳送命令，更新或者獲取儲存在ETCD或ZooKeeper中的元資料資訊。

DBS是構建於我們的API Platform之上的，API Platform是我們自己開發的一個簡單的Faas平臺，有了API Platform，在京東只要是會寫程式碼的人，不管你用何種開發語言，只要是滿足Restful協議的服務，都可以註冊到API Platform中，並不斷豐富DBS。

DBS包括幾個核心模組：

• JGurd 是一個分散式檢測系統，它提供了對MySQL服務的完全分散式檢測，避免了因為網路抖動而產生對MySQL健康狀況的誤判。
• Scheduler是排程平臺，是基於Oozie改造開發的叢集排程平臺。
• JProcess Maker是DBS的流程引擎。
• DBS-Tools是我們在資料庫運維過程中需要用到的一些資料庫工具，比如說AWS報告、監控工具、Master切換工具、域名漂移工具等。
• Authentication是京東內部的身份認證和許可權控制組件。

下面我們針對JED、BinLake和DBS的架構進行詳細講解。

1、JED

JED的前端是AppServer，從整體架構上，JED和Appserver直接打交道的只有一個角色，就是JED-Gate，JED-Gate完全相容MySQL協議，AppServer可以一些查詢語句傳送給JED-Gate，JED-Gate層對所有查詢的查詢執行計劃都會做快取，並且根據查詢執行計劃，通過Topology服務獲得查詢所涉及表的路由源資料資訊，根據元資料資訊將查詢語句改寫或者拆分發送到底層的Shard上去。目前JED已經滿足了廣域分佈架構，實現了異地多活。

2、BinLake

針對上圖的BinLake架構圖，可以看到BinLake叢集中的每個工作節點叫做Wave，每個Wave節點上有多個instance，這個instance就是針對於每個MySQL例項的Binlog採集執行緒，在同一個Wave例項上的多個instance例項通過Epoll模型實現高效網路監聽和通訊。當用戶新採集一個MySQL的Binlog或者某個instance執行緒掛掉了，會根據當前叢集中各個Wave服務的健康狀況選擇一個健康度最高的Wave例項，去例項化這個新的instance執行緒。而每個Wave例項上的健康度是根據Zabbix的監控資料進行動態計算的。

從圖中可以看到，Tower服務其實沒有跟Wave服務做任何直接的通訊或者聯絡，Tower只會跟ZK或ETCD叢集直接做互動，它對ZK或者ETCD叢集任何元資料的更改都被Wave服務及時發現，發現之後，Wave服務會採取一系列相應的措施，來對元資料的更改進行響應。

3、DBS

DBS依賴於兩個基礎的服務進行構建，第一個是API Platform，第二個是JDOS， 通過API Platform實現DBS整個系統所有功能模組的完全解耦，因為所有的底層操作都是單獨開發的符合Restful標準的HTTP服務，並通過API Platform暴露出來。不管是研發人員還是DBA，無論使用什麼樣的開發語言，只要能夠開發出符合Restful的HTTP服務，就可以將其註冊到API Platform上，並實現DBS系統中特定的功能。

其實無論是JGuard、JProcessMaker、DBS-Tools還是Scheduler，它們做的所有工作都只有一樣：呼叫API Platform上所暴露的介面。API Platform會根據你的註冊資訊，去呼叫Tower暴露的API介面，或者是呼叫MHA的一些指令碼或者其它介面。

另外，不管是DBS的應用伺服器、MySQL伺服器、API Platform，後端寫的所有介面，我們都會採集這些服務上的所有日誌，採集了之後接入到Unilog Platform，用於後續的日誌的審計和檢查。

四、實現細節

由於京東彈性資料庫包含的功能和元件很多，下面我選出幾個特定的功能，在實現細節上詳細說明。

1、動態線上擴容

Step1：建立兩個目標Shard

假設某個業務方在JED中起初申請了一個Shard，這個Shard大家可以把它簡單地想象成是一套MySQL叢集，這時我要將它擴容成兩個Shard。

假設現在有一萬條記錄，要擴成兩個Shard，那麼每個目標Shard裡面就有5000條。在JED裡，在觸發擴容這個動作時，首先會通過 JDOS介面，將目標Shard的所有POD都建立並啟動起來，如果每個目標Shard都是1主2從，總共會啟動6個POD，12個Container（一個POD中有2兩個Container，1個Container中是Tablet服務，1個Container是MySQL服務），然後每個POD都是 Not Sevring狀態，其中每三個POD例項組成一個Target shard。可以看到，Source Shard中的sharding key對應的key range是：0x00-OxFF，這裡的 KeyRange也就是你的sharding key經過雜湊之後能夠落到多大的範圍，現在要將一個Source Shard分為兩個Target Shard，所以Source Target對應的Key Range也要就要一分為二，可以看到兩個Target Shard 對應的KeyRange是0x00-Ox80，Ox80-Oxff，並且是Not Serving狀態。

Step2：全量資料過濾克隆

兩個Target Shard建立之後，會根據ETCD裡的預設配置針對每個Target Shard建立MySQL的複製關係，比如一主兩從：一個Master，一個Replication，一個ReadOnly；一主三從，一個Master，兩個Replication，一個Readonly；一主四從，一個Master，兩個Replication和兩個ReadOnly。

建立完複製關係之後，首先會通過JED-Worker將Source Shard中的Schema資訊複製到兩個TargetShard中，然後將Source Shard中的ReadOnly Pod從MySQL複製關係中摘除下來，最後通過JED-Worker將ReadOnly中的資料過濾拷貝到兩個TargetShard中。

Step3：增量資料過濾到兩個目標Shard

現在我們以最簡單的一拖二的方式來講述。當你的兩個TargetShard建立完成後，你要做的就是先把你的這一萬行記錄拷到兩個shard上，拷完之後去建立過濾複製。

完成了Step2的過濾拷貝之後，將ReadOnly重新掛到Source Shard上，然後JED-Worker通過Replication中的介面建立binlog的過濾複製，會在Replication上啟動兩個協程，並根據Target Shard的Key Range分別將binlog複製到對應的TargetShard上。

Step4：資料一致性校驗

當TargetShard中的binglog與SourceShard中的binlog的lag小於5秒的時候，會啟動資料的一致性校驗，該過程是在JED-Worker上完成的。過程很簡單，就是通過大量的後臺協程Target和Source上去取出資料一條一條對比，如果資料的一致性校驗通過，就開始進行Shard切換。

Step5：切Shard

首先將SourceShard中Slave的Serving狀態切換成Not Serving，同事將TargetShard中Slave的Not Serving狀態更改為Serving，最後將Source中的Master停寫，等Target中的Master與Source中的Master無複製延時後，將Source Master停寫，通過JED-Worker將過濾複製斷掉，然後將Target的Master置為Serving狀態，並接受寫入。

上述的所有Serving與NotServing狀態的改變均是通過改變etcd中的元資料來完成的。當前端性業務再發送新的查詢過來時，Gate就會根據最新的元資料資訊，將你的這條SQL傳送到最新的Target Shard。

2、自動FailOver

以1主3從的MySQL主從架構對JED的自動FailOver機制進行說明。

如果Master發生異常，JGuard會通過分散式檢測（JGuard是通過ORC改造之後形成了一個分支檢測服務）檢測異常，檢測到異常之後會通過郵件和簡訊通知業務介面人，通知完之後，不會等業務介面人進行處理，直接從當前整個MySQL叢集當中選擇一個GTID最大的一個MySQL例項，將這個MySQL例項切成Master，並根據新的Master重建新MySQL主從複製關係，將剩餘的Replication和ReadOnly重新掛載到新的Master上，再呼叫JED-Ctrld服務的介面更新ETCD中的元資料，這樣後續的DDL/DML就會發到最新的Master之上。最後缺失的一個Tablet需要人工補入。

3、Streaming Process

JED實現了查詢的流式處理，以查詢語句select table_a.age from table_a order by table_a.age為例說明流式處理的過程。JED-Gate接收到該查詢語句之後，會根據ETCD中的分片元資料，將該語句分發到三個Shard中，各個Shard返回給JED-Gate資料本身就是有序的，在JED-Gate中針對每個Shard都會有一個buffer與之對應，每個buffer用來流式的接收每個Shard返回的排序完畢的資料，因此該buffer中的資料也是有序的。然後將每個buffer的首地址儲存到一個PriorityQueue裡面， PriorityQueue是一個堆排序的優先順序佇列，會根據每個buffer中的首元素不斷的進行排序。每從PriorityQueue中取出一個元素，PriorityQueue都會調整Buffer的先後順序，JED-Gate會將元數一個一個地取出來，以流式的方式發給前端，從而實現整體流式排序。

4、Join處理

現在我們看下如何在JED上執行Join查詢的，在下面所有的說明中，我們都有一個假設條件，就是所有的表的sharding key都是ID。

對Join查詢的處理，要分情況：

第一種情況：Join Key與Sharding Key相同。這種情況下由於Join Key 和 Sharding  Key是完全相同的，因此是可以將Join查詢語句直接傳送到下面的每個shard，在JED-Gate匯聚各個shard的部分查詢結果，並返回給前端應用。

第二種情況：Join Key與Sharding Key相同。如上圖所示，比如Select a.col,b.col.from a join b on b.id_2=a.id where a.id=0。針對該查詢語句，JED-Gate首先對其進行SQL語句改寫，改寫為兩條語句：select a.col,a.id from a where a.id=0和select b.col from b where b.id_2=a.id。在第二個查詢語句中的a.id是繫結變數。JED-Gate會首先根據select a.col,a.id from a where a.id=0，定位到該SQL需要定位到哪個shard，然後將SQL傳送到相應的Shard執行，並流式的獲取其結果，然後將結果中的a.id欄位的值取出，並將值賦給select b.col from b where b.id_2=a.id語句中的繫結變數a.id，然後將複製後的第二條SQL語句依次傳送給所有的shard，並將結果與第一條SQL語句中的結果組合，流式地返回給前端。

當多級Join的時候，也是相同的思路，這裡不再贅述。

5、BinLake元資料架構圖

前面已經提到BinLake有一個很大的特點：一個完全無狀態的叢集，沒有Master管理節點。而要實現這個特性最重要的就是要有合理的元資料設計。之所以沒有Master節點，是因為把Master節點的功能委託給了ZooKeeper或ETCD。通過藉助ZooKeeper中的ephemeral znode實現了Wave服務乃至instance的自動發現和HA，並最終實現了無Master，無狀態的完全對等叢集。

根據上面的元資料架構我們對BinLake的所有元資料進行詳細說明。

一個BinLake叢集的root znode是一個名為wave的znode，在wave之下是一系列的形式為：“MySQL域名命名:port”的znode。這樣的每個znode都對應了一個MySQL例項。而在每個MySQL例項對應的znode下面是該MySQL例項的管理、資訊儲存和選舉znode。其中counter節點中記錄了當前MySQL例項對應的instanc重啟了幾次，若連續重啟超過7次，就會發出報警資訊。而dynamic節點則記錄了每個MySQL例項對應的Binlog採集執行緒對應的快照資訊，包括：當前採集到的Binlog檔案、Offset、Timestamp、GTID、最近的10個時間點Binglog位置和Filter Rules等，從而保證instance重啟後，可以利用這些資訊繼續進行Binlog採集。後面的sequencenumber對應的一系列znode是由Curator自動建立的znode，來保證選舉的正確性和防止羊群效應。而“Bingdleader：wavehost”對應的znode，主要用於人工介入binlake，從而指定讓下次instance leader選舉的時候，固定在wavehost對應的Wave節點上。

如果我某個MySQL採集的Instance掛了，Curator就會在後面的第一個znode對應的wave服務上首先進行leader選舉，若成功選舉，就接入，否則依次對後面對應的每個Wave例項進行選舉，直到成功選舉出leader。選舉出新的leader之後，就會在對應的Wave服務上重啟Binlog採集的instance執行緒，該instance就會根據dynamic znode中儲存的快照資訊重建MySQL的複製關係，繼續進行Binlog採集。

6、叢集化Binlog訂閱

BinLake中的Binlog採集方式有兩種：時序和亂序。

時序：通過NIO實現的類似Epoll的網路模型監聽所有與MySQL之間的連結的網路事件等檢測到與某個MySQL之間的連線有byte流到達時，就會盡量多的讀取所有的byte流，將其全部放到一個Byte Buffer裡，然後通過Worker Thread對ByteBuffer中的Byte進行Decode，並解析成一個個的EventMsg，進而將EventMsg也放到一個MessageBuffer中，在MessageBuffer後面有一個Handler執行緒，這個Handler執行緒會根據ZooKeeper裡的一些元資料資訊（比如：Topics、FilterRules、MQ型別和地址等）對EventMessage進行處理，然後使用protobuff進行序列化後傳送到正確MQ中的特定的Topic裡。這裡的處理包括：根據庫表型別過濾、列過濾、事務頭Event和尾Event過濾等。

亂序：同從上圖中可以看出亂序處理與時序處理的前半部分是相同的，只是在EventMessage Buffer後面是通過執行緒池進行併發處理的，測試結果表明亂序處理的效能是時序處理效能的10倍。

五、落地使用

從上圖可以看出，JED資料庫中介軟體服務通過JTransfer來實現MySQL和JED之間的資料正反向同步和傳輸。現在JED可以實現MySQL向Oracle、Postgres等多種資料庫的實時資料同步和傳輸。BinLake可以對MySQL和JED中的Binlog進行採集，併發送到JMQ或者Kafka，在MQ後端有兩種使用方式：

1. 通過Spark Streaming把它同步到HBase裡，目前京東內部實際上是有一個專案叫做實時資料快照，就是通過這種方式，實現了HBase中的資料與線上MySQL例項中的資料的完全實時同步更新。
2. 下游各個業務部門各自通過Consumer消費，進而進行訂單積壓監控、智慧報表以及營銷實時推薦等。當然JED以及BinLake、Jtransfer都是通過DBS進行自動化運維、排程和管理的。

京東彈性資料庫落地狀況

這些是在9月份從DBS系統裡面拿到的，服務線上業務是指上線專案的個數，目前京東彈性資料庫服務了線上3122個專案，管理的MySQL例項個數有將近兩萬個，管理的Table就比較多了，有660多萬個，並且完成了自動線上切換2700餘次，自動化上線有27000餘次。現在京東有一般的業務都遷到了JED上，當然還有一半的業務正在容器化的MySQL服務上並逐步地進行遷移。

分片數與OPS、延時的關係情況

上圖是JED的分片數與OPS以及分片數延時的一些關係。從圖中可以看出，隨著分片數的增加JED的服務能力也出現線性增長的趨勢。而隨著分片數的增加延時幾乎沒有變化（延時的單位是毫秒）。

Gate數與OPS、延時的關係情況

上圖是Gate數目與OPS以及Gate數目與延時的關係。從圖中可以看出，通過簡單的增加Gate的數目而實現JED資料庫服務能力的橫向擴充套件，不會導致明顯的延時增加。

問答環節

問題1

想諮詢一下咱們的JED做故障切換之後，如果存在資料的複製延遲，這時直接把它切為Read  Write狀態，有部分的Binlog資料還沒追上來，髒資料怎麼辦？這部分髒資料是人工介入進行處理，還是有什麼其它方案來把它自動處理？

答：JED在做Master FailOver時，實際就是你在後端做分片的時候，看MySQL的複製模式是半同步還是非同步，如果是半同步，一旦發現你的Master Fail Over，不會出現所有Slave都lag Master的Binlog。

追問：就是說在Binlog追上之前還是ReadOnly狀態，binlog完全追上之後，才切換為ReadWrite嗎？

答：舉個例子，比如說你後端Master下掛了兩個Slave或者是多個Slave，因為你啟用的是半同步，那麼只要你裡面沒有任何一個追上Master（相當於是你的Master都是 ReadOnly狀態），這個並不是說在Failover裡存在這個問題，而是即使單純的MySQL服務啟用的若是半同步，當沒有任何一個Slave追上Mater的時候，Master肯定是ReadOnly。

問題2

老師好，因為剛才我聽了JED，想問一下JED裡有沒有異構資料庫？比如說，如果我要像你說到的有互相轉這種情況，那麼我要同時轉幾個表，在不同的異構資料庫裡面，我要如何保證它的查詢速率？比如說各個表，我同事要加一個索引，我有沒有統一配置的情況，還是叢集裡的每個庫都要重新再各配一次？

答：說實話，沒聽太清楚你說什麼，就說一個實際的例子吧，你的意思就是說JED裡面有一個庫，實際上就叫KeySpace，下面有四個分庫或者四個分表你現在要統一對KeySpace中的所有分庫或者分表加索引，它怎麼去做，是嗎？

追問：是每個分庫都要加嗎？這樣的話是不是每個分表都要加一條索引，有沒有可以統一一次性配置的功能？

答：在JED裡面實際上是有一個控制檯的，目前不支援直接通過Gate執行DDL，就是說DDL在Client或是通過JBDC Driver是不允許執行的，直接就會報錯，你如果要執行DDL，是通過DBS自動化上線流程通過JED Ctld服務去執行的，Ctld服務會找到你KeySpace下的所有Shard，然後在每個Shard裡面去執行這些DDL。

問題3

有兩個問題想請教一下，一是剛才演講中聽您說這個彈性資料庫有好和壞的東西，那我能不能單獨用一個元件一樣的東西直接移植到JED上，其它東西不用行不行？我這邊的這個資料庫是主要是可以擴容的，但我們業務簡單一點，可能沒那麼多。

答：京東彈性資料庫現在包括三大模組，你可以單獨地去用JED或者BinLake，但你不能夠單獨去用DBS，因為你如果單獨用JED或者BinLake，你是可以脫離京東的自動化運維管理系統的控制，後續的審批當然是沒有了的，可你對於BinLake這個叢集以及JED的管理，是完全依賴於它的API是做控制的，就是說，後續假如說你公司有自己的一套運維管理系統，你可以基於BinLake或者JED的API，跟你的自動化運維管理系統整合，這個沒問題，但你如果只用DBS就不行了，因為DBS是完全地跟京東的JDOS耦合的，這就是為什麼我們可以實現資料庫服務資源的一個自動化交付和自動化運維，實際上是建立在這個JDOS之上的，因為京東所有的資料庫都已經上Docker了，所有的資料庫服務均執行在Docker裡，不管是JED還是傳統的MySQL服務，都是執行在Docker之上的，所以說你只能夠單獨地用其中兩個元件，一個是BinLake，一個是JED。

追問：另外一個問題就是說，因為你說的三個模板塊，那麼現在這個彈性資料庫有沒有可能做成一個像包一樣的形式或一個統一的安裝軟體之類的東西，有沒有這樣的計劃呢？

答：先回答第一個問題，三個模組是不會合到一塊的，因為我們之所以把它分開就是為了實現解耦，我們現在正在啟動內部的一些私有云的資料庫服務，就是說後續對於我們京東內部的使用者來說，你只需要申請就行了，有點像你用阿里的RDS一樣，但我們不會對外提供服務，同時我們的JED和BinLake馬上就會開源了，你馬上就可以使用到了。

原文來自微信公眾號：DBAplus社群