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

[[216347]]

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

　　以下為演講實錄：

　　大家下午好!

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

　　今天講一下在整個微服務架構下，我們整個二手交易平臺怎么樣打造一些云基礎設施?

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

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

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

　　按垂直領域去做微服務架構

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

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

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

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

　　按照業務模式來做微服務框架

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

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

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

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

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

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

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

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

　　引入分布式事務的解決方案

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

　　要解決分布式事務的解決方案，有沒有什么好辦法?你要解決分布式事務理論上是一個長事務，你要解決長事務本質上還是要把這個長事務變成一個短事務，短事務其實就是你的本地事務。這樣你的分布事務解決一旦出現問題，你的協調的問題。解決分布式事務有很多方式，比如說補償的方式。當然也可以在異步環境下通過MQ來去做。在異步的環境下怎么通過MQ實現整個分布式的鎖，分布式事務來去做這一塊，我們的目的最終保證數據一致性。

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

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

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

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

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

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

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

　　講完這個今天我的分享就結束了，主要是帶領大家去學習了一下整個微服務架構設計的一些理念，以及我們整個云事務，給大家舉了兩個例子，以及鎖和整個事務怎么去做。