由中國電子技術(shù)標(biāo)準(zhǔn)化研究院主辦、51CTO承辦的“第七屆中國云計算標(biāo)準(zhǔn)和應(yīng)用大會”于2018年1月4日至1月5日在北京成功召開。本次大會全面展示我國云計算國家標(biāo)準(zhǔn)研制工作的成果，解讀國內(nèi)云計算產(chǎn)業(yè)政策，報告云計算標(biāo)準(zhǔn)化工作的重要進(jìn)展。同時，大會還重磅發(fā)布了國家開源領(lǐng)域的標(biāo)準(zhǔn)化產(chǎn)物，分享了云計算***的技術(shù)趨勢和應(yīng)用創(chuàng)新成效，并頒發(fā)了云計算產(chǎn)品及解決方案第五批測評證書。此外，第二屆中國優(yōu)秀云計算開源案例評選結(jié)果也在大會現(xiàn)場公布。

[[216347]]

　　在大會的云計算基礎(chǔ)架構(gòu)與實踐分論壇上，轉(zhuǎn)轉(zhuǎn)公司架構(gòu)算法部負(fù)責(zé)人孫玄帶來了《微服務(wù)架構(gòu)下，如何打造二手交易平臺》的主題演講。他從何為微架構(gòu)服務(wù)談起，從垂直領(lǐng)域、業(yè)務(wù)模式和引入分布式事務(wù)解決方案三個方面與大家分享了如何做好微架構(gòu)服務(wù)。作為本場論壇的***一名演講嘉賓，雖然天色已晚，但精彩的內(nèi)容分享仍然吸引了現(xiàn)場所有觀眾的駐足聆聽。

　　以下為演講實錄：

　　大家下午好!

　　到這個時間點了，大家還坐在這里聽我講非常不容易，其實剛才劉喆講的非常精彩，他說這個會就不應(yīng)該講比較技術(shù)的東西。剛好我今天準(zhǔn)備的這個東西分兩部分，一部分是用來吹牛的，但是還有一部分是干貨，干貨部分劉喆說了，我們應(yīng)該講一些更加宏觀的東西，所以技術(shù)的東西我們盡量少講。

　　今天講一下在整個微服務(wù)架構(gòu)下，我們整個二手交易平臺怎么樣打造一些云基礎(chǔ)設(shè)施?

　　首先，允許我做個自我介紹，我此前一直在58待了很多年，58成長比較快，成為整個58集團(tuán)***的架構(gòu)師，后來帶領(lǐng)大家做一些在技術(shù)上比較難啃的骨頭。當(dāng)年為什么加入58，其實比較有意思。我2011年在百度，后來想離開百度，去哪里呢?其實不知道，當(dāng)時獵頭就問我，你想不想去58?我當(dāng)時說也可以，但是我不知道58是什么東西，我唯一知道每天楊冪在整個公交上和地鐵上說58同城一個神奇的網(wǎng)站，我想既然神奇，我就來了，一待就是很多年。我在58經(jīng)歷比較簡單，基本上最開始做一個類似于一個電商的聊天的工具，后來就做轉(zhuǎn)轉(zhuǎn)的產(chǎn)品。

　　我在百度其實是在做百度空間，大家知道這個產(chǎn)品嗎?不知道，你們知道的同學(xué)都暴露年輕了。在此前在浙大讀書，后面因為有很多積累，所以代表公司做了很多次分享。基本上業(yè)內(nèi)的大會，我能刷臉的地方都刷過了，包括整個AI，包括整個架構(gòu)的大會其實的刷比較多，為什么最近刷AI?我其實個人的經(jīng)歷，架構(gòu)放了一部分，但是做電商其實更重要的是在算法方面，比如說通過一些機(jī)器學(xué)習(xí)，在整個推薦和搜索上產(chǎn)生一定的訂單萬花，因為這部分現(xiàn)在是我負(fù)責(zé)，我個人更多精力放在算法上面，有興趣的同學(xué)可以交流，也是我個人的一些介紹。

　　談到微服務(wù)架構(gòu)首先聊聊微服務(wù)架構(gòu)是一個什么東西，圍繞微服務(wù)架構(gòu)下二手交易平臺做哪些基礎(chǔ)設(shè)施，這里選擇兩個比較有典型的案例跟大家去講一下，比如說在二手交易平臺下整個分布式怎么設(shè)計，我們整個事務(wù)如何去做?講之前首先聊一下這個東西，這個東西大家都見過沒有?這其實是我們的一個logo，因為我們是做二手的，我們要解決一個從“買買買”到“賣賣賣”的問題，我原來在朋友圈看到一句話覺得挺有意思的，其實也是解決同買買買到賣賣賣的問題，當(dāng)然也是在共享經(jīng)濟(jì)時代的流轉(zhuǎn)，我們更鼓勵你不用的東西可以在二手平臺上賣出去，這樣至少你可以換點錢，至少你對錢其實是不討厭的。

　　按垂直領(lǐng)域去做微服務(wù)架構(gòu)

　　我們講到微服務(wù)，不得不提在整個微服務(wù)時代有一個人提出這個架構(gòu)，這個架構(gòu)是馬丁·福勒。微服務(wù)架構(gòu)的思想很早都有，真正提出來是在2014年，既然是一種架構(gòu)模式，必然會遵循一些規(guī)范或者架構(gòu)設(shè)計的理念，大家可以看，首先微服務(wù)是一些小服務(wù)的組合。什么叫小服務(wù)的組合呢?有一次在一個大會的會議下交流時，有位老師說能夠做到定量的去做到微服務(wù)，我說你們是怎么樣做到的?他們老板說，我們就按照代碼行來做，一千行就定義為一個微服務(wù)。他問我行不行，假設(shè)你們的代碼行數(shù)是1001行你怎么做?他回答好像我們還沒遇到這個問題。

　　我們要做微服務(wù)，你們一定聽說過什么領(lǐng)域驅(qū)動設(shè)計，這是很大的理論，實際過程中怎么做呢?就可以按照整個業(yè)務(wù)的垂直領(lǐng)域去參與。我們做二手交易，我們有用戶體系，我們用商品體系，我們有交易體系、搜索體系、交易體系，垂直拆，用戶是一塊，商品是一塊，推薦一塊，拆完之后，每一塊就是微服務(wù)，這樣拆完就OK了嗎?當(dāng)然不OK，搜索如果拆完之后所有的邏輯、數(shù)據(jù)訪問都在一起，必然造成你的模塊的功能非常臃腫，我們需要在水平方向做一個拆分，可以拆成網(wǎng)關(guān)，業(yè)務(wù)邏輯層和DB來做，我們在業(yè)界做無非就是垂直拆分和水平拆分的東西，來做這一塊，這塊是比較簡單的。

　　最終我們拆出來，我們真正拆的話，其實一樣，比如上面是我們整個客戶端，比如說IOS和安卓，對下面是整個網(wǎng)關(guān)，網(wǎng)關(guān)下面是業(yè)務(wù)邏輯層，再下面是數(shù)據(jù)訪問，再下面是TB做這一塊，垂直方向做了垂直拆分，水平方向又做了水平拆分。在我看來同整個架構(gòu)模式上，你的微服務(wù)架構(gòu)無非做了一個垂直拆分，加上一個水平拆分，當(dāng)然它最難的其實不在你的水平拆分，而是在于你的垂直拆分，所以這個比較簡單。我們整個微服務(wù)，他的業(yè)務(wù)架構(gòu)這時候應(yīng)該按照你的業(yè)務(wù)領(lǐng)域模型進(jìn)行拆分，拆分完之后我們再去做一個水平拆分就OK了，這個其實是比較簡單的。

　　另外一塊，我們整個二手交易平臺其實它是電商，既然有電商的話，電商該有的東西它都有，所以我們這個模塊其實也是比較多的。大家可以看一下，從下面整個的運(yùn)維支撐，包括我們的發(fā)布系統(tǒng)，以及我們整個的信息化平臺，這是在運(yùn)維層面的稱，運(yùn)維層面之上有我們的基礎(chǔ)服務(wù)，包括短域名，包括整個的溝通，因為用戶賣家和買家的溝通，包括我們的push服務(wù)。還有技術(shù)組件，數(shù)據(jù)庫的中間件，這些東西需要我們自己打造，當(dāng)然上面還有一些平臺，這些平臺主要是為了整個服務(wù)來做的，比如說監(jiān)控去做，你的服務(wù)做，你的日志的跟蹤去做?當(dāng)然還有離線任務(wù)，你的調(diào)度去做，保證你的調(diào)度的穩(wěn)定性。當(dāng)然我們還有自己的存儲層，主要三部分。最上面就是大家說的，我們要做微服務(wù)，必然要解決微服務(wù)框架的問題，包括你的RPC怎么去做?你的網(wǎng)關(guān)怎么去做?好在我們其實沒有用業(yè)界開源的東西，但是我們的RPC是我們自己打造的，基本上業(yè)界聽說過的doble和PRC比較類似，所以我們自己做，我們做的東西比較多。我會挑一兩個比較重要的跟大家講一下。

　　按照業(yè)務(wù)模式來做微服務(wù)框架

　　其實鎖這個東西有很多的場景我們可以用到，比如說在整個的交易，因為二手交易平臺和新品不一樣的地方在哪兒?新品是有庫存的概念，但是二手交易平臺是沒有庫存的概念，所有的商品理論上只有一件，所以在這種情況下如果兩個人同時對一個訂單下定單，如果你要不做一個全局唯一的限制，就可能下訂單下重了，超賣的情況，這種情況你需要用到鎖保證它資源的唯一性。另外一方面消費，我要產(chǎn)生一個消息，丟到MQ里面，你發(fā)送消息的時候你是沒有辦法保證你的密令性的，你的密令性通過消費端保證，你怎么保證你的消息被一個消費掉了，另外一個就不再去消費他，解決你的消費密令性的問題，這時候也會用到一些鎖的問題。

　　這種情況無非解決的分布式環(huán)境下我們的資源唯一寫的問題，這個其實很簡單，我相信你們有解決的辦法。大家都知道，我直接用readis Setnx Timeout搞就行了。但是用這個做有什么問題呢?理論上來說其實你的鎖一旦放在redis里面有一個周期，這個鎖什么周期你是不靠控制的。我們的目標(biāo)是解決這些問題，首先的目標(biāo)解決強(qiáng)一致性。另外一點，你的鎖，我希望是有周期的，剛開始申請到5毫秒，我發(fā)現(xiàn)5毫秒還不夠，我再續(xù)5毫秒，但是redis時代這一點是做不到的。你作為一個鎖，業(yè)務(wù)方向接入你，對你的要求，我希望業(yè)務(wù)方接入你的步驟極簡，如果大家做過技術(shù)服務(wù)也好，哪怕你讓業(yè)務(wù)多寫一行代碼，業(yè)務(wù)告訴你我不干，所以這是很麻煩的一個事，你要做這個事情。可視化管理后臺和監(jiān)控這是必須要去做的。

　　怎么做呢?很簡單，我們采用ETCD來做，在業(yè)界經(jīng)過了整個的驗證，它是簡單的KV，它的高可用，數(shù)據(jù)本身是支持持久化的，所以存儲采用ETCD來去做，我們怎么去做呢?ETCD本身是高可用的分布式集群，我們希望在客戶端打造一個分布式的客戶端，一個鎖我當(dāng)然希望在多個模塊都可以公平競爭，所以這是我們的出發(fā)點。

　　你獲取這個鎖無非兩種模式，一個模式是客戶端的TTL，另外一個就是服務(wù)端TTL，服務(wù)端TTL，就是你的鎖一旦到期以后來幫你續(xù)租，一個客戶端幫你續(xù)租，另外一個我希望ETCD本身幫我續(xù)租。這個模式是比較簡單。

　　客戶端模式比較簡單，比如說我有兩個用戶，一個客戶端A，一個客戶端B，拿到鎖很簡單，直接請求ETCD的一個接口就好了，當(dāng)然它需要傳一些東西，比如說你的Key，你的TTL，包括你要寫一些東西，包括你的UID，也是你的鎖的唯一標(biāo)識。

　　當(dāng)然，這時候只有一個用戶其實能拿到鎖，如果A拿到鎖，B必然拿不到鎖。這時候一旦A過期以后希望續(xù)租，客戶端模式有一個線程幫他續(xù)租，客戶端模式需要客戶端幫你做續(xù)租。

　　另外一塊是Server模式很簡單，他獲得鎖都一樣，只不過你的續(xù)租誰來做?當(dāng)然我希望Server端來去做。我們實際用什么呢?我們實際一定是用我們的服務(wù)端模式，因為流程越少，越穩(wěn)定，你的客戶端接入就越穩(wěn)定。

　　業(yè)務(wù)接入比較簡單，JDK7及以上，用Try代碼，如果是JDK7以下，拿到鎖以后需要用你的relesad接口來做這一塊。兩個人同時對它申請就OK了。***清理，如果用JDK7以上如果釋放掉以后，我們就直接釋放掉了，這個比較簡單，不花大功夫去講了。

　　引入分布式事務(wù)的解決方案

　　另外，想跟大家講一下事務(wù)的問題，剛才講在微服務(wù)架構(gòu)里面因為我們的模塊其實會拆分的非常非常多，拆分非常非常多以后，一個請求過來，你會設(shè)計多很多的模塊，這些模塊同時對多個模塊進(jìn)行更改，這時候你怎么能保證你的數(shù)據(jù)對多個模塊要么都成功，要么都成敗。在整個的分布式環(huán)境下或者微服務(wù)架構(gòu)下適合你的模塊其實很多，這時候你可能需要引入一些分布式事務(wù)的解決方案。

　　要解決分布式事務(wù)的解決方案，有沒有什么好辦法?你要解決分布式事務(wù)理論上是一個長事務(wù)，你要解決長事務(wù)本質(zhì)上還是要把這個長事務(wù)變成一個短事務(wù)，短事務(wù)其實就是你的本地事務(wù)。這樣你的分布事務(wù)解決一旦出現(xiàn)問題，你的協(xié)調(diào)的問題。解決分布式事務(wù)有很多方式，比如說補(bǔ)償?shù)姆绞健．?dāng)然也可以在異步環(huán)境下通過MQ來去做。在異步的環(huán)境下怎么通過MQ實現(xiàn)整個分布式的鎖，分布式事務(wù)來去做這一塊，我們的目的最終保證數(shù)據(jù)一致性。

　　怎么做呢?很簡單，MQ其實可以提供類似于TCC的分布式的功能，因為我希望通過一個MQ的事務(wù)消息解決我的數(shù)據(jù)最終一致性的問題，什么叫業(yè)務(wù)場景，剛才講我們是使用在一些異步的場景去做，我們現(xiàn)在在一個交易環(huán)境下下單的支付，我希望下單成功以后產(chǎn)生一個消息放在MQ里面，這時候支付環(huán)節(jié)從MQ里面讀從消息里面異步進(jìn)行處理，這個環(huán)節(jié)是異步場景，關(guān)鍵怎么保證下單能成功?我在下單能成功，把下單以后的消息放在MQ里面企事業(yè)能成功。如果使用正常的MQ，下單之前首先放一個消息在MQ里面，可不可以?也是可以的，但是有可能把消息放在MQ之后，你真正下單失敗了，這時候你放的消息就沒用了，也可以選擇我先下單，下單成功之后再把這個消息放在MQ里面，但是也有可能你把這個消息放在MQ里面又失敗了，因為它是兩步操作，你都沒有辦法保證它一致性的問題，這是頭痛的問題，我們希望我的下單和產(chǎn)生消息在異步環(huán)境下，的確有可能把它放在MQ里面失敗了，但是失敗以后，我希望業(yè)務(wù)方能夠提供一個回查的借口，我再去回查，你告訴我成功與否，如果成功了，我再去做這一塊。

　　這個思路很簡單，我們希望我的業(yè)務(wù)方能提一個本地操作的回查接口，涉及兩個狀態(tài)，一個叫半消息，一個叫消息的回查。這個圖是一個流動圖，MQ發(fā)送方就是MQ的客戶端，本地性的事務(wù)就是下單。我們做這個事呢?***步做下單操作之前做一個什么事兒呢?首先向MQ服務(wù)事務(wù)端里面發(fā)送一個半消息，這時候發(fā)到MQ里面是不會被下游性的，MQ受到這個成功消息之后，知道這個半消息已經(jīng)發(fā)到MQ了，業(yè)務(wù)方可以做什么事呢?第三步就可以執(zhí)行下單的本地事務(wù)。一旦我的下單本地事務(wù)執(zhí)行成功。

　　第四步，如果成功了我就再提交一個消息，告訴我的MQ，我的整個本地事務(wù)已經(jīng)執(zhí)行完了，這個時候可以把剛才這個消息投遞給你的消費方，順利的情況下MQ告訴你的發(fā)送方，我也收到這個消息，就OK了，有可能你發(fā)送這個消息的時候由于網(wǎng)絡(luò)的異常，你的發(fā)送方其實沒有收到，這時候很簡單，大家看第五步，如果這時候我的MQ發(fā)送方?jīng)]有收到你發(fā)給MQ的消息，這時候很簡單，你的發(fā)送方檢查你的本地事務(wù)，這時候剛才操作有沒有成功?假設(shè)你查出你的本地事務(wù)發(fā)現(xiàn)這個訂單我其實已經(jīng)下過了，這時候你會做一個什么事情?很顯然第七部，根據(jù)我的事務(wù)做reback，通過這種方式，總能保證最終這個消息是成功被消費的，野鴿方案理論上是OK的，它的優(yōu)點比較通用，它的缺點是你的業(yè)務(wù)方需要提供一個回查的接口，你每做一個本地事務(wù)，你需要把本地事務(wù)的回查接口提供給你的MQ發(fā)送方讓他查詢，也是對業(yè)務(wù)方是有代價的，當(dāng)然過程不用講了。

　　第四步執(zhí)行本地的操作，OK以后，你提交，這時候?qū)δ愕陌l(fā)送方來說，其實你需要去提交或者去回滾這個brouk。他的***問題不在于提交，問題每次做這樣一個事務(wù)以后，我的業(yè)務(wù)方都要提供一個回查的接口，這個其實很多情況下對于你的業(yè)務(wù)方是不愿意干的。這個方案本身是沒有問題的。我們能不能有一個方案能完成我們對重設(shè)計的一致性，有可能。我們期望做什么事情呢?我們希望說，剛才說我的下單和我產(chǎn)生一個MQ消息這兩步操作，我們能不能做這件事情?我把我本地的下單和我產(chǎn)生消息，這時候我不是直接放在MQ里面，我能不能直接通過本地事務(wù)的方式把下單操作和產(chǎn)生消息的操作放在一個里面，如果能放在一個里面，那么你的訂單和你的下單，你的訂單和產(chǎn)生消息，要么都成，要么都失敗就OK了，這時候你還需要多一個從你本地的消息表里面讀出消息傳到你的MQ里面就好了。如果這樣的話，業(yè)務(wù)方其實不需要提供回查接口的，這樣會比較爽一點。

　　所以很簡單，去做也一塊呢?我們希望在用戶做本地操作事務(wù)表的同時，我們給他放一張本地的消息表，開啟一個本地事務(wù)來做這一塊。這是流程。這個流程，這個就是你的微服務(wù)的客戶端，這就是你的微服務(wù)的數(shù)據(jù)庫。

　　和此前不一樣的地方是什么呢?***步寫入業(yè)務(wù)數(shù)據(jù)和服務(wù)數(shù)據(jù)，***步在這里面放一個，在這個里面可以對它進(jìn)行事務(wù)的操作，***步一旦成功或者失敗，比如說成功了做什么事情呢?從事務(wù)表里面讀出來本地事務(wù)放到我們的MQ里面去。所以第三步，讀出來以后，我的微服務(wù)可以把這個協(xié)議再寫到MQ里面，同時MQ給你的微服務(wù)和客戶端，我就可以去做這個事情，這是需要你的MQ的客戶端多做一些事情，同你剛才提交的本地的消息表里面讀出來，再放在本地。所以這是這個方式。

　　我們最終選擇的是這種方式，因為時間有限，其他的東西沒有辦法給大家展開，有興趣的時候我們可以交流一下。這個基本上是我今天講的內(nèi)容。其他的我們采用的本地事務(wù)消息表去做這一塊。

　　講完這個今天我的分享就結(jié)束了，主要是帶領(lǐng)大家去學(xué)習(xí)了一下整個微服務(wù)架構(gòu)設(shè)計的一些理念，以及我們整個云事務(wù)，給大家舉了兩個例子，以及鎖和整個事務(wù)怎么去做。