近日，2017云棲大會·深圳峰會如期舉行，多項阿里云新產品對外發(fā)布。在企業(yè)級互聯(lián)網架構分會場，來自阿里中間件（Aliware）的技術專家及合作伙伴，為現(xiàn)場參會嘉賓帶來最新的傳統(tǒng)IT架構到企業(yè)級互聯(lián)網架構跨越式升級、實現(xiàn)互聯(lián)網轉型的產品及解決方案。其中高級技術專家姜宇在分享中帶來的Aliware新產品—全局事務服務（GlobalTransactionService，簡稱GTS），在分布式事務處理上帶來的高性能和技術創(chuàng)新令到場參會的各路技術專家眼前一亮。

Aliware新成員—全局事務服務GTS技術分享現(xiàn)場

分布式事務背景

OLTP領域中很多業(yè)務場景都會面臨事務一致性的需求，傳統(tǒng)業(yè)務系統(tǒng)常以單體應用形式存在，只需借助特有數(shù)據(jù)訪問技術和框架，結合關系型數(shù)據(jù)庫自帶的事務管理機制來實現(xiàn)事務一致性的要求。而目前大型互聯(lián)網應用和平臺往往是由一系列分布式系統(tǒng)構建而成，平臺和技術架構也是流派紛呈。

尤其是微服務架構盛行的今天，一個看似簡單的功能，內部可能需要調用多個“服務”并操作多個數(shù)據(jù)庫或分片來實現(xiàn)，單一技術手段和解決方案已無法滿足這些復雜應用場景。因此，分布式系統(tǒng)架構中分布式事務是一個繞不過去的挑戰(zhàn)。什么是分布式事務？簡單的說，就是一次大操作由不同小操作組成，這些小操作分布在不同服務器上，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。

本質上來說，分布式事務就是為了保證不同數(shù)據(jù)庫或消息系統(tǒng)的數(shù)據(jù)一致性。

分布式事務三大難題：一致性、高性能和易用性

分布式系統(tǒng)的事務一致性本身是一個技術難題，沒有一種簡單完美的方案能夠應對所有場景，很難兼顧事務一致性，高性能與易用性。三者缺一，則適用場景大大受限，實用價值不高。

首先是一致性：要求在各種異常情況下保證數(shù)據(jù)是強一致的。目前最常見的一致性解決方案是最終一致性方案，通常是結合消息中間件實現(xiàn)，在互聯(lián)網企業(yè)中廣泛使用。最終一致性實現(xiàn)方案比較復雜，開發(fā)、運維成本高，并且與強一致相比，業(yè)務上是受很多限制的。

其次是高性能：目前基于XA協(xié)議的兩階段提交是最常見的分布式事務解決方案，但XA類產品的典型不足是性能低下，這對于互聯(lián)網大并發(fā)需求下的多數(shù)企業(yè)是無法接受的。國外具有幾十年歷史和技術沉淀的基于XA模型的商用分布式事務產品，在相同軟硬件條件下，開啟分布式事務后吞吐經常有數(shù)量級的下降。

第三是易用性：為了滿足一致性和高性能要求，出現(xiàn)了一些特定場景下的分布式事務方案，但通常會限制用戶用法，對業(yè)務侵入性強，無法做到簡單易用，帶來更多開發(fā)成本。

世界級應用場景，催生世界級分布式事務解決方案

早期的阿里巴巴集團隨著業(yè)務高速發(fā)展，內部不斷涌現(xiàn)各種典型的分布式事務需求，比如阿里內部廣泛使用的TDDL分庫分表所帶來的分庫間數(shù)據(jù)不一致問題，HSF服務化后所帶來的服務鏈路上數(shù)據(jù)不一致問題等。在這個過程中，各業(yè)務技術團隊利用現(xiàn)有中間件技術手段實現(xiàn)分布式事務處理，但這些手段都較為復雜，工作量大，對應用侵入嚴重，有些適用場景還有限制。

2014年5月開始，阿里中間件（Aliware）內部命名為TXC的分布式事務中間件開始研發(fā)，同年10月1.0版本發(fā)布，分布式事務功能已經具備，但性能還有局限，只適合于吞吐量較小的場景；2015年12月，TXC2.0版本發(fā)布，相比1.0版本性能提升10倍以上，在阿里內部多條業(yè)務線得到部署。

通過部署TXC，應用只需極少的代碼改造和配置，即可享受分布式事務帶來的便利。TXC作為阿里內部為解決分布式數(shù)據(jù)強一致性問題而研發(fā)的分布式事務中間件，徹底解決了分布式事務數(shù)據(jù)一致性的問題，簡單易用，先后在淘寶，菜鳥，淘票票和村淘等多個業(yè)務的核心系統(tǒng)上得到部署和驗證。

順應云時代潮流，GTS應運而生

從2016年年中開始，在阿里內部一直接受錘煉的分布式事務中間件TXC在2.0版本后，隨著阿里中間件上云熱潮，開始通過專有云輸出，并得到了市場極大認可，適用場景得到進一步拓展，全面涵蓋電商、物流、金融、零售、政企、游戲、文娛等領域。2017年2月，TXC2.0通過阿里云對外公測，外部改名為全局事務服務（GlobalTransactionService，簡稱GTS）。

GTS總體架構圖

在整體架構方面，GTS由三個組件組成：客戶端（GTS-Client），資源管理器（RM），事務協(xié)調器（GTS-Server）?？蛻舳伺c事務協(xié)調器間，資源管理器與事務協(xié)調器間都是通過GTS分布式事務協(xié)議進行通信?？蛻舳素撠熃缍ㄊ聞者吔纾_啟/提交/回滾全局事務，資源管理器負責管理資源，支持的資源包括：DRDS，Oracle，MySQL，RDS，PostgreSQL，H2，MQ，后續(xù)計劃根據(jù)實際業(yè)務需求支持更多類型資源。事務協(xié)調器，也就是GTS服務器，是分布式事務處理的大腦，負責協(xié)調整個事務過程。GTS事務通過RPC框架和消息中間件進行事務傳遞，把整個業(yè)務調用鏈路或者消息鏈路串成一個分布式事務，極大簡化應用開發(fā)。

在高可用方面，GTS支持同城容災與兩地三中心容災，可保證各種異常情況下的數(shù)據(jù)一致。在易用性方面，GTS對業(yè)務無侵入，真正做到業(yè)務與事務分離，開發(fā)者可以集中精力于業(yè)務本身。在技術創(chuàng)新方面，GTS也走在了行業(yè)前沿。項目負責人阿里高級技術專家姜宇（花名于皋）擁有13項分布式事務的核心技術專利，研發(fā)團隊的技術專家張松樹也有3篇專利。通過大量的專利技術，精妙的算法，與精巧的分布式事務私有協(xié)議，GTS取得了超強的性能。

另外，在部分嚴苛的行業(yè)應用場景，比如金融用戶的資管項目分布式事務場景下，GTS也經歷了嚴格的測試，按照用戶要求順利完成功能性、穩(wěn)定性和性能測試。下圖是一個典型性能測試場景數(shù)據(jù)，從實測數(shù)據(jù)可以看出，開啟GTS（TXC）分布式事務后性能下降不明顯。目前GTS已經在資金業(yè)務上有實際應用，線上大量真實數(shù)據(jù)驗證了GTS的高效可靠。

GTS典型性能測試場景數(shù)據(jù)

性能優(yōu)異，業(yè)務場景廣泛

作為新一代企業(yè)級分布式事務服務產品，全局事務服務GTS兼顧了事務一致性，高性能與易用性。在滿足事務ACID的前提下，普通配置的單服務器就可以達到15000TPS以上的超強性能（兩個小時內完成1億多筆業(yè)務），3臺8核16G內存虛機組成的服務器集群可以支撐1萬TPS以上的分布式事務，與同類產品相比，性能優(yōu)勢明顯。另外簡單易用對業(yè)務無侵入，為廣大企業(yè)大幅降低開發(fā)成本，業(yè)務場景非常廣泛：

1、跨多分庫的分布式數(shù)據(jù)庫事務場景：關系型數(shù)據(jù)庫普遍支持事務，能夠滿足事務內的SQL要么全部成功、要么全部失敗。但客戶從單機數(shù)據(jù)庫往分布式數(shù)據(jù)庫遷移的情況下，原有的一個事務往往會被拆分為多個分庫上的事務。由于網絡的不可靠性，容易出現(xiàn)部分分庫上成功，部分分庫上失敗的情況。GTS結合DRDS可徹底解決了這一問題。

2、跨多數(shù)據(jù)庫的事務場景：復雜的業(yè)務系統(tǒng)經常會使用多個數(shù)據(jù)庫，甚至多種類型的數(shù)據(jù)庫，比如企業(yè)中Oracle，MySQL和其他關系型數(shù)據(jù)庫并存的情況時有發(fā)生。業(yè)務同時操作多個數(shù)據(jù)庫的情況下，一旦發(fā)生先提交的事務成功、后提交的事務失敗，就很難解決。GTS支持各種常見關系型數(shù)據(jù)庫，并提供多數(shù)據(jù)庫間的事務保證。

3、跨數(shù)據(jù)庫系統(tǒng)、消息系統(tǒng)的事務場景：消息系統(tǒng)被廣泛地用于系統(tǒng)間解耦，一般先執(zhí)行一段業(yè)務邏輯，執(zhí)行成功會向消息系統(tǒng)發(fā)送一條消息，用于通知或觸發(fā)下游業(yè)務。這個場景下，如果業(yè)務邏輯執(zhí)行成功、消息發(fā)送失敗，則業(yè)務不完整；如果先發(fā)送消息，但執(zhí)行業(yè)務邏輯失敗，同樣存在問題。GTS提供了針對消息系統(tǒng)以及常見關系型數(shù)據(jù)庫的操作入口，保證數(shù)據(jù)庫操作和發(fā)送消息要么同時成功、要么同時失敗。

4、跨服務的事務場景：隨著業(yè)務復雜度提升，大多企業(yè)會對業(yè)務進行服務化改造?？赡艽嬖诜找徊僮鱉ySQL和DRDS，服務二操作Oracle，要求兩個服務操作要么同時成功、要么同時失敗，否則會造成業(yè)務數(shù)據(jù)的不一致。GTS可以很方便地進行跨多個服務的分布式事務。

依托阿里中間件(Aliware)，打造世界一流企業(yè)級互聯(lián)網架構平臺

據(jù)GTS項目負責人姜宇介紹，“GTS作為一款高性能、高可靠、接入簡單的分布式事務中間件產品，可與DRDS、RDS、Oracle、MySQL、PostgreSQL、H2等數(shù)據(jù)源，EDAS、Dubbo及多種私有RPC框架，MQ消息隊列等中間件產品配合使用，可輕松實現(xiàn)分布式數(shù)據(jù)庫事務、多庫事務、消息事務、服務鏈路級事務及各種組合。策略豐富，易用性和性能兼顧，將真正完善阿里云中間件產品線?！?/p>GTS（TXC）的研發(fā)依托于阿里中間件(Aliware)團隊，中間件技術部是阿里巴巴集團生態(tài)系統(tǒng)的技術基石，為集團各大業(yè)務群提供可靠、高效、易擴展的技術基礎服務；并在此基礎上打造世界一流的中間件產品、高可用架構基礎設施和企業(yè)級互聯(lián)網架構平臺，為全球企業(yè)和客戶提供服務。

更多AliwareGTS產品服務和技術細節(jié)，請訪問官網：

相關新聞

2016-04-19

2016-06-13

2016-10-24

2016-11-04

2017-12-29

隨著互聯(lián)網的發(fā)展，越來越多的業(yè)務不僅僅由單一節(jié)點（或是單一語言）就可承載，而是趨向多語言分布式協(xié)同開發(fā)（如接入層由Node.js完成，邏輯（數(shù)據(jù)）層由C++/GO/Python實現(xiàn)）并由此組成大型異構系統(tǒng)。

我們（現(xiàn)SuperTeam）基于 Tars 體系研發(fā)出 Tars.js 以便用戶在不改變異構系統(tǒng)整體架構的情況下快速搭建（遷移）Node.js服務，并可非常方便的將原來的單一服務拆分為多個（邏輯）子服務。

Tars.js在騰訊內部經過5年多的沉淀與迭代（Node.js@0.10版本即提供支持），廣泛運用于騰訊QQ瀏覽器、騰訊桌面瀏覽器、騰訊地圖、應用寶、騰訊手機管家、互聯(lián)網+、騰訊醫(yī)療、騰訊覓影、保險、彩票等幾十個重要業(yè)務中，日承擔了上百億流量。

Tars.js包含下述特性：

l 100%由JavaScript編寫，不包含任何C/C++代碼。

l 多進程負載均衡與管理。

l 代碼異常監(jiān)控與重啟。

l 服務日志搜集與處理。

l HTTP(s)服務監(jiān)控與用量自動上報，并支持用戶自定義維度上報（PP監(jiān)控）。

l 符合 Tars(IDL)規(guī)范的編解碼模塊。

l 支持 TarsRPC調用與染色（模調自動上報）。

l 支持在線發(fā)送管理命令、拉取服務配置。

l 獨創(chuàng) LongStackTrace?異常跟蹤機制。

l …… 更多特性可訪問 @tars/node-agent 了解

設計理念：

?A．高自由度：

l 兼容所有（≥0.10）官方Node.js版本。

l 對 Node.js源碼無侵入無修改。

l 底層對上層完全透明，支持各種上層框架，無需變更。

也就是說：

您可以使用任何您熟悉的框架（如 Express.js/Koa.js等，包括但不僅限于Web框架），也無需對框架進行任何修改（無需引入任何中間件）。即可通過Tars.js運行，享受平臺提供的各種監(jiān)控與管理特性。

與此同時，Tars.js所提供的模塊，也可以根據(jù)您的需求引入（如未使用到則可不引入）。

?B．高性能：

Tars.js為高性能與大并發(fā)量而設計，使用了大量的前端（V8）優(yōu)化技巧（如FlattenString/FastProperties等）盡量降低所提供的能力對于業(yè)務性能的影響。

經過我們測試（WebServer），默認的旁路上報與監(jiān)控對服務性能的影響≤5%，常用模塊（RPC、日志等）性能位于業(yè)界前列。

?C．差異化：

Tars.js根據(jù)不同的業(yè)務類型提供差異化運營方案：

l 高流量業(yè)務：盡力降低框架對業(yè)務性能的影響。

l 低流量業(yè)務：充分利用硬件資源提升開發(fā)體驗。

HelloWorld

我們來看Node.js官網的 例子 (如下)，無需任何變更，直接通過Tars.js進行部署，它會擁有哪些特性？

? 進程管理

默認基于 cluster 模塊進行負載均衡，進程數(shù)可以配置為1~max（CPU核心數(shù)）、還可配置為auto（物理核心數(shù)相同）以減小內存壓力提升“性價比”。

與此同時，進程僵死檢測也會同時啟動，實時監(jiān)控業(yè)務進程。

?案例說明

某服務在論壇UBB代碼轉HTML時，使用未優(yōu)化的正則表達式進行XSS攻擊過濾，但由于用戶發(fā)帖時圖片采用BASE64編碼，導致正則表達式計算時間過長，CPU使用率飆漲到100%：

開啟僵死檢測后，Tars.js監(jiān)控到業(yè)務進程僵死時，自動重啟業(yè)務進程，從而縮短了業(yè)務無響應時間：

Tars.js雖然無法解決業(yè)務代碼的問題（BUG），但會盡最大努力保證業(yè)務的可用性。

? 服務監(jiān)控

以服務名、接口名（URL-PATH節(jié)）為緯度，統(tǒng)計總流量、平均耗時、超時率、異常率：

其中返回碼大于400（可配置）作為異常進行上報。

?監(jiān)控說明

Web服務一般由靜態(tài)與動態(tài)資源（接口）組成，由于靜態(tài)資源（本地文件）的請求耗時遠低于動態(tài)資源（業(yè)務邏輯），請求量往往又很高，拉低了服務整體耗時。

基于此，Tars.js將請求URL中的PATH節(jié)作為接口，每個接口均可查看其總流量、平均耗時、異常率，便于用戶全面了解服務性能。

? 特性監(jiān)控

無論您服務的類型是什么，總是會上報下述特性，便于回溯問題與評估性能：

l memUsage：內存用量，將會上報rss、heapUsed、heapTotal這三個用量（單位為字節(jié)）

l cpuUsage：CPU用量，將會上報CPU使用率，數(shù)據(jù)匯總為邏輯單核（單位為百分比）

l eventloopLag：（任務）隊列延遲，每隔2秒采樣（單位為毫秒）

l libuv：I/O用量，將會上報activeHandles、activeRequests這兩個用量

各策略以平均值（Avg）、最大值（Max）、最小值（Min）分節(jié)點進行統(tǒng)計：

? 日志輸出

所有通過Console模塊（如console.log）輸出的日志，都會輸出到服務本地文件內。并附加相關信息（如下），方便定位問題。

日志格式：日期時間|進程PID|日志級別|輸出文件名與行號|日志內容

2018-07-0112:00:00|332|DEBUG|app.js:13|Serverrunningathttp://127.0.0.1:3000/

? LongStackTrace?

由于Node.js采用異步機制，在發(fā)生異常時堆棧不完整，導致定位問題復雜。

鑒于此，我們提供了長鏈路跟蹤技術在產生異常時自動附加前序調用堆棧，同時還支持在異常堆棧中過濾出用戶代碼部分。

由于開啟此特性時會造成性能損耗，故默認關閉，管理平臺等性能不敏感業(yè)務可直接通過配置開啟。

?案例說明

執(zhí)行上述代碼會拋出下述異常：

ReferenceError:ThisMayThrowErrorisnotdefined

atTimeout.setTimeoutas_onTimeout

at_disibledevent="http://superzheng.com/">@SuperZheng 創(chuàng)立于2017年。團隊成員均為全棧架構師（Super寓意Superman——無所不能），熟知Web(3D)、終端、后端與大數(shù)據(jù)計算，并由傳統(tǒng)前端向互聯(lián)網從業(yè)者方向發(fā)展。歡迎前端牛人加入，共創(chuàng)前端美好未來。