J大數(shù)據(jù)是什么，大數(shù)據(jù)如同少年談性，都好像很明白的樣子，但是誰(shuí)都不怎么明白。

有人說(shuō)大數(shù)據(jù)就是大量海量數(shù)據(jù)處理。是嗎?我說(shuō)這樣理解可能有點(diǎn)片面。

在此我舉兩個(gè)小例子，希望有助于對(duì)于這個(gè)概念能做一定的闡述。

例 1：

當(dāng)你有一天在樹(shù)林里面運(yùn)送一塊大木樁，你想一次性運(yùn)回農(nóng)場(chǎng)，你牽一頭牛來(lái)，這頭牛來(lái)運(yùn)輸這塊木頭，拉的動(dòng)嗎，可以

當(dāng)你有一天有10塊大木樁，你還牽頭牛來(lái)，它拉得動(dòng)嗎，可能也拉的動(dòng)，但是它會(huì)比較費(fèi)力，效率會(huì)低一點(diǎn)，但是它還是能完成任務(wù)。

當(dāng)你有一天有50塊大木樁，你還牽頭牛來(lái)，它拉得動(dòng)嗎，拉不動(dòng)，為什么，50塊木樁的重量超過(guò)了它的負(fù)載能力，在這種情況下，這50塊木頭對(duì)于這頭牛來(lái)說(shuō)就是一個(gè)大數(shù)據(jù)。

例 2：

NASA美國(guó)航空航天總局需要24小時(shí)內(nèi)完成對(duì)月球上面?zhèn)鬏敾貋?lái)的數(shù)據(jù)進(jìn)行計(jì)算分析，于是部署了一臺(tái)計(jì)算機(jī)，24小時(shí)內(nèi)完成了

突然，有一天，領(lǐng)導(dǎo)一上班說(shuō)，我需要今天下班前得到當(dāng)天數(shù)據(jù)報(bào)告，大家就慌了，因?yàn)檎Ｄ莻€(gè)部署的計(jì)算機(jī)需要16小時(shí)完成。在這種情況的，在8小時(shí)內(nèi)完成對(duì)正常一天數(shù)據(jù)量的分析對(duì)于那臺(tái)計(jì)算機(jī)來(lái)就是大數(shù)據(jù)。

那對(duì)于這兩個(gè)例子，當(dāng)遇到大數(shù)據(jù)情況下，解決方案是什么呢?

在例一的情況下，你有兩個(gè)選擇。第一，牽來(lái)一頭大象，大象一次就能拉80個(gè)大木樁，50個(gè)對(duì)于它來(lái)說(shuō)綽綽有余。第二，牽來(lái)五頭牛，一樣可以順利完成任務(wù)。

在例二的情況下，你同樣有兩個(gè)選擇，立刻把數(shù)據(jù)分析計(jì)算程序部署到一臺(tái)超級(jí)計(jì)算機(jī)上面，譬如中國(guó)的天河-2，美國(guó)的Cray，這樣可能一下子數(shù)據(jù)就能出來(lái)，或者你說(shuō)我把程序部署到3臺(tái)同等級(jí)別計(jì)算機(jī)上面，利用這3臺(tái)計(jì)算機(jī)的計(jì)算能力來(lái)完成任務(wù)。

那么問(wèn)題來(lái)了，從成本上面來(lái)說(shuō)哪個(gè)合算，大家會(huì)驚訝的發(fā)現(xiàn)，在同樣完成任務(wù)的情況下，五頭牛的成本比一頭大象成本小很多，而三臺(tái)普通計(jì)算機(jī)比一臺(tái)超級(jí)計(jì)算機(jī)成本小很多。而那五頭牛和三臺(tái)計(jì)算機(jī)，在協(xié)力合作的條件下，完成了對(duì)于任何一個(gè)單元都不可能完成的任務(wù)，這就是一個(gè)簡(jiǎn)單的分布式系統(tǒng) (Distributed system)的例子，而每個(gè)單元可以從廣義上稱之為一個(gè)微服務(wù)(MicroService)。

微服務(wù)，一個(gè)最近被炒的很火的名字，那他到底是個(gè)什么東西呢?

微服務(wù)沒(méi)有一個(gè)精確的定義，可以說(shuō)這是一種軟件架構(gòu)風(fēng)格，利用模組化的方式組合出復(fù)雜的大型應(yīng)用程序，各功能區(qū)塊使用與語(yǔ)言無(wú)關(guān) (Language agnostic) 的 API 集相互通訊，而實(shí)現(xiàn)方法也多種多樣，每個(gè)公司使用微服務(wù)的出發(fā)點(diǎn)也不盡相同。但是微服務(wù)卻有幾個(gè)重要的共同特點(diǎn)：

1. 小而單一 (small and single resposibility)，并且專注于做一件事情，只負(fù)責(zé)一個(gè)系統(tǒng)下的某一個(gè)功能。

譬如我們?cè)诘谝粋€(gè)例子中的一頭牛，他只做一件事情，那就是拉車(chē)運(yùn)輸，而且他做的很好。而你作為趕車(chē)的，也可以是整個(gè)運(yùn)輸系統(tǒng)中的一個(gè)微服務(wù)，你也負(fù)責(zé)一件事件，就是這幾頭牛都走同一方向，而且方向正確，你并不負(fù)責(zé)拉車(chē)。

在初步劃分模塊的時(shí)候，通常公司可以按照自己的業(yè)務(wù)領(lǐng)域來(lái)分塊服務(wù)，一個(gè)典型的例子就是垂直電商系統(tǒng)一般可以分塊為用戶模塊服務(wù) Customer Service, 產(chǎn)品模塊服務(wù) Product Service, 訂單模塊服務(wù) Order Service, 支付模塊服務(wù) Payment Service 和 運(yùn)送模塊服務(wù)Shipping Service，每一個(gè)服務(wù)只負(fù)責(zé)一個(gè)領(lǐng)域模型中所需要完成的任務(wù)。這樣輕松實(shí)現(xiàn)整個(gè)微服務(wù)系統(tǒng)的松耦合和較高的維護(hù)能力。

2. 獨(dú)立部署 (independently deployable)，升級(jí)，擴(kuò)展或者替換

每個(gè)服務(wù)都可以單獨(dú)部署及重新部署而不影響整個(gè)系統(tǒng)。這使得服務(wù)很容易升級(jí)。

在此我們可以對(duì)比一下單體應(yīng)用(monolithic application)。譬如上文中提到的垂直電商系統(tǒng)，在單體應(yīng)用下，所有這些模塊都是打包在同一個(gè)WAR，或者EAR文件下面，部署到一個(gè)應(yīng)用服務(wù)器上面，這個(gè)應(yīng)用服務(wù)器可以Web應(yīng)用服務(wù)器，譬如TOMCAT，或者是J2EE應(yīng)用服務(wù)器，譬如WebLogic， IBAM WebSpeher或者是Jboss。 通常在這樣架構(gòu)下，當(dāng)我們需要替換，升級(jí)，或者一個(gè)簡(jiǎn)單的修改某一個(gè)模塊，譬如支付模塊的話，我們需要怎么做?修改支付模塊代碼，編譯整個(gè)項(xiàng)目，重新打包成一個(gè)WAR，EAR文件，然后替換整個(gè)應(yīng)用系統(tǒng)。即使我們修改的模塊和其他模塊沒(méi)有任何關(guān)系，但是，我們必須一起替換。這就增加了我們?nèi)粘５墓ぷ髁亢惋L(fēng)險(xiǎn)，譬如測(cè)試方便，除了做單元測(cè)試，我們還需要做一個(gè)集成測(cè)試，來(lái)保持我們其他模塊一樣工作;風(fēng)險(xiǎn)就是如果是一個(gè)架構(gòu)不是很好的軟件，軟件個(gè)模塊之間沒(méi)實(shí)現(xiàn)松耦合，那么修改一個(gè)模塊，很有可能導(dǎo)致另外一個(gè)模塊的不工作，別告訴我你沒(méi)有遇到過(guò)，當(dāng)你是一個(gè)新人，加入一個(gè)開(kāi)發(fā)組，team leader告訴你，把支付模塊一個(gè)bug修了，你廢了九牛二虎之力，很開(kāi)心的修完了那個(gè)bug，通過(guò)單元測(cè)試，提交了代碼，過(guò)了一會(huì)一封郵件過(guò)來(lái)，jenkins上面出錯(cuò)了，某一個(gè)和支付模塊完全不相關(guān)的用戶管理模塊出錯(cuò)了。是誰(shuí)的錯(cuò)，不是你的錯(cuò)，可能是架構(gòu)師沒(méi)有架構(gòu)好軟件，但是通常情況下，你得負(fù)責(zé)。

而微服務(wù)的獨(dú)立部署能力就是為了避免這樣類似的問(wèn)題再出現(xiàn)，通常一個(gè)微服務(wù)是領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)下完成的，各模塊之間有非常清楚明晰的邊界。

再拿第一個(gè)例子來(lái)說(shuō)，你趕著五頭牛運(yùn)送木樁，突然有一頭牛脫水倒下了，這個(gè)時(shí)候你并不荒，打個(gè)電話到農(nóng)場(chǎng)，給你再牽一頭或者是牛，或者是驢，或者是馬，你很輕松的就替換了那頭倒下的牛，而且對(duì)于其他幾頭牛并沒(méi)有影響，他們還是可以繼續(xù)安全的工作。

那么有人會(huì)說(shuō)，那怎么從一個(gè)單體應(yīng)用，轉(zhuǎn)換成一個(gè)成功，松耦合，易于升級(jí)和擴(kuò)展的微服務(wù)架構(gòu)的，這有一個(gè)非常有趣的話題，包括很多方面的考慮，從領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，到技術(shù)選擇和實(shí)現(xiàn)，到怎么一步一步分解一個(gè)巨大而復(fù)雜的單體應(yīng)用，到一個(gè)個(gè)微服務(wù)，以及各個(gè)微服務(wù)之間的通信選擇，畢竟當(dāng)你擁有200個(gè)微服務(wù)的時(shí)候，微服務(wù)之間的通信已經(jīng)不是簡(jiǎn)單的進(jìn)程內(nèi)呼叫了，而是通過(guò)網(wǎng)絡(luò)協(xié)議來(lái)實(shí)現(xiàn)的，穩(wěn)定性和性能都會(huì)有影響。

3. 輕量級(jí)通信協(xié)議 (lightweight communication protocol)

最常用的是HTTP協(xié)議下的REST，或者M(jìn)essage機(jī)制，譬如JMS， 或者AMQP (Advanced Message Queuing Protocol)

由于每個(gè)微服務(wù)都是一個(gè)獨(dú)立的應(yīng)用程序，這個(gè)獨(dú)立程序可以部署在同一個(gè)，或者不同的服務(wù)器上面，從java程序角度來(lái)講，每一個(gè)微服務(wù)就是一個(gè)java進(jìn)程。所以服務(wù)之間的通信就不再是一個(gè)進(jìn)程內(nèi)的呼叫。我們就需要一個(gè)輕量級(jí)通信協(xié)議來(lái)完成各個(gè)分布式服務(wù)之間的通信。而這種通信可以分為兩種，同步和異步。當(dāng)我們需要一個(gè)同步呼叫來(lái)完成一個(gè)業(yè)務(wù)邏輯，通常會(huì)通過(guò)HTTP下的REST API來(lái)實(shí)現(xiàn)，通?？梢赃x擇Spring下的Restful框架或者是Oracle下的JAX-RS。而當(dāng)我們需要服務(wù)之間做異步通信時(shí)，Message會(huì)是一個(gè)很好的協(xié)議。 Java微服務(wù)應(yīng)用程序之間可以使用非常成熟的JMS，如果是Java和非Java程序應(yīng)用之間，現(xiàn)在比較流行的是AMQP協(xié)議。

4. 去中心化數(shù)據(jù)管理 (decentralized data management)

多樣化持久性(Polyglot Persistence)，即讓每一個(gè)微服務(wù)都有其自己的數(shù)據(jù)庫(kù)，并且允許其各自擁有不同類型的數(shù)據(jù)持久化特性一直是微服務(wù)架構(gòu)所倡導(dǎo)的。

當(dāng)我們開(kāi)發(fā)一個(gè)企業(yè)化大型應(yīng)用時(shí)，我們通常會(huì)發(fā)現(xiàn)，數(shù)據(jù)的類型，屬性和被查詢和修改的頻率都會(huì)不一樣，而傳統(tǒng)的單體應(yīng)用下，我們通常會(huì)使用一個(gè)中心數(shù)據(jù)庫(kù)，來(lái)存儲(chǔ)所有數(shù)據(jù)。譬如一個(gè)垂直電商的應(yīng)用里面可以有客戶信息數(shù)據(jù)，商品數(shù)據(jù)，購(gòu)物車(chē)數(shù)據(jù)，訂單數(shù)據(jù)，支付數(shù)據(jù)。單體應(yīng)用下，我們很可能就使用一個(gè)MYSQL數(shù)據(jù)庫(kù)就解決所有問(wèn)題。而微服務(wù)框架下，允許也提倡每一個(gè)服務(wù)模塊下?lián)碛凶约旱臄?shù)據(jù)庫(kù)，這個(gè)數(shù)據(jù)庫(kù)可以是SQL類型的數(shù)據(jù)庫(kù)，譬如Oracle，MYSQL，Postgres等等，也可以是NOSQL類型數(shù)據(jù)庫(kù)，譬如MongoDB，Cassandra, Amazon DynamoDB等等，當(dāng)然你也可以根據(jù)你的數(shù)據(jù)類型，在NOSQL里面來(lái)選擇哪種類型的數(shù)據(jù)庫(kù)。那么說(shuō)我們就不能讓兩個(gè)或多個(gè)微服務(wù)之間共享一個(gè)數(shù)據(jù)庫(kù)了嗎，個(gè)人認(rèn)為是不提倡，但是也不反對(duì)，具體情況具體分析。譬如當(dāng)你需要一個(gè)request call里面的多個(gè)數(shù)據(jù)持久化在一個(gè)事務(wù)內(nèi)完成，在這種情況下，通常一個(gè)SQL數(shù)據(jù)庫(kù)會(huì)讓事情變得簡(jiǎn)單。譬如當(dāng)你擔(dān)心數(shù)據(jù)的一致性能否得到保障，而且要達(dá)到ACID級(jí)別時(shí)，可能分布式數(shù)據(jù)管理會(huì)變得不可能。當(dāng)然如果你一定要分布式管理數(shù)據(jù)的話，可以通過(guò)最終一致性(Eventual Consistency)來(lái)做。實(shí)現(xiàn)數(shù)據(jù)的強(qiáng)一致性，強(qiáng)最終一致性，還是最終一致性一直是分布式計(jì)算下的一個(gè)難題。這也是我們?cè)谠O(shè)計(jì)微服務(wù)架構(gòu)時(shí)可能會(huì)遇到也需要考慮的問(wèn)題。

5. 公共設(shè)施自動(dòng)化 (Infrastructure Automation)

通過(guò)采用一系列的開(kāi)源軟件，自動(dòng)化開(kāi)發(fā)，測(cè)試，部署流程，可以大大提高產(chǎn)品的質(zhì)量和交付能力。

在決定是否要采用微服務(wù)架構(gòu)前，應(yīng)該考慮團(tuán)隊(duì)是否有足夠的經(jīng)驗(yàn)在公共設(shè)施自動(dòng)化方面。實(shí)戰(zhàn)用例告訴我們，那些在微服務(wù)系統(tǒng)上面取得成功的團(tuán)隊(duì)都擁有豐富的連續(xù)集成和連續(xù)交付能力。這涉及到一連串的自動(dòng)化能力，包括編譯，單元測(cè)試，功能測(cè)試，集成測(cè)試，用戶體驗(yàn)測(cè)試和性能測(cè)試上面的自動(dòng)化，包括部署自動(dòng)化。我們只有通過(guò)做大量的自動(dòng)化測(cè)試，才能大大的增強(qiáng)團(tuán)隊(duì)的信心。因?yàn)楫?dāng)我們采用微服務(wù)架構(gòu)時(shí)，我們所要處理的不是一個(gè)單體應(yīng)用所帶來(lái)的問(wèn)題，而且?guī)资畟€(gè)，幾百個(gè)微服務(wù)，甚至是部署在上百個(gè)服務(wù)器上面，到那時(shí)候我們?cè)倏紤]自動(dòng)化，可能未免太晚了。

這邊也值得聽(tīng)一下亞馬遜云服務(wù)團(tuán)隊(duì)一直倡導(dǎo)的兩個(gè)微服務(wù)開(kāi)發(fā)的原則：

1. Two Pizza Size

就是說(shuō)每一個(gè)團(tuán)隊(duì)只需要定兩個(gè)Pizza就能吃飽，當(dāng)然這邊是指美式Pizza，不是意大利 Pizza，基本就是說(shuō)一個(gè)團(tuán)隊(duì)在6 - 10 人之間，這也完全符合一個(gè)敏捷開(kāi)發(fā)團(tuán)體的個(gè)數(shù)。

2. You Build It, You Run It

是指誰(shuí)開(kāi)發(fā)和編譯的軟件，誰(shuí)來(lái)運(yùn)行。這也就是為什么亞馬遜每一個(gè)團(tuán)隊(duì)成員都會(huì)輪流On Call，這也是被很多亞馬遜員工所批評(píng)的。

不管怎么樣我們從這兩個(gè)原則可以看到在采用微服務(wù)架構(gòu)時(shí)候可以采用的方法，每一個(gè)團(tuán)隊(duì)負(fù)責(zé)一個(gè)或者多個(gè)微服務(wù)，采用自動(dòng)化的編譯，測(cè)試，集成，部署，檢測(cè)開(kāi)源工具，讓這個(gè)流程變得很boring，大大提高交付能力。而且負(fù)責(zé)開(kāi)發(fā)的團(tuán)隊(duì)當(dāng)然對(duì)于軟件是最熟悉的，一旦出現(xiàn)什么問(wèn)題，可以立即就能找到根源和解決，而不是需要通過(guò)復(fù)雜的部門(mén)之間的溝通再來(lái)解決問(wèn)題。

這期我們從大數(shù)據(jù)，分布式系統(tǒng)，談到了當(dāng)前非常流行的微服務(wù)架構(gòu)以及其共享的一些重要特征。當(dāng)然，當(dāng)你真正開(kāi)始著手開(kāi)始把一個(gè)單體應(yīng)用變?yōu)橐幌盗形⒎?wù)時(shí)，所需要面臨的挑戰(zhàn)還有很多，譬如怎么來(lái)對(duì)你已經(jīng)存在的碩大的單體應(yīng)用來(lái)解體;譬如當(dāng)你成功解體到一系列的微服務(wù)后，怎么來(lái)解決由于分布式結(jié)構(gòu)導(dǎo)致的系統(tǒng)性能問(wèn)題;譬如當(dāng)你實(shí)現(xiàn)了多樣持久化后，發(fā)現(xiàn)事務(wù)處理變得積極復(fù)雜，怎么來(lái)管理分布式系統(tǒng)下的數(shù)據(jù)，保證數(shù)據(jù)一致性，等等。這些我們希望會(huì)在接下來(lái)幾期進(jìn)行討論。