分布式服务解决方案
1 微服務(wù)的發(fā)展
微服務(wù)倡導(dǎo)將復(fù)雜的單體應(yīng)用拆分為若干個功能簡單、松耦合的服務(wù),這樣可以降低開發(fā)難度、增強擴展性、便于敏捷開發(fā)。當前被越來越多的開發(fā)者推崇,很多互聯(lián)網(wǎng)行業(yè)巨頭、開源社區(qū)等都開始了微服務(wù)的討論和實踐。Hailo有160個不同服務(wù)構(gòu)成,NetFlix有大約600個服務(wù)。國內(nèi)方面,阿里巴巴、騰訊、360、京東、58同城等很多互聯(lián)網(wǎng)公司都進行了微服務(wù)化實踐。當前微服務(wù)的開發(fā)框架也非常多,比較著名的有Dubbo、SpringCloud、thrift 、grpc等。
2 微服務(wù)落地存在的問題
雖然微服務(wù)現(xiàn)在如火如荼,但對其實踐其實仍處于探索階段。很多中小型互聯(lián)網(wǎng)公司,鑒于經(jīng)驗、技術(shù)實力等問題,微服務(wù)落地比較困難。如著名架構(gòu)師Chris Richardson所言,目前存在的主要困難有如下幾方面:
1)單體應(yīng)用拆分為分布式系統(tǒng)后,進程間的通訊機制和故障處理措施變的更加復(fù)雜。
2)系統(tǒng)微服務(wù)化后,一個看似簡單的功能,內(nèi)部可能需要調(diào)用多個服務(wù)并操作多個數(shù)據(jù)庫實現(xiàn),服務(wù)調(diào)用的分布式事務(wù)問題變的非常突出。
3)微服務(wù)數(shù)量眾多,其測試、部署、監(jiān)控等都變的更加困難。
隨著RPC框架的成熟,第一個問題已經(jīng)逐漸得到解決。例如dubbo可以支持多種通訊協(xié)議,springcloud可以非常好的支持restful調(diào)用。對于第三個問題,隨著docker、devops技術(shù)的發(fā)展以及各公有云paas平臺自動化運維工具的推出,微服務(wù)的測試、部署與運維會變得越來越容易。
而對于第二個問題,現(xiàn)在還沒有通用方案很好的解決微服務(wù)產(chǎn)生的事務(wù)問題。分布式事務(wù)已經(jīng)成為微服務(wù)落地最大的阻礙,也是最具挑戰(zhàn)性的一個技術(shù)難題。 為此,本文將深入和大家探討微服務(wù)架構(gòu)下,分布式事務(wù)的各種解決方案,并重點為大家解讀阿里巴巴提出的分布式事務(wù)解決方案----GTS。該方案中提到的GTS是全新一代解決微服務(wù)問題的分布式事務(wù)互聯(lián)網(wǎng)中間件。
3 SOA分布式事務(wù)解決方案
3.1 基于XA協(xié)議的兩階段提交方案
交易中間件與數(shù)據(jù)庫通過 XA 接口規(guī)范,使用兩階段提交來完成一個全局事務(wù), XA 規(guī)范的基礎(chǔ)是兩階段提交協(xié)議。
第一階段是表決階段,所有參與者都將本事務(wù)能否成功的信息反饋發(fā)給協(xié)調(diào)者;第二階段是執(zhí)行階段,協(xié)調(diào)者根據(jù)所有參與者的反饋,通知所有參與者,步調(diào)一致地在所有分支上提交或者回滾。
兩階段提交方案應(yīng)用非常廣泛,幾乎所有商業(yè)OLTP數(shù)據(jù)庫都支持XA協(xié)議。但是兩階段提交方案鎖定資源時間長,對性能影響很大,基本不適合解決微服務(wù)事務(wù)問題。
3.2 TCC方案
TCC方案在電商、金融領(lǐng)域落地較多。TCC方案其實是兩階段提交的一種改進。其將整個業(yè)務(wù)邏輯的每個分支顯式的分成了Try、Confirm、Cancel三個操作。Try部分完成業(yè)務(wù)的準備工作,confirm部分完成業(yè)務(wù)的提交,cancel部分完成事務(wù)的回滾。基本原理如下圖所示。
事務(wù)開始時,業(yè)務(wù)應(yīng)用會向事務(wù)協(xié)調(diào)器注冊啟動事務(wù)。之后業(yè)務(wù)應(yīng)用會調(diào)用所有服務(wù)的try接口,完成一階段準備。之后事務(wù)協(xié)調(diào)器會根據(jù)try接口返回情況,決定調(diào)用confirm接口或者cancel接口。如果接口調(diào)用失敗,會進行重試。
TCC方案讓應(yīng)用自己定義數(shù)據(jù)庫操作的粒度,使得降低鎖沖突、提高吞吐量成為可能。 當然TCC方案也有不足之處,集中表現(xiàn)在以下兩個方面:
對應(yīng)用的侵入性強。業(yè)務(wù)邏輯的每個分支都需要實現(xiàn)try、confirm、cancel三個操作,應(yīng)用侵入性較強,改造成本高。
實現(xiàn)難度較大。需要按照網(wǎng)絡(luò)狀態(tài)、系統(tǒng)故障等不同的失敗原因?qū)崿F(xiàn)不同的回滾策略。為了滿足一致性的要求,confirm和cancel接口必須實現(xiàn)冪等。
上述原因?qū)е耇CC方案大多被研發(fā)實力較強、有迫切需求的大公司所采用。微服務(wù)倡導(dǎo)服務(wù)的輕量化、易部署,而TCC方案中很多事務(wù)的處理邏輯需要應(yīng)用自己編碼實現(xiàn),復(fù)雜且開發(fā)量大。
3.3 基于消息的最終一致性方案
消息一致性方案是通過消息中間件保證上、下游應(yīng)用數(shù)據(jù)操作的一致性。基本思路是將本地操作和發(fā)送消息放在一個事務(wù)中,保證本地操作和消息發(fā)送要么兩者都成功或者都失敗。下游應(yīng)用向消息系統(tǒng)訂閱該消息,收到消息后執(zhí)行相應(yīng)操作。
消息方案從本質(zhì)上講是將分布式事務(wù)轉(zhuǎn)換為兩個本地事務(wù),然后依靠下游業(yè)務(wù)的重試機制達到最終一致性。基于消息的最終一致性方案對應(yīng)用侵入性也很高,應(yīng)用需要進行大量業(yè)務(wù)改造,成本較高。
4 GTS–分布式事務(wù)解決方案
GTS是一款分布式事務(wù)中間件,由阿里巴巴中間件部門研發(fā),可以為微服務(wù)架構(gòu)中的分布式事務(wù)提供一站式解決方案。
更多GTS資料請訪問創(chuàng)始人微博。
4.1 GTS的核心優(yōu)勢
性能超強
GTS通過大量創(chuàng)新,解決了事務(wù)ACID特性與高性能、高可用、低侵入不可兼得的問題。單事務(wù)分支的平均響應(yīng)時間在2ms左右,3臺服務(wù)器組成的集群可以支撐3萬TPS以上的分布式事務(wù)請求。
應(yīng)用侵入性極低
GTS對業(yè)務(wù)低侵入,業(yè)務(wù)代碼最少只需要添加一行注解(@TxcTransaction)聲明事務(wù)即可。業(yè)務(wù)與事務(wù)分離,將微服務(wù)從事務(wù)中解放出來,微服務(wù)關(guān)注于業(yè)務(wù)本身,不再需要考慮反向接口、冪等、回滾策略等復(fù)雜問題,極大降低了微服務(wù)開發(fā)的難度與工作量。
完整解決方案
GTS支持多種主流的服務(wù)框架,包括EDAS,Dubbo,Spring Cloud等。
有些情況下,應(yīng)用需要調(diào)用第三方系統(tǒng)的接口,而第三方系統(tǒng)沒有接入GTS。此時需要用到GTS的MT模式。GTS的MT模式可以等價于TCC模式,用戶可以根據(jù)自身業(yè)務(wù)需求自定義每個事務(wù)階段的具體行為。MT模式提供了更多的靈活性,可能性,以達到特殊場景下的自定義優(yōu)化及特殊功能的實現(xiàn)。
容錯能力強
GTS解決了XA事務(wù)協(xié)調(diào)器單點問題,實現(xiàn)真正的高可用,可以保證各種異常情況下的嚴格數(shù)據(jù)一致。
4.2 GTS的應(yīng)用場景
GTS可應(yīng)用在涉及服務(wù)調(diào)用的多個領(lǐng)域,包括但不限于金融支付、電信、電子商務(wù)、快遞物流、廣告營銷、社交、即時通信、手游、視頻、物聯(lián)網(wǎng)、車聯(lián)網(wǎng)等,詳細介紹可以閱讀 《GTS–阿里巴巴分布式事務(wù)全新解決方案》一文。
4.3 GTS與微服務(wù)的集成
GTS包括客戶端(GTS Client)、資源管理器(GTS RM)和事務(wù)協(xié)調(diào)器(GTS Server)三個部分。GTS Client主要用來界定事務(wù)邊界,完成事務(wù)的發(fā)起與結(jié)束。GTS RM完成事務(wù)分支的創(chuàng)建、提交、回滾等操作。GTS Server主要負責分布式事務(wù)的整體推進,事務(wù)生命周期的管理。GTS和微服務(wù)集成的結(jié)構(gòu)圖如下所示,GTS Client需要和業(yè)務(wù)應(yīng)用集成部署,RM與微服務(wù)集成部署。
4.4 GTS的輸出形式
GTS目前有三種輸出形式:公有云輸出、公網(wǎng)輸出、專有云輸出。
4.4.1 公有云輸出
這種輸出形式面向阿里云用戶。如果用戶的業(yè)務(wù)系統(tǒng)已經(jīng)部署到阿里云上,可以申請開通公有云GTS。開通后業(yè)務(wù)應(yīng)用即可通過GTS保證服務(wù)調(diào)用的一致性。這種使用場景下,業(yè)務(wù)系統(tǒng)和GTS間的網(wǎng)絡(luò)環(huán)境比較理想,達到很好性能。
具體使用樣例使用參見4.7節(jié)GTS的工程樣例。
4.4.3 專有云輸出
這種形式主要面向于已建設(shè)了自己專有云平臺的大用戶,GTS可以直接部署到用戶的專有云上,為專有云提供分布式事務(wù)服務(wù)。目前已經(jīng)有10多個特大型企業(yè)的專有云使用GTS解決分布式事務(wù)難題,性能與穩(wěn)定性經(jīng)過了用戶的嚴格檢測。
4.5 GTS的使用方式
GTS對應(yīng)用的侵入性非常低,使用也很簡單。下面以訂單存儲應(yīng)用為例說明。訂單業(yè)務(wù)應(yīng)用通過調(diào)用訂單服務(wù)和庫存服務(wù)完成訂單業(yè)務(wù),服務(wù)開發(fā)框架為Dubbo。
4.5.1 訂單業(yè)務(wù)應(yīng)用
在業(yè)務(wù)函數(shù)外圍使用@TxcTransaction注解即可開啟分布式事務(wù)。Dubbo應(yīng)用通過隱藏參數(shù)將GTS的事務(wù)xid傳播到服務(wù)端。
4.5.2 服務(wù)提供者
更新庫存方法
4.6 GTS的應(yīng)用情況
GTS目前已經(jīng)在淘寶、天貓、阿里影業(yè)、淘票票、阿里媽媽、1688等阿里各業(yè)務(wù)系統(tǒng)廣泛使用,經(jīng)受了16年和17年兩年雙十一海量請求的考驗。某線上業(yè)務(wù)系統(tǒng)最高流量已達十萬TPS(每秒鐘10萬筆事務(wù))。
GTS在公有云和專有云輸出后,已經(jīng)有了100多個線上用戶,很多用戶通過GTS解決SpringCloud、Dubbo、Edas等服務(wù)框架的分布式事務(wù)問題。業(yè)務(wù)領(lǐng)域涉及電力、物流、ETC、煙草、金融、零售、電商、共享出行等十幾個行業(yè),得到用戶的一致認可
上圖是GTS與SpringCloud集成,應(yīng)用于某共享出行系統(tǒng)。業(yè)務(wù)共享出行場景下,通過GTS支撐物聯(lián)網(wǎng)系統(tǒng)、訂單系統(tǒng)、支付系統(tǒng)、運維系統(tǒng)、分析系統(tǒng)等系各統(tǒng)應(yīng)用的數(shù)據(jù)一致性,保證海量訂單和數(shù)千萬流水的交易。
4.7 GTS的工程樣例
GTS的公有云樣例可參考阿里云網(wǎng)站。在公網(wǎng)環(huán)境下提供sample-txc-simple和sample-txc-dubbo兩個樣例工程。
sample-txc-simple http://txc-console.oss-cn-beijing.aliyuncs.com/sample/sample-txc-simple.zip
sample-txc-dubbo http://txc-console.oss-cn-beijing.aliyuncs.com/sample/sample-txc-dubbo.zip
4.7.1 sample-txc-simple樣例
4.7.1.1 樣例業(yè)務(wù)邏輯
該樣例是GTS的入門sample,案例的業(yè)務(wù)邏輯是從A賬戶轉(zhuǎn)賬給B賬戶,其中A和B分別位于兩個MySQL數(shù)據(jù)庫中,使用GTS事務(wù)保證A和B賬戶錢的總數(shù)始終不變。
4.7.1.2 樣例搭建方法
安裝MySQL,創(chuàng)建兩個數(shù)據(jù)庫db1和db2。在db1和db2中分別創(chuàng)建txc_undo_log表(SQL腳本見4.7.3)。在db1庫中創(chuàng)建user_money_a表,在db2庫中創(chuàng)建user_money_b表。
將sample-txc-simple文件下載到本地,樣例中已經(jīng)包含了GTS的SDK。
打開sample-txc-simple/src/main/resources目錄下的txc-client-context.xml,將數(shù)據(jù)源的url、username、password修改為實際值。
在sample-txc-simple目錄下執(zhí)行build.sh編譯本工程。編譯完成后執(zhí)行run.sh。
4.7.2 sample-txc-dubbo 樣例
4.7.2.1 樣例業(yè)務(wù)邏輯
本案例模擬了用戶下訂單、減庫存的業(yè)務(wù)邏輯。客戶端(Client)通過調(diào)用訂單服務(wù)(OrderService)創(chuàng)建訂單,之后通過調(diào)用庫存服務(wù)(StockService)扣庫存。其中訂單服務(wù)讀寫訂單數(shù)據(jù)庫,庫存服務(wù)讀寫庫存數(shù)據(jù)庫。由 GTS 保證跨服務(wù)事務(wù)的一致性。
4.7.2.2 樣例搭建方法
安裝MySQL,創(chuàng)建兩個數(shù)據(jù)庫db1和db2。在db1和db2中分別創(chuàng)建txc_undo_log表。在db1庫中創(chuàng)建orders表,在db2庫中創(chuàng)建stock表。
將樣例文件sample-txc-dubbo下載到本地機器,樣例中已經(jīng)包含了GTS的SDK。
打開sample-txc-dubbo/src/main/resources目錄,將dubbo-order-service.xml、dubbo-stock-service.xml兩個文件中數(shù)據(jù)源的url、username、password修改為實際值。
a. 編譯程序
在工程根目錄執(zhí)行 build.sh 命令,編譯工程。編譯后會在 sample-txc-dubbo/client/bin 目錄下生成 order_run.sh、stock_run.sh、client_run.sh 三個運行腳本對應(yīng)訂單服務(wù)、庫存服務(wù)以及客戶端。
b. 運行程序
在根目錄執(zhí)行run.sh,該腳本會依次啟動order_run.sh(訂單服務(wù))、stock_run.sh(庫存服務(wù))和client_run.sh(客戶端程序)。
4.7.2.3 其他說明
樣例使用Multicast注冊中心的聲明方式。如果本機使用無線網(wǎng)絡(luò),dubbo服務(wù)在綁定地址時有可能獲取ipv6地址,可以通過jvm啟動參數(shù)禁用。
方法是配置jvm啟動參數(shù) -Djava.net.preferIPv4Stack=true。
4.7.3 SQL
4.7.3.1 建表 txc_undo_log
CREATE TABLE txc_undo_log (
id bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘主鍵’,
gmt_create datetime NOT NULL COMMENT ‘創(chuàng)建時間’,
gmt_modified datetime NOT NULL COMMENT ‘修改時間’,
xid varchar(100) NOT NULL COMMENT ‘全局事務(wù)ID’,
branch_id bigint(20) NOT NULL COMMENT ‘分支事務(wù)ID’,
rollback_info longblob NOT NULL COMMENT ‘LOG’,
status int(11) NOT NULL COMMENT ‘狀態(tài)’,
server varchar(32) NOT NULL COMMENT ‘分支所在DB IP’,
PRIMARY KEY (id),
KEY unionkey (xid,branch_id)
) ENGINE=InnoDB AUTO_INCREMENT=211225994 DEFAULT CHARSET=utf8 COMMENT=‘事務(wù)日志表’;
4.7.3.2 建表 user_money_a
CREATE TABLE user_money_a (
id int(11) NOT NULL AUTO_INCREMENT,
money int(11) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
4.7.3.3 建表 user_money_b
CREATE TABLE user_money_b (
id int(11) NOT NULL AUTO_INCREMENT,
money int(11) DEFAULT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;
4.7.3.4 建表 orders
CREATE TABLE orders (
id bigint(20) NOT NULL AUTO_INCREMENT,
user_id varchar(255) NOT NULL,
product_id int(11) NOT NULL,
number int(11) NOT NULL,
gmt_create timestamp NOT NULL,
PRIMARY KEY (id)
) ENGINE=MyISAM AUTO_INCREMENT=351 DEFAULT CHARSET=utf8
4.7.3.5 建表 stock
CREATE TABLE stock (
product_id int(11) NOT NULL,
price float NOT NULL,
amount int(11) NOT NULL,
PRIMARY KEY (product_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
總結(jié)
- 上一篇: python随机生成红包_自制Pytho
- 下一篇: 零基础报成都java培训班需要学多久才能