阿里云消息服務(wù)的相關(guān)技術(shù)架構(gòu)

SegmentFault都非常困，所以借這個活動把大家的精神氣提起來。就前面那個問題，阿里云其實(shí)也會有很多用戶收集的需求，而且這個規(guī)模量會比這個更大，我們用的程序就是用P寫的，P（音）是解釋型語言，它的那些解釋器效率非常低，但是它有一種新的解釋器PNPN，這個解釋器效率非常高，然后我們優(yōu)化完以后，我們性能能夠跟C++是一樣的，甚至能夠比JAVA的效率還要高。下面我開始我的，我今天的題目是阿里云消息服務(wù)的技術(shù)架構(gòu)，我在做分享之前想跟大家做一個小小的，有多少人知道阿里云，知道的舉手，看來阿里云的做的很好，有多少人知道阿里云的飛天，就是知道的比較少。說明今天我出來講是非常有必要的，阿里云是09年的博士帶著一幫有理想的同學(xué)到去做飛天的夢想，包括我們今天的消息服務(wù)其實(shí)也是在飛天這個平臺上演化出來的一個云服務(wù)產(chǎn)品。自我介紹一下，我是阿里云飛天事業(yè)部服務(wù)團(tuán)隊的，我現(xiàn)在在負(fù)責(zé)這款產(chǎn)品的研發(fā)，我在負(fù)責(zé)另外一塊產(chǎn)品。我在11年加入阿里云，從阿里云飛天平臺研發(fā)測試一直做到現(xiàn)在，其實(shí)比較自豪的事情，我們飛天平臺現(xiàn)在已經(jīng)能做到10K的規(guī)模，10KHadoop進(jìn)入，我們其實(shí)今天講了一個叫消息服務(wù)，其實(shí)廣義的消息，大家覺得我們?nèi)?。、郵件、IM信息，比如說 其實(shí)我們計算機(jī)世界也是一樣的，而且計算機(jī)世界對消息處理的要求更高。到我們上面來，我們爭取們變成土豪公司。這是廣義的消息，處理這種消息的軟件有哪些？傳統(tǒng)的消息軟件，開源的RabbitMO，然后是Kafka。而且技術(shù)門檻蠻高的，你要配一個專門的人去看著不要出問題，然后你機(jī)器投入比較多，Kafka剛才前面講到你在，你在杭州要部署的時候又要一套，然后發(fā)展很快到海外去了，統(tǒng)，我們今天想把它封裝服務(wù)，然后解決傳統(tǒng)軟件的一些痛點(diǎn)。它有哪些特點(diǎn)我們可以來看一下，第一門檻低，你只要到阿里云點(diǎn)擊開通，你甚至不需要知道Kafka24用HTTP的時候，你原來的小概率會出現(xiàn)，可能每兩天要掛一次，這個時候你不得不證數(shù)據(jù)十個9可靠性，基本上不丟。還有服務(wù)高可用，我們假設(shè)任何物理機(jī)或者虛擬得到的可用性是三個9。然后是安全，Docker的安全性怎么樣，今天Docker沒有給成一個解決方案，們提供一個RAM控制功能，還有多用戶。最后還有彈性，今天我們消息服務(wù)上的的的消息至少被你的程序成功處理一次。然后是一對多的，一個 群，你里面發(fā)的消息所有人都能看到，隊列是說你單獨(dú)溝通，只有跟你聊天的人看到。這邊，今天比如說你想做一個消息系統(tǒng)，有發(fā)生，然后你想去接各個服務(wù)的API，你綁定哪幾個，你就可以順利去發(fā)郵件。這在我們的官網(wǎng)上也有，這是阿里云消息服務(wù)MNS架構(gòu)，基本上是四層，最外飛天集群希望我們有兩個Server，一個是MetaServer，一個是DataServer。務(wù)切片，每個用戶的切片都會在不同的服務(wù)器上，然后當(dāng)有物理機(jī)fail片可以快速遷移，這樣的話任何時候物理機(jī)fail都不影響你往里面寫數(shù)據(jù)。據(jù)寫進(jìn)來都是寫到飛天的分布式系統(tǒng)，里面一個系統(tǒng)，每條消息的數(shù)據(jù)有replication的能力，自動能力，當(dāng)我發(fā)現(xiàn)我消息對應(yīng)的三份只有兩份的時候它會去補(bǔ)全，從而實(shí)現(xiàn)我們數(shù)據(jù)十個9的可靠性。消息服務(wù)商業(yè)化到現(xiàn)在我們從來沒有們還有防Ddos，我們還有支持RAM，主子帳號，還有臨時AK。用我們的產(chǎn)品往角色，運(yùn)維你給他一個運(yùn)限的帳號，開發(fā)給他一個開發(fā)權(quán)限的子帳號，這樣的話你可以去控制你的隊列哪些該給誰。臨時AK是解決這個問題，今天我們移動APP非常流行，大家都會移動端往我這邊發(fā)數(shù)據(jù)，但是有一個問題，會有AK，AK就是你的用戶名、，你在用戶的設(shè)備上放一些你的帳號其實(shí)是很不安全的，臨時AK的作用APPAK，然后AK比如說15分鐘有效，這樣的話你不用擔(dān)心你今天發(fā)出去的APP家，反向從里面找出你企業(yè)的AK信息，這是適用于這種場景。另外我們今天所有消息服務(wù)都是支持https，你去截人家某些官網(wǎng)可能可以從包里面截到用戶名、。第四點(diǎn)，每個用戶數(shù)據(jù)都會打上用戶，實(shí)現(xiàn)獨(dú)立命名空間，也就是說用戶A根本看不到用戶B的存在和他的數(shù)據(jù)。最后，我們做了一個特別包，我們有有效期，如果你的消息句柄在網(wǎng)上家截獲了，也不用擔(dān)心，因?yàn)檫@個然后是彈性的實(shí)現(xiàn)，我們元數(shù)據(jù)分片具備自動能力，然后數(shù)據(jù)節(jié)點(diǎn)可以水平擴(kuò)展，前端http服務(wù)節(jié)點(diǎn)也是可以水平擴(kuò)展。無論是消息隊列的個數(shù)，還有的個數(shù)，ServerA機(jī)器上去調(diào)一個服務(wù)B，這是一個比較緊的耦合系統(tǒng)，因?yàn)楫?dāng)你服務(wù)B掛的時候，它會馬上影響你服務(wù)A。一個公司可能有兩個開發(fā)在做兩個不同的服務(wù)，服務(wù)A往往會被服務(wù)B坑掉。我們可以用這樣一個方式來解耦它，就是松耦合系統(tǒng)，我服務(wù)A要向服務(wù)B請求，我先把數(shù)據(jù)放在隊列里面，然后B再從隊列里面處理。這樣的一個好處是說當(dāng)你B掛的時候，其實(shí)A還是可以繼續(xù)工作的。包括你有些運(yùn)維活動，比如說我的B要升級，這個服務(wù)A都是不會被影響的，這是系統(tǒng)解耦。還有一個我們的典型場景叫削峰填谷，正常比如說我用戶直接你的服務(wù)，尤其是像秒殺這種產(chǎn)品，你會非常痛苦，你為了用戶可能幾天的大量就得擴(kuò)一堆服務(wù)供http的，經(jīng)常會出現(xiàn)這種情況，我跟你兩個企業(yè)之間需要做數(shù)據(jù)交換，這個時候兩家都有，怎么辦？可以通過阿里云消息服務(wù)做一些中轉(zhuǎn)。下面是異步通知這個產(chǎn)品，正常的時候會發(fā)現(xiàn)用戶提了任務(wù)，這個任務(wù)需要一段時間計算，我又不知道你什么時候算完，然后我不停的發(fā)送請求。其實(shí)12306就是后去處理，處理完了以后你再通過另外一個我們的這個方式通知用戶說處理人家買不了了，30分鐘以后你檢查一下這個用戶到底有沒有把錢付了，沒有付錢，我下面給大家兩個用戶案例，一個是撈月狗，這個公司現(xiàn)在國內(nèi)最大的第游rabbitmqrabbitmq10所以現(xiàn)在他們是我們一個忠實(shí)的客戶，基本上他從用了我們以后需要去運(yùn)維Q這個事第二個案例是FmRadio8公司，他服務(wù)的客戶里面有比較牛B的，比如說人民12我們以后他在大概兩個多，就把這套系統(tǒng)搭完了，而且在春節(jié)千萬級用戶的活動發(fā)次，應(yīng)該有這種解決方案。消費(fèi)的時候，你怎么辦？有可能兩個人都在消費(fèi)，你一條消息掛了，完了以后它再發(fā)的時候發(fā)到B上面去了，然后你那邊還沒有處理完。我們生產(chǎn)者往服務(wù)里面發(fā)消息，隊列里面，然后假設(shè)A拿到了這條消息，今天A拿NNBAB你A掛的時候過一段時間我B還可以消費(fèi)。還有一個問題，那是因?yàn)槲页绦驋炝?，還有一種情況，今天個任務(wù)處理的時長30fail，它還在努能被消費(fèi)者B去處理。這里面我們提供另外一個接口，今天我30秒超時，我在25秒能保證消費(fèi)者A雖然這個任務(wù)超時，它還是能處理完。這是從我們消息處理上的兩種另外還有一個問題，剛剛好象也有人提到了，日志處理順序的問題，日志處理Spark是今天一個最佳實(shí)踐的方案，然后我們的方案也有下面的，大家可以去看。接收64K的消息，為什么不做更大的，我們每個系統(tǒng)都有時間空間，系統(tǒng)也是一樣，當(dāng)你系統(tǒng)如果要追求QPS的時候，你可能會犧牲你的Throughput，當(dāng)你追求Throughput的時候可能會犧牲QPS，比如說我的QPS很高，但是我可能Throughput很低。Throughput就是吞吐量，其實(shí)受限于網(wǎng)絡(luò)，QPS受限于你的處理能力。今天極度優(yōu)化了我的QPS，我強(qiáng)調(diào)的是秒鐘處理消息的數(shù)量，不是說秒鐘的網(wǎng)絡(luò)吞鐘只能處理十。所以我們今天消息服務(wù)限制了64K，這是不是意味著我要發(fā)大數(shù)據(jù)就實(shí)的消息變成了M和D，的消息M放到消息隊列里面需，然后的D放到OSSMNS以后再從OSS上去拿消息和數(shù)據(jù)，這樣就完成了大數(shù)據(jù)的傳輸，而且這個基本上是無最后提到OSS，我今天把阿里云服務(wù)的產(chǎn)品體系做服務(wù)這么一個產(chǎn)品系列，它里面不光是說消息服務(wù)，它最大一塊是對象，就是我們OSS，另外還有塊，還有日志服務(wù)，剛才月Spark，其實(shí)阿也提供類似的功行了。還有你的數(shù)據(jù)，剛剛提到那些音數(shù)據(jù)放在上面時間久了，你后面可能不需用買。還有一個就是表格，以前叫OTS，這個性能上更好。這基本上就是阿的服務(wù)產(chǎn)品的系列，然后大家如果之前講說寫代碼什么的，你可以先想想這個產(chǎn)品是不是可以先用起來，我們是按量，你不用是不的。 ，大家有可以掃描看一看：謝謝老師，現(xiàn)在阿擴(kuò)招，大家有的話可以找他提問：你好，但是這么火，秒殺、團(tuán)購、特賣的，流量壓力比較大，你：你的問題我基本上聽明白了，這也是阿，現(xiàn)在雙十一大部分在大量阿然，都會分開的，可能前面插一個，量控制住，還讓你輸入 庫，還是我們傳統(tǒng)的MQ那種，它是一個分布式的數(shù)據(jù)庫，然后里面可以查你這個下單有沒有下，沒下我就秒殺，經(jīng)常會發(fā)現(xiàn)我秒的時候，過一會兒又回來了，有時還有你數(shù)據(jù)也會出現(xiàn)這個問題，當(dāng)你系統(tǒng)規(guī)模很大以后，任何小概率都會發(fā)生，不是完成，然后它事后有有一次檢查，當(dāng)我再拿到一條過去的不一致的消息的時我碰到過，余額寶轉(zhuǎn)帳的時候，我從一個比較偏僻的地方，又從感覺IT不是很強(qiáng)的了。它有日志在那邊，數(shù)據(jù)庫狀態(tài)在那邊，會幫你補(bǔ)回來，去看看，如果你發(fā)生這種狀態(tài)，等待24小時后會回來的，或者你打。提問：老師你好，請問一下你之前說的削峰填谷來解決大數(shù)據(jù)高并發(fā)的時候能一種是要改變我服務(wù)器狀態(tài)，還有一種是讀，你的緩存只能對讀有用，比如說我，我有很多同時來，讀你的緩存是有用的，但是如果你大量請求，比如我來改某個：你還有一種情況，緩存寫到中間狀態(tài)，做一致性的處理。程，但是你用隊列先把任務(wù)放進(jìn)去，然后后面做操作。這樣的話你前面進(jìn)來的速提問：問一下，如果我們作為一個發(fā)送者是沒有問題的，但是作為一個消費(fèi)者該怎么辦，因?yàn)槲覀兎?wù)有一個靜態(tài)服務(wù)器地址，但是APP沒有辦法實(shí)現(xiàn)？：阿有另外一個服務(wù)叫移動推送，就是我們會跟它對接，今天我去讀你的服務(wù)地址是可以的，但是我服務(wù)去你的，你沒有給我回，沒有關(guān)系，今天我們有一個移動推送服務(wù)，這個移動推送服務(wù)類似于第，你甚至于不用第三方，你可以用、Android這種網(wǎng)關(guān)去做你這個推送的事情，本質(zhì)上那是一個移一個你移動推送的帳號和群，就是APP那個模板，然后我們這邊一條消息過來，可以提問：之前我做過淘寶賣家工具，用的是阿的接口，其中有做服務(wù)推送的，開發(fā)商訂閱一些信息、支付信息，這些信息應(yīng)該一直是傳輸?shù)侥隳欠N成功處理之后才會刪掉，對吧？我的場景是這樣，我們第應(yīng)用上去之后，他就要拿到他近：我們這個產(chǎn)品是類似免費(fèi)的，就是一點(diǎn)錢沒有收，我們后面可能會。訂閱以后我有一個可以是一對多推消息，本來只有兩個人訂閱，突