MySQL 作為當(dāng)前比較受歡迎的關(guān)系型數(shù)據(jù)庫(RDS)，在云原生浪潮中仍然面臨諸多挑戰(zhàn)。如何用 Cloud Native 的設(shè)計原則，通過沙箱隔離、計算和數(shù)據(jù)的完全分離，實現(xiàn)低成本、可擴展、高可用的 Cloud RDS 方案?阿里云數(shù)據(jù)庫團(tuán)隊的姜杉彪(孟宇)同學(xué)將介紹一種云原生分布式 MySQL 高可用數(shù)據(jù)庫方案，分享其中的關(guān)鍵技術(shù)，并對云原生場景下傳統(tǒng)數(shù)據(jù)庫的發(fā)展趨勢做簡要分析。

云時代的到來，無論傳統(tǒng)行業(yè)還是互聯(lián)網(wǎng)行業(yè)，業(yè)務(wù)越來越多樣，迭代速度越來越快，使得整體數(shù)據(jù)量大幅提升。

近兩年，隨著 Docker + Kubernetes 等技術(shù)的興起，大家都將業(yè)務(wù)往容器化遷移，團(tuán)隊的技術(shù)也在往云原生方向演進(jìn)。早期的 Kubernetes 著重解決 Stateless 和 Share Nothing 的應(yīng)用部署場景，然而在如今愈發(fā)復(fù)雜的應(yīng)用場景中經(jīng)常會遇到有狀態(tài)保存的需求。

從 Kubernetes 1.9 開始，針對有狀態(tài)服務(wù)的資源類型 Statefulset 進(jìn)入 GA，而且 Kubernetes 1.14 版本 Local Volume、CSI 等存儲功能也進(jìn)入 GA 階段，Kubernetes 對有狀態(tài)服務(wù)的支持得到全面加強，這使得很多數(shù)據(jù)存儲型基礎(chǔ)中間件往 Kubernetes 遷移成為可能。

MySQL 作為當(dāng)前比較受歡迎的開源關(guān)系型數(shù)據(jù)庫(RDS)，集可靠、易用、功能豐富、適用范圍廣等特點于一身，使其成為關(guān)系型數(shù)據(jù)庫的主要選擇。雖然備受關(guān)注，但 MySQL 在云原生浪潮中卻也面臨著諸多挑戰(zhàn)。如何用 Cloud Native 的設(shè)計原則，通過沙箱隔離、計算和數(shù)據(jù)的完全分離，實現(xiàn)低成本、可擴展、高可用的 Cloud RDS 方案?

本文介紹一種云原生分布式 MySQL 高可用數(shù)據(jù)庫方案(下稱“SlightShift MySQL 高可用方案”)，并對云原生場景下傳統(tǒng)數(shù)據(jù)庫的發(fā)展趨勢做簡要分析。

??

一 需求&挑戰(zhàn)

在考慮云原生場景下的 MySQL 高可用架構(gòu)時，主要有如下幾個方面的挑戰(zhàn)：

• 故障轉(zhuǎn)移：主庫發(fā)生宕機時，集群能夠自動選主并快速轉(zhuǎn)移故障，且轉(zhuǎn)移前后數(shù)據(jù)一致。
• 敏捷彈性伸縮：基于副本的彈性橫向擴展，擴縮容過程不中斷業(yè)務(wù)訪問。
• 數(shù)據(jù)安全性：數(shù)據(jù)定時冷備/實時熱備，以便故障恢復(fù)和數(shù)據(jù)遷移。
• 數(shù)據(jù)強一致性：用作備份/只讀副本的Slave節(jié)點數(shù)據(jù)應(yīng)該和主節(jié)點數(shù)據(jù)保持實時或半實時一致。

二 目標(biāo)&關(guān)鍵考慮點

SlightShift MySQL 高可用方案要達(dá)到的目標(biāo)：

• SLA保障：一年內(nèi)可接受最高 52.56 分鐘服務(wù)不可用(99.99%)。
• 故障轉(zhuǎn)移：主庫出現(xiàn)異常時主從切換耗時 < 2min。
• 彈性擴展：從庫理論可無限擴展，擴展從庫耗時 < 2min。
• 冷備恢復(fù)：MySQL集群出現(xiàn)不可恢復(fù)性問題時，從冷備恢復(fù)耗時 < 10min。

除以上目標(biāo)外，在技術(shù)架構(gòu)設(shè)計時還需重點考慮以下關(guān)鍵點：

• 高可用
• 應(yīng)用接入成本
• 資源占用量
• 可擴展性
• 可維護(hù)性

三 架構(gòu)設(shè)計

該 MySQL 高可用方案使用一主多從的復(fù)制結(jié)構(gòu)，主從數(shù)據(jù)復(fù)制采用半同步復(fù)制，保證了數(shù)據(jù)一致性和讀寫效率，理論上從庫可無限擴展。

??

在數(shù)據(jù)引擎上層添加了仲裁器，使用 Raft 分布式一致性算法實現(xiàn)自動化選主和故障切換。

路由層使用 ProxySQL 作為 SQL 請求代理，能夠?qū)崿F(xiàn)讀寫分離、負(fù)載均衡和動態(tài)配置探測。

監(jiān)控告警方面，采用 Prometheus-Operator 方案實現(xiàn)整個 MySQL 高可用系統(tǒng)的資源監(jiān)控告警。

運維管控方面，引入 Kubernetes Operator 的管控模型來實現(xiàn) DB-Operator，能夠做到聲明式配置、集群狀態(tài)管理以及On Demand(按需創(chuàng)建)。另外，可以在 MySQL 控制臺上進(jìn)行 MySQL 的基礎(chǔ)運維，例如：數(shù)據(jù)庫管理、表管理、SQL查詢，索引變更、配置變更、數(shù)據(jù)備份&恢復(fù)等。

四 關(guān)鍵技術(shù)

狀態(tài)持久化

容器技術(shù)誕生后，大家很快發(fā)現(xiàn)用它來封裝“無狀態(tài)應(yīng)用”(Stateless Application)非常好用。但如果想要用容器運行“有狀態(tài)應(yīng)用”，其困難程度就會直線上升。

對于 MySQL 等存儲型分布式應(yīng)用，它的多個實例之間往往有依賴關(guān)系，比如：主從關(guān)系、主備關(guān)系。各個實例往往都會在本地磁盤上保存一份數(shù)據(jù)，當(dāng)實例被殺掉，即便重建出來，實例與數(shù)據(jù)之間的對應(yīng)關(guān)系也已經(jīng)丟失，從而導(dǎo)致應(yīng)用失敗。

這種實例之間有不對等關(guān)系，以及實例對外部數(shù)據(jù)有依賴關(guān)系的應(yīng)用，被稱為“有狀態(tài)應(yīng)用”(Stateful Application)。

Kubernetes 集群中使用節(jié)點本地存儲資源的方式有 emptyDir、hostPath、Local PV 等幾種方式。其中，emptyDir 無法持久化數(shù)據(jù)，hostPath 方式需要手動管理卷的生命周期，運維壓力大。

因此在MySQL場景中，出于性能和運維成本考慮需要使用本地存儲，Local PV 是目前為止唯一的選擇。

??

Local PV 利用機器上的磁盤來存放業(yè)務(wù)需要持久化的數(shù)據(jù)，和遠(yuǎn)端存儲類似，Pod 的數(shù)據(jù)和生命周期是互相獨立的，即使業(yè)務(wù) Pod 被刪除，數(shù)據(jù)也不會丟失。

同時，和遠(yuǎn)端存儲相比，本地存儲可以避免網(wǎng)絡(luò) IO 開銷，擁有更高的讀寫性能，所以分布式文件系統(tǒng)和分布式數(shù)據(jù)庫這類對 IO 要求很高的應(yīng)用非常適合本地存儲。

不同于其他類型的存儲，Local PV 本地存儲強依賴于節(jié)點。換言之，在調(diào)度 Pod 的時候還要考慮到這些 Local PV 對容量和拓?fù)溆虻囊蟆?/p>

MySQL 在使用 Local PV 時，主要用到兩個特性：延遲綁定機制和 volume topology-aware scheduling。延遲綁定機制可以讓 PVC 的綁定推遲到有 MySQL Pod 使用它并且完成調(diào)度后，而 volume topology-aware scheduling 則可以讓 Kubernetes 的調(diào)度器知道卷的拓?fù)浼s束，也就是這個存儲卷只能在特定的區(qū)域或節(jié)點上使用(訪問)，讓調(diào)度器在調(diào)度 Pod 的時候必須考慮這一限制條件。

另外，MySQL 使用的 Local PV 還需通過 nodeAffinity 將 Pod 調(diào)度到正確的 Node 上。

下面展示了 MySQL 使用 Local PV 的簡單配置示例：

--- 
 apiVersion: storage.k8s.io/v1 
 kind: StorageClass 
 metadata: 
   creationTimestamp: null 
   name: local-storage 
 provisioner: kubernetes.io/no-provisioner 
 reclaimPolicy: Delete 
 --- 
 apiVersion: v1 
 kind: PersistentVolumeClaim 
 metadata: 
   annotations: 
     pv.kubernetes.io/bound-by-controller: "yes" 
   creationTimestamp: null 
   labels: 
     app: slightshift-mysql 
     mysql-node: "true" 
   name: data-slightshift-mysql-0 
 spec: 
   accessModes: 
   - ReadWriteOnce 
   resources: 
     requests: 
       storage: 10Gi 
   storageClassName: local-volume-storage 
   volumeName: mysqlha-local-pv-0 
 --- 
 apiVersion: v1 
 kind: PersistentVolume 
 metadata: 
   annotations: 
     helm.sh/hook: pre-install,pre-upgrade 
     helm.sh/resource-policy: keep 
     volume.alpha.kubernetes.io/node-affinity: '{ "requiredDuringSchedulingIgnoredDuringExecution": 
       { "nodeSelectorTerms": [ { "matchExpressions": [ { "key": "kubernetes.io/hostname", 
       "operator": "In", "values": ["yz2-worker004"] } ]} ]} }' 
   labels: 
     pv-label: slightshift-mysql-data-pv 
     type: local 
   name: slightshift-mysql-data-pv-0 
 spec: 
   accessModes: 
   - ReadWriteOnce 
   capacity: 
     storage: 500Gi 
   local: 
     path: /var/lib/ali/mysql 
   persistentVolumeReclaimPolicy: Retain 
   storageClassName: pxc-mysql-data

以上是 Local PV 的基礎(chǔ)用法，而 MySQL 還需考慮節(jié)點的彈性伸縮，這就要求底層存儲也能夠隨著 MySQL 實例伸縮來動態(tài)配置。這里提出兩種解決方案：

在 Kubernetes 集群中引入 LVM Manager，以 DaemonSet 形式運行，負(fù)責(zé)管理每個節(jié)點上的磁盤，匯報節(jié)點磁盤容量和剩余容量、動態(tài)創(chuàng)建 PV 等;再引入 local storage scheduler 調(diào)度模塊，負(fù)責(zé)為使用本地存儲的 Pod 選擇合適(有足夠容量)的節(jié)點。

使用開源方案 OpenEBS：iSCSI 提供底層存儲功能，OpenEBS 管理 iSCSI(目前只支持PV的 ReadWriteOnce 訪問模式)。

自動化選主

SlightShift MySQL 高可用架構(gòu)基于 Raft 強一致協(xié)議實現(xiàn)分布式 MySQL 自動化選主。

??

Raft 使用心跳來觸發(fā)選主，當(dāng) MySQL Server 啟動時狀態(tài)是 follower。當(dāng) server 從 leader 或者 candidate 接收到合法的RPC時，它會保持在 follower 狀態(tài)，leader 會發(fā)送周期性的心跳來表明自己是 leader。

當(dāng)一個 follower 在 election timeout 時間內(nèi)沒有接收到通信，那么它會開始選主。

選主的步驟如下：

• 增加 current term。
• 轉(zhuǎn)成 candidate 狀態(tài)。
• 選自己為主，然后把選主RPC并行地發(fā)送給其他的 server。
• candidate 狀態(tài)會繼續(xù)保持，直到下述三種情況出現(xiàn)。

candidate 會在下述三種情況下退出：

• server 本身成為 leader。
• 其他的 server 選為 leader。
• 一段時間后，沒有 server 成為 leader。

故障轉(zhuǎn)移

在正常運行的主從復(fù)制環(huán)境中，故障轉(zhuǎn)移(Failover)模塊會監(jiān)聽集群狀態(tài)，當(dāng) Master 發(fā)生故障時會自動觸發(fā)故障轉(zhuǎn)移。

故障轉(zhuǎn)移的第一步是自動化選主，自動化選主的邏輯在上面已介紹過;其次是數(shù)據(jù)一致性保障，需最大化保證 Dead Master的 數(shù)據(jù)被同步到 New Master。

??

在將 Master 切換到 New Master 之前，部分 slave 可能還未接收到最新的 relay log events，故障轉(zhuǎn)移模塊也會從最新的 slave 自動識別差異的 relay log events，并 apply 差異的 event 到其他 slaves，以此保證所有 slave 的數(shù)據(jù)都是一致的。

關(guān)于代理層，ProxySQL 會實時探測 MySQL 實例的可讀寫配置，當(dāng) MySQL 實例的可讀寫配置發(fā)生變化時，ProxySQL 會自動調(diào)整MySQL 實例的讀寫分組配置，最終保證在 Failover 之后讀寫分離能正確運行。

??

SlightShift MySQL 自動故障轉(zhuǎn)移的步驟如下：

• HA-Manager 偵測到 Master Server 連接異常，啟動 Failover。
• 嘗試關(guān)閉 Dead Master 以避免腦裂(此步驟可選)。
• 獲取最新數(shù)據(jù) slave 的 end_log_pos，并從 Dead Master 同步 bin-log，最終保證所有 slave 的 end_log_pos 一致。
• 使用 raft 分布式算法選舉 New Master。
• 將 Master 切換到 New Master。
• 回調(diào) ProxySQL 代碼服務(wù)，剔除 Dead Master 配置。
• ProxySQL 網(wǎng)關(guān)檢測到各個 MySQL 實例的可讀寫配置變化，調(diào)整讀寫分離配置。
• 通知切換結(jié)果(郵件、釘釘群機器人)。

SlightShift MySQL 能做到秒級故障轉(zhuǎn)移，5-10秒監(jiān)測到主機故障，5-10秒 apply 差異 relay logs，然后注冊到新的 master，通常10-30秒即可 total downtime。另外，可在配置文件里配置各個 slave 當(dāng)選為 New Master 的優(yōu)先級，這在多機房部署 MySQL 場景下很實用。

故障自動恢復(fù)

宕機的 Master 節(jié)點恢復(fù)時：

• 如果恢復(fù)的節(jié)點重新創(chuàng)建 Mysql Pod 并加入集群，Sentinel 會配置新 Pod 為 Slave，通過獲取當(dāng)前 Master Mysql 的 log file 和 Position 來實現(xiàn)新加入 Slave 的數(shù)據(jù)同步。
• 如果恢復(fù)的節(jié)點中 Mysql Pod 依然存在且可用，Sentinel 此時會發(fā)現(xiàn)2個 Label 為 master 的 Pod。Sentinel 會依然使用宕機期間選擇的新 Master，且把恢復(fù)的 Master 強制設(shè)置為Slave，并開啟只讀模式。

宕機的 Slave 節(jié)點恢復(fù)時：

• 如果恢復(fù)節(jié)點重新創(chuàng)建 Mysql Pod 并加入集群，Sentinel會配置新 Pod 為Slave，通過獲取當(dāng)前 Master Mysql 的 log file 和 Position 來實現(xiàn)新加入 Slave 的數(shù)據(jù)同步。
• 如果恢復(fù)的節(jié)點中 Mysql Pod 依然存在且可用，調(diào)度器不會執(zhí)行操作，proxysql-service 會監(jiān)測到新加入的 Slave，并將其加入到 endpoints 列表。

狀態(tài)管理

狀態(tài)管理并非新鮮話題，它為中心化系統(tǒng)分發(fā)一致的狀態(tài)，確保分布式系統(tǒng)總是朝預(yù)期的狀態(tài)收斂，是中心化系統(tǒng)的基石之一 。

MySQL 服務(wù)由一個 Master 節(jié)點和多個從 Master 上異步復(fù)制數(shù)據(jù)的 Slave 節(jié)點組成，即一主多從復(fù)制模型。其中，Master 節(jié)點可用來處理用戶的讀寫請求，Slave 節(jié)點只能用來處理用戶的讀請求。

為了部署這樣的有狀態(tài)服務(wù)，除了 StatefulSet 之外，還需要使用許多其它類型的 k8s 資源對象，包括 ConfigMap、Headless Service、ClusterIP Service 等。正是它們間的相互配合，才能讓 MySQL 這樣的有狀態(tài)服務(wù)有條件運行在 k8s 之上。

在 MySQL 集群中，狀態(tài)轉(zhuǎn)移最常發(fā)生在 Master 發(fā)生故障，集群進(jìn)行故障轉(zhuǎn)移期間。當(dāng) Master 發(fā)生故障宕機時會自動觸發(fā)選主邏輯，選主結(jié)束后會進(jìn)行故障切換，直至 New Master 正常提供讀寫服務(wù)，故障轉(zhuǎn)移過程是需要時間的，在故障轉(zhuǎn)移過程中 MySQL 服務(wù)會處于不可寫狀態(tài)。

在故障轉(zhuǎn)移期間，Dead Master 實例會被 k8s 集群自動拉起，Dead Master 被拉起后會認(rèn)為自己是合法的 Master，這樣會造成集群中同時存在兩個 Master，寫請求很可能會被隨機分配到兩個 Master 節(jié)點，從而造成腦裂問題。

為了解決這種場景下的腦裂問題，我們引入了 InitContainer 機制，再配合 Sentinel 就能很好的解決該問題。

InitContainer，顧名思義，在容器啟動的時候會先啟動一個或多個容器去完成一些前置性工作，如果有多個，Init Container將按照指定的順序依次執(zhí)行，只有所有的 InitContainer 執(zhí)行完后主容器才會啟動。

我們在每一個 MySQL 的實例中都加入了 InitContainer，在 Dead Master 被 k8s 自動拉起之后，InitContainer 會自動檢測集群中是否處于 Failover 階段，如果處于Failover 階段會進(jìn)入 Sleep 輪詢狀態(tài)，直至 Failover 結(jié)束。

??

當(dāng) Failover 結(jié)束后，Sentinel 檢測到 Dead Master 被拉起，會自動將 Dead Master 設(shè)置為 New Master 的 Slave 節(jié)點，以此來完成一次完整的 Failover 過程，并避免集群出現(xiàn)腦裂問題。

聲明式運維

我們在使用 k8s 時，一般會通過 k8s 的 Resource 滿足應(yīng)用管理的需求：

• 通過 Deployment、StatefulSet 等 workload 部署服務(wù)。
• 通過 Service、Ingress 管理對服務(wù)的訪問。
• 通過 ConfigMap、Secrets 管理服務(wù)的配置。
• etc.

上述 Resource 表征 User 的期望，kube-controller-mananger 中的 Controller 會監(jiān)聽 Resource Events 并執(zhí)行相應(yīng)的動作，來實現(xiàn) User 的期望。

這種操作方式給應(yīng)用管理帶來了很大的便利，User 可以通過聲明式的方式管理應(yīng)用，不用再關(guān)心如何使用傳統(tǒng)的 HTTP API、RPC 調(diào)用等。

Controller 會通過各種機制來確保實現(xiàn) User 的期望，如通過不斷檢測 Object 的狀態(tài)來驅(qū)使 Object 當(dāng)前狀態(tài)符合用戶期望，這種運維模式我們稱之為聲明式運維。

但如果僅僅使用 k8s 提供的基礎(chǔ)類型，對于 MySQL 這類復(fù)雜應(yīng)用來說運維成本依然很高。如果能將聲明式運維的模式進(jìn)行擴展延伸到 MySQL 應(yīng)用，會極大程度降低 MySQL 應(yīng)用的部署和運維成本。

??

為了解決這個問題，slightshift-mysql-operator 應(yīng)運而生。

slightshift-mysql-operator 本質(zhì)上是 Resource + Controller：

• Resource

• 自定義資源(CRD, Custom Resource Definitions)，為 User 提供一種聲明式的方式描述對服務(wù)的期望。

• Controller

實現(xiàn) Resource 中 User 的期望。

• slightshift-mysql-operator 通過組合 k8s 中已有的概念，極大降低了部署和運維 MySQL 的成本：

User 通過類似使用 Deployment 的方式描述對 MySQL 的需求

在 k8s 上部署 MySQL 應(yīng)用的姿勢與 k8s 官方資源的操作方式相同。

由 slightshift-mysql-operator 的 Controller 監(jiān)聽、處理事件請求

• 監(jiān)聽 Resource Events。
• 針對不同類型 (ADD/UPDATE/DELETE) 的 Events 執(zhí)行相應(yīng)的動作。
• 不斷檢測 Object 的狀態(tài)來執(zhí)行動作，驅(qū)使服務(wù)的狀態(tài)符合 User 期望。

??

slightshift-mysql-operator 的設(shè)計理念：

• 聲明式配置：提升可讀性和運維效率，降低運維成本。
• 最終一致性：動態(tài)調(diào)整集群狀態(tài)實現(xiàn)最終一致性。

??

slightshift-mysql-operator 極大程度上降低了在 Kubernetes 集群中使用和管理 MySQL 應(yīng)用的成本，User 可以通過聲明式的 CR 創(chuàng)建應(yīng)用，Vendor 可將管理應(yīng)用的專業(yè)知識封裝，對 User 透明。

slightshift-mysql-operator 在架構(gòu)層面上使用分層設(shè)計，簡化了架構(gòu)復(fù)雜度，同時盡可能降低了 MySQL 多個集群實例間相互干擾，實現(xiàn)各個實例的自治。

部署結(jié)構(gòu)如下圖所示：

??

備份與恢復(fù)

為保證數(shù)據(jù)安全性，還需對數(shù)據(jù)進(jìn)行定期備份，保證用戶數(shù)據(jù)在極端情況下(集群崩潰)時數(shù)據(jù)可恢復(fù)。

通過 Cronjob 對 Mysql 數(shù)據(jù)進(jìn)行備份：

• 在 Kubernetes 集群中創(chuàng)建 Cronjob，Cronjob 會定期進(jìn)行數(shù)據(jù)備份。
• 備份數(shù)據(jù)會被打上時間標(biāo)簽，并上傳到對象存儲服務(wù)器(Ceph、Minio)。

通過創(chuàng)建 Job 對 Mysql 進(jìn)行數(shù)據(jù)恢復(fù)：

• 在集群中創(chuàng)建恢復(fù) Job，Job 根據(jù) SNAP_SHOT 到存儲服務(wù)器(OSS、Minio)上獲取備份數(shù)據(jù)。
• Job 把數(shù)據(jù)恢復(fù)到 Mysql Master 實例，同時 Slave 會完成數(shù)據(jù)同步。

五 技術(shù)演進(jìn)

唯有進(jìn)化，才能站到食物鏈頂端。

根據(jù) Gartner 報告預(yù)測，數(shù)據(jù)庫云平臺市場份額將會在下一個五年中翻倍，而70%的用戶將開始使用 dbPaaS 數(shù)據(jù)庫云平臺。因此，為了滿足各類應(yīng)用程序?qū)?shù)據(jù)庫云平臺的需求，同時為了減少私有云部署中對大量不同類型數(shù)據(jù)存儲產(chǎn)品的運維復(fù)雜性，數(shù)據(jù)庫的架構(gòu)演進(jìn)將是未來十年數(shù)據(jù)庫轉(zhuǎn)型的主要方向之一。

云原生數(shù)據(jù)庫是未來數(shù)據(jù)庫發(fā)展的一個重要方向，云原生數(shù)據(jù)庫架構(gòu)隨著云化要求也需要進(jìn)行相應(yīng)的迭代，未來在云原生數(shù)據(jù)庫架構(gòu)的演進(jìn)還會隨著需求的變化而持續(xù)發(fā)展。

??

六 未來展望

中間件作為構(gòu)筑上層業(yè)務(wù)系統(tǒng)的基石和核心技術(shù)，具有高可靠性、高擴展性、強專業(yè)性等特點。

關(guān)于未來，由于中間件的這些特點，未來云原生中間件會向著規(guī)范化、構(gòu)建化、松耦合和平臺化的方向發(fā)展。平臺化能夠更快速響應(yīng)業(yè)務(wù)變化，為業(yè)務(wù)的橫向發(fā)展提供集中的技術(shù)解決方案。

??

從終態(tài)來看，我們想做一個企業(yè)級云原生中間件 PaaS 平臺，涵蓋基礎(chǔ)中間件的部署、配置、升級、伸縮、故障處理等自動化能力。

首先談?wù)勎覍χ虚g件平臺的理解，中間件平臺應(yīng)該是一系列中間件解決方案集合的能力開放式技術(shù)中臺，它形成了完整、久經(jīng)考驗、開放和組件化的解決方案，旨在為復(fù)雜多變的上層業(yè)務(wù)領(lǐng)域提供穩(wěn)定可靠的計算、存儲服務(wù)。

任何一個平臺型產(chǎn)品的發(fā)展歷程，都不是一開始就做平臺的，而是先有業(yè)務(wù)需求，為了解決實際業(yè)務(wù)需求而積累了某些領(lǐng)域的知識，進(jìn)而成為了這些領(lǐng)域的專家，最終再向平臺轉(zhuǎn)變。換句話說，平臺是一個持續(xù)積累的過程，也是一個水到渠成的過程。

??

在企業(yè)信息平臺構(gòu)建過程中，有效、合理、規(guī)范化的利用中間件平臺來快速構(gòu)建上層業(yè)務(wù)系統(tǒng)，可以為企業(yè)及時響應(yīng)需求變化提供有力保障，形成企業(yè)的集約化管理，進(jìn)而提升企業(yè)核心力量獲得可持續(xù)競爭的優(yōu)勢。

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

??戳這里，看該作者更多好文??