在開始前，我想先介紹介紹一下我們在資料庫即服務（DBaaS）方向的努力過程。
我們是在2013年，當時雲端計算概念剛開始推廣，中國銀聯研究院需要完成一個資料庫雲的研究性專案。在當時很多雲端計算專案都是基於虛擬化，但是我們認為虛擬化不是未來，又由於我們對作業系統比較熟悉，所以基於CGroup的資源隔離技術開發出第一套DBaaS原型。
到了2014年，Docker容器技術已經在社群很火。眼前一亮，覺得這就是我們需要的容器封裝技術，於是我們決定在公司內部基於Docker重構。
2015年之前，我們用Docker技術解決容器封裝和使用，但是又有一個新問題擺在我們面前，那就是資源排程和編排問題。當時容器編排的概念剛剛開始，在看到Swarm或Kubernetes之前，我們一直在自己開發管理和排程邏輯，碰到各種需求變化帶來的問題。經過調研我們最終選擇了Swarm。在2015年基於Docker的背景下，我們認為這也是唯一的選擇。
經過兩年的改造和進化，DBaaS也從原型變成一個相對可用的資料庫雲平臺。在2016年中國銀聯資訊總中心邀請我們一起參與開發“生產級環境可用的DBaaS平臺”。這對於我們來說又是一個新挑戰，因為當時把資料庫這樣的有狀態服務放入容器中，進行服務化的管理，難度巨大，也沒有其他借鑒的案例。雖然經過前兩年的積累和研發，在容器編排和資料庫服務化管理這兩個方面我們已經積累了經驗，但要執行在中國銀聯的生產環境，最大挑戰還是來自於底層技術，儲存方案、網路方案和高可用排程方案，這三個方面才是決定能否在生產環境中穩定執行的三個關鍵指標。又經過一年的努力我們自己找到了相對應的方案並驗證可行。成功完成了中國銀聯第一期生產區DBaaS專案。
2017年，我們在基於一期專案的基礎上，增加了支援更多型別資料的服務，不僅支援MySQL，還添加了Redis支援，定義了更靈活的服務編排模型以適應將來更多不同型別資料服務。在金融行業客戶生產環境推廣後，由於新的網際網路樣式業務，對後端基礎服務的需求會快速增長，並且需求的資料型別也更多，不僅限於資料庫，應該說可以是所有的資料型別的服務。
花了點時間和大家分享了我們一路走來，從一個研究性專案，到公司開發的產品，到在金融客戶生產環境可用的平臺的整個過程。
其實在整個過程中，我們也在不斷摸索前進，從開始尋找資源隔離技術，到尋找資源管理，到服務編排模型，再到尋找多型別資料服務支援。整個過程是一個從下到上漸進的過程。
在2013年我們專案團隊對DBaaS理解：只是一個資料庫服務管理，只是負責最基本的的資料庫服務部署“交付、啟動、停止”這樣最日常的操作。到2015年，我們在重構DBaaS過程中認識到它其實應該是“資料庫資源池管理平臺”。2016年後我們進一步認識到DBaaS是“整合資源和服務結構，以服務化的方式提供資料服務的平臺”。
從DBaaS平臺理解變化可以看出我們由下到上演進的過程，實現了從軟體到平臺的不同階段，資源池化及自動化，服務化。
這個問題的答案，拿到今天來看也許根本不是問題，因為在容器編排工具選擇上大家一致都會選擇Kubernetes。在Kubernetes中已經定義的了Pod概念。
在這裡我就不贅述了，但是我們是在2013年開始開發DBaaS專案的，當時我們能夠借鑒物件是虛擬機器。
unit我們定義是一個服務中的最小管理物件，它是由一個容器（包含Namespace，二進製版本，環境變數），多個邏輯捲物件和目錄物件，一個網絡卡裝置和IP，和配置檔案物件。
我們就是把一個程式需要的部分都拆分管理，當時我們內部討論時發現，這個設計和容器設計思想似乎背道而馳，但是放在有狀態服務管理的維度去看問題時，也許這個是比較好的解決方案。
在我們設計unit時，最主要思想還是分而治之，把資源進行計算，儲存，網路分離之後，我們就可以對不同型別的資源進行管理，並且滿足有狀態服務在日常運維，線上擴容，線上變更的這些基本的核心需求。
作為DBaaS平臺，其實就是對資料庫服務的管理，合理靈活的服務模型才能適配更多不同型別的服務。
透過定義最小的管理物件unit，我們定義了最小的資源模型。但是對於一個完整的資料庫服務是完全不夠的。因為在資料庫架構中為了滿足分散式的一些特性，資料庫軟體大都會有複製的叢集結構，並且不同結構由於特性不同而導致了管理操作的不同。所以針對於完整的資料庫服務，需要對unit管理物件進行組合疊加後才是一個完整的服務物件，才能實現服務化。
這是我們對服務的定義，主要有三個物件組合疊加而成，單元、子服務、服務。
一個子服務是由多個單元組成，子服務會管理其擁有單元的關係，比如一組具備主從複製關係的MySQL，一組具備sharding關係的Redis等可以根據需求進行定義。
一個服務是由多個子服務組成，服務會管理其擁有子服務的疊加關係，比如一組ProxySQL和MySQL的關係，一組ProxySQL和多個MySQL的關係等。同樣也可以根據需求進行定義，這樣我們透過橫向和縱向的兩個物件，把分散的unit物件組合在一起。
從服務資源模型看，透過設計子服務物件固化一類unit的組織關係，可以使用配置檔案的管理方式實現，也可以使用執行命令指令碼的方式實現。透過設計服務物件，疊加多個子服務物件豐富服務的組織結構，為服務化管理提供有效的管理物件。
在整個服務的管理中，有狀態服務相比於無狀態服務有一個很明顯的區別，有狀態服務需要固化和資源的關係，固化一組服務中不同元件unit的關係。並且在發生變化時，不能透過摧毀和重建的方式進行改造，必須在原有狀態下，進行增量變化的方式進行變化。
簡單來說，無狀態服務是透過重啟樣式變化的，有狀態服務時透過繼承方式變化的。
所以管理有狀態服務需要更加複雜物件來進行記錄和延續。
定義資源模型，這個過程其實和Kubernetes中CRD過程很像，主要我們對於定義資源模型主要訴求來源於對映真實的硬體物件，進行邏輯管理，並且透過對硬體使用標簽方式，來完成在分配資源到多個硬體物件上，來感知硬體高可用屬性。
在圖中有八個資源物件，分別是：site站點、region區域、Cluster叢集、Node主機、Data storage外接儲存、IP address地址池、images容器映象、backup storage備份儲存。
從這些物件都可以找到相應的證實物理物件。這些物件的產生，一個原因是由於在規模化管理硬體時，需要這樣的邏輯物件來管理，更重要的原因是，針對於資料庫，需要多個硬體裝置來保證其高可用。
比如我們在產生一個服務時，如果指定高可用屬性，那麼分配演演算法就會過濾這些資源標簽，並且根據高可用原則進行過濾，從機房、機架電源、網路交換機、物理機、外接儲存的角度進行多方法的高可用篩選。保證服務在地理位置、電源、網路、主機、儲存都具備高可用，並且體現在整個服務的部署結構中。
很高興，今天和大家分享我們在建設DBaaS平臺的經驗和思考。今天時間有限，主要還是在分享設計時一些經驗和想法。下次有機會可以和大家分享，一些具體技術細節，比如分配演演算法，分配模型，網路架構的實現和儲存架構的實現。
Q：請問是採取什麼策略升級這些資料庫型別的服務？升級過程有宕機時間嗎？如果沒有，會有雙寫問題嗎？
A：在設計中是升級操作就是更新容器映象。更新策略會根據資料庫的高可用結構進行搖擺升級。
Q：具體是實現方式是怎樣，有沒有用到StatefulSet，或者StatefulSet的區別？
A：沒有用到StatefulSet，目前我們構建了一個名為服務物件，來管理服務的。應該說我們服務物件比service更複雜，可以理解為是由多個不同型別的Pod組成的。
Q：請問一下你們的binlog多長時間過期，有用什麼持久化的方式儲存嗎？
A：我們在封裝容器映象時，針對不同服務映象有外圍的配套指令碼。類似於Kubernetes中sidecat的實現。然後透過定期呼叫方式備份binlog到備份儲存。並且清理備份過的binlog。
Q：還有關於中介軟體和高可用的選擇，我們用MaxScale和MHA，但是並不是非常穩定？
A：的確，我們在設計DBaaS也考慮到了，由於目前在MySQL中介軟體和高可用套件沒有一個很好的開源產品，所以很難說你必須用哪個方案實現。所以我們在開發中就將這樣的需求設計為靈活的服務架構定義，我們平臺支援不同型別MySQL高可用方案和中介軟體方案。我們在中國銀聯是自己開發的高可用中介軟體方案，透過高可用元件發現故障進行隔離，使用Proxy元件進行資料路由，使用MySQL做資料複製。在我們設計中，可定製不同服務架構來進行服務的管理。
Q：請問在這套平臺裡面支援比如說，前端可以讓使用者選擇資料庫執行的方式（單機）（還是讀寫分離、主從架構），這個是自動化配置的嗎？這個過程是提前構建的容器映象對嗎？
A：資料庫容器映象是相同的，單機、主從、讀寫分離等不同服務架構會生成相應的配置檔案和啟動項，管理邏輯。整體管理會使用定義服務架構配置資訊進行自動解析產生相對應的管理操作。
Q：單元、子服務、服務的理解還是比較抽象，有更易理解的例子嗎？
A：單元相當於一個我們自己構建的Pod，但不同於Pod。單元只會包換一個容器。子服務內是多個相同型別的單元，這樣單元就可以部署在不同物理機上，並且完成資料庫的複製關係。服務是多個型別的子服務的集合，服務內的子服務會有關聯關係，比如一個完整的Redis可以有一組三個sentinel組成的子服務 + 一組多Redis Proxy的子服務 + 多組主從複製的Reids。同樣的型別甚至可以對映到TiDB上，可以有一組三個TiDB + 一組三個PD + 一組五個TiKV。
A：在容器開始階段，大家會有共同的認識就是容器只適合執行無狀態服務。直到大家對容器需求越來越多，有了Petset，有了StatefulSet，甚至有了MySQL Operater。但回歸到容器本質還是為統一運維標準，快速靈活的管理資源。但是有狀態服務天生就是重的，需要使用繼承式的方式進行管理。但為了將有狀態服務放到容器，享受容器的優勢，就必須進行計算、儲存、網路這些關鍵資源的分離。
Q：請問你們的平臺是用什麼語言寫的，有用到鏈路跟蹤嗎？
A：我們平臺全部元件都是用Golang寫的。目前鏈路跟蹤還沒有，我們主要是透過我們的自研的監控平臺，獲取監控資料，監控物理機，容器，和容器內服務的資訊，進行高可用的管理，也正在和人工智慧公司合作，對運維資料進行分析，進行故障智慧分析。
本次培訓內容包括：容器介紹、容器網路、Kubernetes架構基礎介紹、安裝、設計理念、架構詳解、設計原則、常用物件、監控方案、Kubernetes高階設計和實現、微服務、實踐案例分享等，點選瞭解具體培訓內容。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
