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

核心功能模塊：JED，提供數據查詢和寫入的自動路由、自動彈性伸縮、自動FailOver、自動負載調度和數據庫服務智能自治的功能。 實時數據發布與訂閱模塊： BinLake，完全自助、無狀態、自動負載、完全自治、可橫向擴展的集群化Binlog采集和訂閱服務。 自動化運維模塊：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后端有兩種使用方式：

通過Spark Streaming把它同步到HBase里，目前京東內部實際上是有一個項目叫做實時數據快照，就是通過這種方式，實現了HBase中的數據與線上MySQL實例中的數據的完全實時同步更新。

下游各個業務部門各自通過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馬上就會開源了，你馬上就可以使用到了。

來自：http://database.51cto.com/art/201801/563260.htm