【51CTO.com原創(chuàng)稿件】2017年12月01-02日，由51CTO主辦的WOTD 2017全球軟件開發(fā)技術峰會在深圳中洲萬豪酒店召開。自2012年以來，WOT品牌大會成功舉辦了14屆，積累了大量的技術專家資源，獲得了廣大IT從業(yè)者和技術愛好者的一致認可，成為了業(yè)界重要的技術分享交流平臺以及人脈拓展平臺。本次會議包含：編程語言與框架，大數(shù)據(jù)系統(tǒng)架構設計、微服務與容器技術、前端開發(fā)實戰(zhàn)、物聯(lián)網(wǎng)(IoT)技術、軟件性能優(yōu)化等10大技術主題。

在大數(shù)據(jù)系統(tǒng)架構設計專場，來自TalkingData的資深Java工程師何坤分享了主題為《高可用數(shù)據(jù)服務交易系統(tǒng)架構實踐》精彩演講，介紹了TalkingData在搭建高可用數(shù)據(jù)服務系統(tǒng)的過程中，準確計量系統(tǒng)的設計、實現(xiàn)和演進等內(nèi)容。

演講中，何坤介紹了TalkingData智能數(shù)據(jù)服務商城SDMK(Smart Data Market)。SDMK是什么?它提供多種形式的數(shù)據(jù)服務，包括 API 服務、人群數(shù)據(jù)服務、異步服務等，還開放了Lookalike，情景感知，預測引擎，推薦引擎等人工智能服務。通過這些數(shù)據(jù)服務，可以降低數(shù)據(jù)應用場景的難度，幫助更多企業(yè)發(fā)現(xiàn)數(shù)據(jù)的深層價值。

所謂實踐出真知，談及智能數(shù)據(jù)服務商城實踐的經(jīng)驗心得，何坤從如何保證數(shù)據(jù)服務交易系統(tǒng)的高可用，如何做到準確計量等多個方面與51CTO記者進行了交流。

如何搭建高可用的數(shù)據(jù)服務交易系統(tǒng)?

作為基礎設施，有很多應用依賴于SDMK提供的服務,SDMK的自身的總體可用性必須比它們還要高。考慮到南向服務的多樣性和不可靠性，雖然不能做服務本身的可用性保證，但是要能做到服務不可用時，能以合適的方式通知用戶。因此，在SDMK構建過程中，TalkingData技術團隊充分考慮了系統(tǒng)的可用性。

何坤表示，想要搭建一個高可用的數(shù)據(jù)服務交易系統(tǒng)，不僅要做好梳理好業(yè)務流程，劃分出具體的系統(tǒng)功能模塊等這些常規(guī)工作。同時，在可用性上，系統(tǒng)需要達到兩點要求：一是，計量最終誤差要求，不高于0.01%;二是，交易系統(tǒng)可用性要求，不低于99.9%。

如何做到準確計量，保證計量誤差不高于0.01%?

那么，我們究竟該如何做到準確計量?對此，何坤認為，首先我們要明確準確計量的概念，它有兩層含義：一是，實時數(shù)量的準確性;二是，最終數(shù)量的準確性。但實時準確與高并發(fā)是一對矛盾，因此只能做到最終準確+高并發(fā)，犧牲一定的實時數(shù)量準確性，也就是說，實時計量會有一定誤差。因此，我們需要在保證最終準確性的前提下，盡量提高實時準確性。

此外，為了保證服務高并發(fā)和高QPS下服務的響應時間，可以使用“異步計量”的方式。在發(fā)生故障時，選擇盡量確保服務可用，容忍可能的超量;在故障后恢復數(shù)據(jù)，滿足最終準確的要求。

何坤表示，之所以選擇“異步計量”的方式而不是“同步計量”的方式，是因為：

1.對數(shù)據(jù)庫壓力大;

2.每次調(diào)用時延變長，不容易保證主流程時延穩(wěn)定;

3.MySQL不易擴展，要做分庫分表;

4.異步計量容易洗數(shù);

5.擴展性好，牽涉到異步服務的所有組件，ES，Kafka，Redis都是原生就支持方便擴展的。

此外，為了保證最終一致性，同時讓實時準確性盡量達到目標，TalkingData采用了Lambda架構來降低準確性和高并發(fā)下實時的矛盾。

如何保證系統(tǒng)可用性不低于99.9%?

記者了解到，整體服務的高可用性，不止故障轉(zhuǎn)移這一個點，它包括四個方面：事前的預防、事中的自動化故障轉(zhuǎn)移、事中的故障感知、事后的故障恢復。

何坤表示：“可用性背后是故障，我們預防故障的發(fā)生，在故障發(fā)生的時候及時做到故障轉(zhuǎn)移和故障的感知，并且在感知到故障之后能比較快速地恢復故障，恢復之后能做到復盤或者改進，就回到預防這一環(huán)，形成良性的循環(huán)。”

要想保證交易系統(tǒng)可用性不低于99.9%，何坤建議可以這樣做：

***，采用分布式部署，無狀態(tài)設計。采用服務無狀態(tài)設計，把必要的狀態(tài)保存在中央存儲中(MySQL/Redis等);所有調(diào)用必須帶trackid，以便定位問題，縮短故障恢復時間。

第二，可以專注于核心業(yè)務，降低關鍵路徑復雜性與負載，并適時拆分和合并功能模塊，降低模塊復雜度。

第三，對資源的使用進行限制，避免無效調(diào)用或者故障耗盡資源?？刹捎萌蹟鄼C制，分服務SLA，獨立適配器，限制pending狀態(tài)等方式，從用戶和服務兩個方向來進行。

第四，消息系統(tǒng)的選擇需要能夠保證數(shù)據(jù)可持久化，支持訂閱和隊列兩種方式，具有高性能和高擴展性。

第五，做好監(jiān)控與報警。所有服務上線之前必須有基本監(jiān)控與報警，比如：基礎組件監(jiān)控與報警、業(yè)務指標監(jiān)控與報警、調(diào)用追蹤系統(tǒng)等。

第六，減少更新帶來的故障，因為大多數(shù)故障都是更新引起的。對此，可以采用灰度系統(tǒng)，基于用戶id分流，而不是隨機分流。無論gateway請求還是頁面請求，所有的請求都帶用戶id，因此可以基于這個特性在Nginx中寫Lua來識別用戶，讀取后端配置的灰度用戶列表，決定是進入灰度系統(tǒng)還是正式生產(chǎn)系統(tǒng)。接入灰度的可以是友好用戶，也可以是守護用戶。但是要注意做好守護用戶數(shù)據(jù)的隔離，不要污染生產(chǎn)數(shù)據(jù)的統(tǒng)計分析。

此外，何坤強調(diào)，為了保證系統(tǒng)的高可用，一方面，要做好功能實現(xiàn)的演練測試;另一方面，研發(fā)人員需要深入地切入到運維層面，因為開發(fā)出的產(chǎn)品并不是實現(xiàn)了所有功能就是完成了任務，還需要發(fā)現(xiàn)并解決產(chǎn)品運行過程中存在的問題，否則會出現(xiàn)脫節(jié)的情況。

***，何坤表示，在設計系統(tǒng)時，除了計量本身的邏輯之外，計量是和可用性是密切聯(lián)系在一起的。如果可用性不夠高，或者不能及時糾正運行過程中的錯誤，那么就會影響計量。比如：如果不能快速的恢復數(shù)據(jù)，那么準確性也無法保證。

【講師簡介】

[[212573]]

TalkingData資深Java工程師何坤

何坤主要負責Smart Data Market研發(fā)，主導開發(fā)了智能數(shù)據(jù)服務商城，為超過200家客戶以高SLA提供數(shù)百個在線數(shù)據(jù)服務。在基于微服務的高并發(fā)高可用Saas系統(tǒng)設計實現(xiàn)運營方面具有豐富經(jīng)驗。之前曾任職于甲骨文，安捷倫科技等公司。敏捷開發(fā)和DevOps的踐行者。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】