作為技術(shù)者，我們不能只從技術(shù)的角度來考慮微服務(wù)的價(jià)值，而是要從商業(yè)價(jià)值的角度去衡量它，因?yàn)槭篱g的決策者們最終都是逐利的，其能否帶來更大的商業(yè)價(jià)值這一點(diǎn)才是決策者們首要考慮的因素。

1. 微服務(wù)帶來了擴(kuò)容的彈性

放在第一位的，當(dāng)然是我認(rèn)為最重要的一個(gè)好處，以前單片系統(tǒng)，在使用量達(dá)到系統(tǒng)規(guī)格上限時(shí)，就需要擴(kuò)容，而擴(kuò)容通常都要從購買硬件做起，刀片，存儲(chǔ)……更有甚者甚至還要建設(shè)新的機(jī)房，構(gòu)建時(shí)間動(dòng)輒以月計(jì)算，這在如今是不能夠接受的。
互聯(lián)網(wǎng)時(shí)代，老板們最渴望的是，當(dāng)客戶涌來時(shí)，系統(tǒng)有足夠的容量能夠”笑迎八方客“，而客戶稀少之后，又能夠?qū)①Y源釋放以保持比較低的運(yùn)行成本（哪怕省兩毛錢電費(fèi)也是好的），因此，速度和容量相比，容量的彈性其實(shí)是更重要的考量因素，因?yàn)槿缃裣到y(tǒng)面對(duì)的通常都是上百萬的用戶的沖擊，而你不能讓客戶天天面對(duì) “500” 的錯(cuò)誤。
服務(wù)拆分以后，熱點(diǎn)服務(wù)可以針對(duì)性的進(jìn)行彈性擴(kuò)容，而相對(duì)冷的模塊則可以維持比較低的硬件使用水平?！昂娩撚迷诘度猩稀?，會(huì)為企業(yè)帶來更高的硬件利用率，從而降低擴(kuò)容的成本。而相對(duì)的，服務(wù)拆分帶來的性能損失則在次要位置，并且通過性能優(yōu)化，適當(dāng)?shù)挠布訌?qiáng)，是可以補(bǔ)足的。

春運(yùn)是典型的系統(tǒng)容量和請(qǐng)求無法匹配的場(chǎng)景

2. 微服務(wù)可以一定程度的縮短交付時(shí)間，從而在有限的期限內(nèi)能夠盡可能多的交付功能

老板們當(dāng)然希望多快好省的上線他們的系統(tǒng)帶來商業(yè)利益，而多快好省這四個(gè)因素里面，多和快往往占著很高的比重，因?yàn)楣δ芡陚洌到y(tǒng)可用性就會(huì)比較強(qiáng)，因?yàn)樯暇€快速，就會(huì)更快的搶占市場(chǎng)獲取利益，以戰(zhàn)養(yǎng)戰(zhàn)，推動(dòng)商務(wù)運(yùn)作進(jìn)入正向循環(huán)模式。
而這，正是微服務(wù)的優(yōu)勢(shì)，因?yàn)槲⒎?wù)都是獨(dú)立開發(fā)，因此在明確各服務(wù)之間接口與關(guān)系以后，通過并行開發(fā)的方式，采用某種程度的人海戰(zhàn)術(shù)去堆，確實(shí)可以縮減特性功能的上線時(shí)間。用項(xiàng)目管理上的說法就是，因?yàn)槟愕哪K都獨(dú)立了，因此任務(wù)關(guān)鍵路徑全被拆掉了，而關(guān)鍵路徑縮短就意味著交付時(shí)間的提前。在經(jīng)營者的眼睛里面看，這就意味著可以更快的搶占市場(chǎng)創(chuàng)造價(jià)值。而以戰(zhàn)養(yǎng)戰(zhàn)，迭代獲利，無疑是微服務(wù)的一個(gè)重要魅力。

但是，再強(qiáng)調(diào)一點(diǎn)，老板們的成本并沒有降低，因?yàn)槲⒎?wù)帶來的系統(tǒng)復(fù)雜性的提高，開發(fā)整套系統(tǒng)的成本甚至還增高了，時(shí)間縮短和成本降低沒有必然聯(lián)系，這一點(diǎn)必須要有清醒的認(rèn)識(shí)。

3. 微服務(wù)帶來了功能更新的便捷

如今商業(yè)需求千變?nèi)f化，需求熱點(diǎn)的更迭速度都是以天來計(jì)算，而之前的系統(tǒng)特性從設(shè)計(jì)到交付都需要花費(fèi)半年的時(shí)間，甚至更久。這在如今的商業(yè)模式下是會(huì)錯(cuò)過很多市場(chǎng)窗口期的。系統(tǒng)設(shè)計(jì)的再精妙，再完備，再無懈可擊，不能帶來商業(yè)價(jià)值也不過是垃圾一堆而已。
微服務(wù)的局部更新能力解決了這個(gè)問題，微服務(wù)本質(zhì)上就是在說解耦，整體
微服務(wù)這一點(diǎn)就非常優(yōu)秀，因?yàn)槟K小，因此可以“潤物細(xì)無聲“的一點(diǎn)點(diǎn)的上線，而不用一股腦的扔上去，對(duì)于老板們來講，這確實(shí)太吸引人了，它可以把功能分解成數(shù)個(gè)小服務(wù)逐個(gè)的上線，每次上線速度都會(huì)比原來一整塊的上線要快。就算是某一次更新出錯(cuò)了，你只要把有問題的模塊拿下來就好了，不用那么大張旗鼓的回退。尤其對(duì)于互聯(lián)網(wǎng)企業(yè)來講，是一個(gè)致命的吸引力。

4. 微服務(wù)的架構(gòu)在地理容災(zāi)方面會(huì)有一定的成本降低

做過地理容災(zāi)的人都知道，現(xiàn)在說兩地三中心，同城備份，跨域備份，很多時(shí)候都是以一整套系統(tǒng)為單位進(jìn)行復(fù)制，在不同的地理位置去構(gòu)建完全一樣的系統(tǒng)以備萬一，花錢就是兩倍，三倍甚至更多，這顯然是CXO們不樂意看到的情景。

到了微服務(wù)時(shí)代，每一個(gè)服務(wù)組件都是可以替換的，而且每一個(gè)組件都要求有自愈的功能，我們就可以在組件的粒度上去進(jìn)行更精細(xì)的控制，而且更能充分的發(fā)揮備份系統(tǒng)的能力，最終達(dá)到降低成本的目的。

5. 微服務(wù)帶來了技術(shù)異構(gòu)的可能性

如今的技術(shù)沒有哪個(gè)是完美的，最簡單的，C沒有自動(dòng)管理內(nèi)存的能力，最終寫出了很多泄露內(nèi)存的代碼，Java倒是規(guī)避了這個(gè)，但時(shí)不時(shí)的GC也很讓人困擾。因此很難用同一個(gè)技術(shù)棧去搞定一個(gè)系統(tǒng)所有的問題。從老板們的眼睛來看，當(dāng)你為了系統(tǒng)1%的問題而大動(dòng)干戈的時(shí)候，就得考慮技術(shù)異構(gòu)了。

先放著一個(gè)觀點(diǎn)，沒事兒別談技術(shù)異構(gòu)，建議直到“忍無可忍，無需再忍”的時(shí)候再搞，例如搞一個(gè)Web系統(tǒng)模塊，每個(gè)都很獨(dú)立，但是使用框架五花八門，Spring MVC有，Struts2有，純Servlet也有，請(qǐng)問你的維護(hù)組遇到這么五花八門的模塊的時(shí)候，沒有罵娘嗎？

異構(gòu)過多維護(hù)成本過大，不做異構(gòu)會(huì)在研發(fā)上付出較大代價(jià)之間，建議傾向前者。
實(shí)施之前的評(píng)估，你要考慮的問題有：

1. 團(tuán)隊(duì)的學(xué)習(xí)曲線
2. 新技術(shù)帶來的品質(zhì)問題（更傾向于非功能性問題，例如性能，穩(wěn)定性，安全性問題等）
3. 維護(hù)團(tuán)隊(duì)維護(hù)新組件的成本

（未完待續(xù)...下一章開始真正進(jìn)入討論實(shí)施的話題）