年度總結(jié)，看完這個你應(yīng)該知道如何回答別人的問題了。

一、微服務(wù)的定義

實(shí)際上沒有太明確的定義，我覺得很多互聯(lián)網(wǎng)公司已經(jīng)是微服務(wù)了，Martin Fowler的定義也比較模糊，簡單的幾個特征，可以總結(jié)為：

• 專注做一件事;
• 獨(dú)立的進(jìn)程;
• 獨(dú)立的部署;
• 小;
• 輕量級的通信機(jī)制。

如果聯(lián)想一下相關(guān)詞匯，又會想到服務(wù)化、SOA，在我看來，根本不需要糾結(jié)這些概念性的東西，就好比SOA的時代，也不是所有的應(yīng)用都采用ws，而微服務(wù)，代碼行數(shù)，通信機(jī)制這些也未必能滿足定義。最重要的是適合業(yè)務(wù)場景，不必完全按照微服務(wù)的定義來做。每個公司都有自己的業(yè)務(wù)特色，適合的一定是個性的。因?yàn)榧軜?gòu)不只是技術(shù)因素決定的，跟業(yè)務(wù)、公司文化、組織結(jié)構(gòu)、人員水平都息息相關(guān)。例如facebook一直奉行的單體應(yīng)用，據(jù)說一個應(yīng)用有千萬行代碼級別，同時發(fā)布，做的也非常棒，也能很好的持續(xù)交付，那是因?yàn)樯厦嫖艺f的那些因素都能滿足，如果換一個公司，未必能做的很好。當(dāng)然，對于我們來說，我們要選的是那條最好走的路。

二、微服務(wù)帶來的好處

實(shí)際上所說的所有微服務(wù)的好處都是來自于和單體應(yīng)用的對比。

組織結(jié)構(gòu)。組織結(jié)構(gòu)和架構(gòu)是映射關(guān)系，如果你想知道某個公司的架構(gòu)是怎么做的，完全可以根據(jù)組織結(jié)構(gòu)推導(dǎo)出來。當(dāng)一個團(tuán)隊(duì)的人數(shù)太多的時候，溝通效率急劇下降，團(tuán)隊(duì)成員的主人翁精神也降低一個層次。這和敏捷開發(fā)是一致的。

功能復(fù)用。抽象通用的部分，減少重復(fù)代碼，本身就是效率的提升。另一點(diǎn)，因?yàn)榉?wù)被切分為足夠小的粒度，容易變更。假設(shè)是一個大的應(yīng)用，要進(jìn)行重構(gòu)，相對于微服務(wù)來說，要復(fù)雜的多，因?yàn)槟悴豢赡苤蛔鲋貥?gòu)，而不去接新的需求。如果切分的粒度夠小，完全可以在接口不變的情況下，神不知鬼不覺的重構(gòu)。

容錯。服務(wù)運(yùn)行在不同的進(jìn)程中，無疑隔離性更好，某一個點(diǎn)導(dǎo)致的故障影響面更小。

三、微服務(wù)帶來的災(zāi)難

最重要的是適合業(yè)務(wù)場景，不必非得采用微服務(wù)，微服務(wù)并不是一種炫酷的技術(shù)或者架構(gòu)思想，同時采用微服務(wù)會帶來很多問題：

依賴關(guān)系。原來一個應(yīng)用可能會被拆分成幾個或者幾十個應(yīng)用，服務(wù)數(shù)量爆炸式增長，導(dǎo)致依賴關(guān)系復(fù)雜，除非有一套非常好的服務(wù)注冊發(fā)現(xiàn)機(jī)制，漂亮的依賴關(guān)系統(tǒng)計(jì)圖，否則在服務(wù)數(shù)量超過100的時候，無論哪個架構(gòu)師都搞不明白他們之間到底是什么關(guān)系。同時對開發(fā)人員遵守標(biāo)準(zhǔn)、規(guī)范的要求也空前提升。

性能。原本進(jìn)程內(nèi)的調(diào)用關(guān)系變成了網(wǎng)絡(luò)調(diào)用，一次rpc變成了幾次或者幾十次rpc，同等條件下性能損失嚴(yán)重。(如果采用http+json，比netty+kryo、protobuf、thrift又會下降幾乎一半性能，包括響應(yīng)時間和吞吐量)

一致性。原本本地事務(wù)有可能變成了分布式事務(wù)，這個非?？简?yàn)服務(wù)切分的規(guī)則，考驗(yàn)架構(gòu)師對業(yè)務(wù)的理解程度。就算采用最終一致性，也要在各個服務(wù)中做好容錯機(jī)制，假設(shè)調(diào)用失敗如何處理，如果重試，重試幾次失敗怎么辦?調(diào)用成功，返回ack失敗時，怎么保證生產(chǎn)者的冪等性。

復(fù)雜度。服務(wù)數(shù)量多，依賴關(guān)系多，給開發(fā)、測試都帶來了更大的挑戰(zhàn)。架構(gòu)師也需要定義一些規(guī)則，服務(wù)分層。例如服務(wù)分為原子服務(wù)、組合服務(wù)、流程服務(wù)，下層是不能調(diào)用上層的，如果允許調(diào)用，會導(dǎo)致循環(huán)依賴的問題。同一份數(shù)據(jù)可能上上下下調(diào)用了好多次。有可能只需要調(diào)用一次原子服務(wù)，因?yàn)樯蠈拥幕靵y，下來可能變成了幾次。

四、如何做好微服務(wù)

要做好，就要先做好準(zhǔn)備。

提升架構(gòu)能力非常重要的一個手段就是平臺化驅(qū)動。通過抽離通用部分，用最核心的人去研發(fā)，做到最穩(wěn)定。如果非要說google的架構(gòu)能力遠(yuǎn)遠(yuǎn)領(lǐng)先于百度，那并不是百度的業(yè)務(wù)開發(fā)人員比google的差很多，而是google平臺化的架構(gòu)遠(yuǎn)遠(yuǎn)強(qiáng)于百度。例如容器、分布式數(shù)據(jù)庫。

So，要做好微服務(wù)，先要解決的是相關(guān)的框架、中間件、組件、通用服務(wù)。在這些都準(zhǔn)備好的了情況下，業(yè)務(wù)開發(fā)人員根本不需要關(guān)心太多。

舉幾個例子，

• 要解決依賴關(guān)系問題，就要有一個服務(wù)發(fā)現(xiàn)注冊中心。
• 要解決性能問題，讀的問題可以通過緩存來補(bǔ)償。可以采用并行、異步、非阻塞等方式補(bǔ)償性能，當(dāng)然這些都可以封裝到通用的rpc框架里面。
• 要解決一致性問題，就要有一個通用的事務(wù)處理平臺。如果采用最終一致性，就把重試策略封裝到框架。
• 要解決復(fù)雜度問題，就要定義一系列標(biāo)準(zhǔn)、規(guī)范，通過工具來檢測問題。建立一整套devops平臺，自動化測試平臺。通過調(diào)用鏈分析，迅速定位問題。

五、大師寄語

ThoughtWorks首席科學(xué)家MartinFowler 在Monolith First中寫道：

所有的成功的微服務(wù)的故事都是以單體應(yīng)用太大開始的，逐步的拆分。我聽到的所有的一個從無到有被創(chuàng)建為微服務(wù)的系統(tǒng)，他們都以遇到很大麻煩而告終。

六、總結(jié)

總結(jié)一下，做微服務(wù)之前，需要審視一下，目前的業(yè)務(wù)場景、技術(shù)實(shí)力，是不是需要把應(yīng)用拆分到“微”的粒度。優(yōu)雅的架構(gòu)總是和實(shí)用的架構(gòu)有距離的。在沒有足夠的能力之前，應(yīng)該盡量選擇更實(shí)用的架構(gòu)。

微服務(wù)之所以被炒的如此之熱，主要是因?yàn)槿萜鞯某霈F(xiàn)，PaaS服務(wù)提供商，不斷的鼓吹微服務(wù)帶來的好處，以此來吸引眾多中小開發(fā)者使用其服務(wù)。像go語言一樣，中國似乎又領(lǐng)先世界了。

如果你的體量還不大，首先應(yīng)該解決的是搭建好一套絕對穩(wěn)定的平臺化服務(wù)，待體量逐漸長大，再去根據(jù)實(shí)際需要進(jìn)行不斷發(fā)分裂。團(tuán)隊(duì)也隨之變化。

如果體量足夠大，飽受單體應(yīng)用之苦，也應(yīng)該先建設(shè)平臺化服務(wù)，建設(shè)好之后，先按照大的粒度進(jìn)行拆分，逐步“微”化，否則，可能在你還沒成功之前，已經(jīng)被解雇了。

【本文來源：奔跑中的蝸牛公眾號】