1、什么是微服務(wù)？

微服務(wù)是一種架構(gòu)風(fēng)格，一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。微服務(wù)架構(gòu)模式（Microservices Architecture Pattern）的目的是將大型的、復(fù)雜的、長期運(yùn)行的應(yīng)用程序構(gòu)建為一組相互配合的服務(wù)，每個(gè)服務(wù)都可以很容易做局部修改。微服務(wù)架構(gòu)帶來可獨(dú)立部署、高擴(kuò)展與伸縮、自由選擇開發(fā)語言、高效利用資源、故障隔離等優(yōu)點(diǎn)，同時(shí)也因?yàn)榉?wù)多帶來分布式事務(wù)、服務(wù)之間通信、監(jiān)控、部署等新的問題。

2、為什么要用微服務(wù)？

整體式架構(gòu)應(yīng)用圖(以華為軟件開發(fā)云為假設(shè)-其實(shí)他應(yīng)該屬于微服務(wù)架構(gòu))：

整體式架構(gòu)的不足

使用傳統(tǒng)的整體式架構(gòu)(Monolithic Architecture)應(yīng)用開發(fā)系統(tǒng)易于開發(fā)，易于調(diào)試，也易于部署。在早期這類應(yīng)用運(yùn)行的很好，不幸的是，這種簡單方法卻有很大的局限性。

1)一個(gè)簡單的應(yīng)用會(huì)隨著時(shí)間推移逐漸變大。在每次的sprint中，開發(fā)團(tuán)隊(duì)都會(huì)面對(duì)新story，新的task，然后開發(fā)許多新代碼。幾年后，這個(gè)小而簡單的應(yīng)用會(huì)逐漸變大。

2)一旦你的應(yīng)用變成一個(gè)又大又復(fù)雜的怪物，開發(fā)團(tuán)隊(duì)肯定很痛苦。由于應(yīng)用太大太復(fù)雜，以至于任何單個(gè)開發(fā)者都不可能搞懂它。因此，修正bug和正確的添加新功能變的非常困難，并且很耗時(shí)。

3)整體式架構(gòu)應(yīng)用也會(huì)降低開發(fā)速度。應(yīng)用越大，啟動(dòng)時(shí)間會(huì)越長。如果開發(fā)者需要經(jīng)常重啟應(yīng)用，那么大部分時(shí)間就要在等待中渡過，生產(chǎn)效率受到極大影響。

4)復(fù)雜而巨大的整體式架構(gòu)應(yīng)用不利于持續(xù)性開發(fā)。今天，SaaS應(yīng)用常態(tài)就是每天會(huì)改變很多次，而這對(duì)于整體式架構(gòu)模式非常困難。

5)整體式架構(gòu)應(yīng)用另外一個(gè)問題是可靠性。因?yàn)樗心K都運(yùn)行在一個(gè)進(jìn)程中，任何一個(gè)模塊中的一個(gè)bug，比如內(nèi)存泄露，將會(huì)有可能弄垮整個(gè)進(jìn)程。

6)整體式架構(gòu)應(yīng)用使得采用新架構(gòu)和語言非常困難。比如你的代碼使用A框架寫的，如果想改成B框架，無論是時(shí)間還是成本都是非常昂貴的。因此，這是一個(gè)無法逾越的鴻溝。

微服務(wù)架構(gòu)圖（以華為軟件開發(fā)云為例）：

微服務(wù)架構(gòu)的好處

第一，通過分解巨大單體式應(yīng)用為多個(gè)服務(wù)的方法解決了復(fù)雜性問題。在功能不變的情況下，應(yīng)用被分解為多個(gè)可管理的分支或服務(wù)。每個(gè)服務(wù)都有一個(gè)用RPC-或者消息驅(qū)動(dòng)API定義清楚的邊界。微服務(wù)架構(gòu)模式給采用單體式編碼方式很難實(shí)現(xiàn)的功能提供了模塊化的解決方案，由此，單個(gè)服務(wù)很容易開發(fā)、理解和維護(hù)。

第二，這種架構(gòu)使得每個(gè)服務(wù)都可以有專門開發(fā)團(tuán)隊(duì)來開發(fā)。開發(fā)者可以自由選擇開發(fā)技術(shù)，提供API服務(wù)。這種自由意味著開發(fā)者不需要被迫使用某項(xiàng)目開始時(shí)采用的過時(shí)技術(shù)，他們可以選擇現(xiàn)在的技術(shù)。甚至于，因?yàn)榉?wù)都是相對(duì)簡單，即使用現(xiàn)在技術(shù)重寫以前代碼也不是很困難的事情。

第三，微服務(wù)架構(gòu)模式是每個(gè)微服務(wù)獨(dú)立的部署。開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對(duì)本服務(wù)的影響。這種改變可以加快部署速度。團(tuán)隊(duì)可以采用AB測試，快速的部署變化。微服務(wù)架構(gòu)模式使得持續(xù)化部署成為可能。

最后，微服務(wù)架構(gòu)模式使得每個(gè)服務(wù)獨(dú)立擴(kuò)展。你可以根據(jù)每個(gè)服務(wù)的規(guī)模來部署滿足需求的規(guī)模。甚至于，你可以使用更適合于服務(wù)資源需求的云服務(wù)。比如，你可以為計(jì)算密集型服務(wù)選擇高配置的云主機(jī)，而在為存儲(chǔ)密集型的服務(wù)選擇高帶寬高存儲(chǔ)的云主機(jī)。

3、微服務(wù)，真的適合你么？

提到微服務(wù)架構(gòu)時(shí)，我們常常會(huì)與整體式架構(gòu)進(jìn)行比較，整體式架構(gòu)存在如下缺點(diǎn)：代碼維護(hù)難度大，臃腫的部署，局限的彈性與擴(kuò)展能力，阻礙團(tuán)隊(duì)與技術(shù)革新等等；微服務(wù)架構(gòu)存在如下優(yōu)點(diǎn)：代碼維護(hù)簡化，可獨(dú)立部署，高擴(kuò)展與伸縮，自由選擇開發(fā)語言等優(yōu)點(diǎn)。那么整體式架構(gòu)真的這么差嗎？顯然不是。

在復(fù)雜度較小時(shí)采用整體式架構(gòu)的生產(chǎn)率更高，復(fù)雜度到了一定規(guī)模時(shí)，單體應(yīng)用的生產(chǎn)率開始急劇下降，這時(shí)對(duì)其進(jìn)行微服務(wù)化的拆分才是合理的。所以說脫離業(yè)務(wù)場景，空談架構(gòu)絕對(duì)是耍流氓。

再牛逼的架構(gòu)設(shè)計(jì)，如果無法在業(yè)務(wù)場景中落地實(shí)施，也只是空談。因此架構(gòu)需要服務(wù)于業(yè)務(wù)，針對(duì)不同的業(yè)務(wù)場景架構(gòu)設(shè)計(jì)也會(huì)不同，架構(gòu)設(shè)計(jì)不必追求高大上，只要能滿足業(yè)務(wù)發(fā)展需求，便是好架構(gòu)。

此外，好的架構(gòu)不完全是設(shè)計(jì)出來的，隨著業(yè)務(wù)量、請(qǐng)求量的增長，好的架構(gòu)是演化而來的。微服務(wù)架構(gòu)之所以得到廣泛認(rèn)可，源于對(duì)于業(yè)務(wù)多變性的不可預(yù)測，微服務(wù)架構(gòu)能夠不斷的自演化，進(jìn)而快速適應(yīng)業(yè)務(wù)變化。此外，微服務(wù)也有他的不足之處：

第一，微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會(huì)帶來固有的復(fù)雜性。

第二，分區(qū)的數(shù)據(jù)庫架構(gòu)在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫，這對(duì)開發(fā)者提出了更高的要求和挑戰(zhàn)。

第三，測試一個(gè)基于微服務(wù)架構(gòu)的應(yīng)用也是很復(fù)雜的任務(wù)。

第四，微服務(wù)架構(gòu)模式應(yīng)用的改變將會(huì)波及多個(gè)服務(wù)。

第五，部署一個(gè)微服務(wù)應(yīng)用也很復(fù)雜。一個(gè)微服務(wù)應(yīng)用一般由大批服務(wù)構(gòu)成。成功部署一個(gè)微服務(wù)應(yīng)用需要開發(fā)者有足夠的控制部署方法，并高度自動(dòng)化。

鑒于上述原因，如果公司的長期業(yè)務(wù)規(guī)劃不需要微服務(wù)架構(gòu)或者公司的實(shí)際情況不具備實(shí)施微服務(wù)一些基本的條件，不建議各位盲目邁向微服務(wù)這一新興架構(gòu)領(lǐng)域。如果準(zhǔn)備早點(diǎn)進(jìn)行技術(shù)積累，也可以從試點(diǎn)開始，逐步在團(tuán)隊(duì)中推行微服務(wù)架構(gòu)。

4、微服務(wù)，如果真的適合你，應(yīng)該怎么做？

1)買書學(xué)習(xí)。

2)上網(wǎng)查資料學(xué)習(xí)。

3)用華為軟件開發(fā)云，讓華為專家指導(dǎo)你。