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

[[216347]]

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

　　以下為演講實(shí)錄：

　　大家下午好!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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