作為技術者，我們不能只從技術的角度來考慮微服務的價值，而是要從商業價值的角度去衡量它，因為世間的決策者們最終都是逐利的，其能否帶來更大的商業價值這一點才是決策者們首要考慮的因素。
1. 微服務帶來了擴容的彈性
放在第一位的，當然是我認為最重要的一個好處，以前單片系統，在使用量達到系統規格上限時，就需要擴容，而擴容通常都要從購買硬件做起，刀片，存儲……更有甚者甚至還要建設新的機房，構建時間動輒以月計算，這在如今是不能夠接受的。
互聯網時代，老板們最渴望的是，當客戶涌來時，系統有足夠的容量能夠”笑迎八方客“，而客戶稀少之后，又能夠將資源釋放以保持比較低的運行成本（哪怕省兩毛錢電費也是好的），因此，速度和容量相比，容量的彈性其實是更重要的考量因素，因為如今系統面對的通常都是上百萬的用戶的沖擊，而你不能讓客戶天天面對 “500” 的錯誤。
服務拆分以后，熱點服務可以針對性的進行彈性擴容，而相對冷的模塊則可以維持比較低的硬件使用水平。“好鋼用在刀刃上”，會為企業帶來更高的硬件利用率，從而降低擴容的成本。而相對的，服務拆分帶來的性能損失則在次要位置，并且通過性能優化，適當的硬件加強，是可以補足的。
2. 微服務可以一定程度的縮短交付時間，從而在有限的期限內能夠盡可能多的交付功能
老板們當然希望多快好省的上線他們的系統帶來商業利益，而多快好省這四個因素里面，多和快往往占著很高的比重，因為功能完備，系統可用性就會比較強，因為上線快速，就會更快的搶占市場獲取利益，以戰養戰，推動商務運作進入正向循環模式。
而這，正是微服務的優勢，因為微服務都是獨立開發，因此在明確各服務之間接口與關系以后，通過并行開發的方式，采用某種程度的人海戰術去堆，確實可以縮減特性功能的上線時間。用項目管理上的說法就是，因為你的模塊都獨立了，因此任務關鍵路徑全被拆掉了，而關鍵路徑縮短就意味著交付時間的提前。在經營者的眼睛里面看，這就意味著可以更快的搶占市場創造價值。而以戰養戰，迭代獲利，無疑是微服務的一個重要魅力。
但是，再強調一點，老板們的成本并沒有降低，因為微服務帶來的系統復雜性的提高，開發整套系統的成本甚至還增高了，時間縮短和成本降低沒有必然聯系，這一點必須要有清醒的認識。
3. 微服務帶來了功能更新的便捷
如今商業需求千變萬化，需求熱點的更迭速度都是以天來計算，而之前的系統特性從設計到交付都需要花費半年的時間，甚至更久。這在如今的商業模式下是會錯過很多市場窗口期的。系統設計的再精妙，再完備，再無懈可擊，不能帶來商業價值也不過是垃圾一堆而已。
微服務的局部更新能力解決了這個問題，微服務本質上就是在說解耦，整體
微服務這一點就非常優秀，因為模塊小，因此可以“潤物細無聲“的一點點的上線，而不用一股腦的扔上去，對于老板們來講，這確實太吸引人了，它可以把功能分解成數個小服務逐個的上線，每次上線速度都會比原來一整塊的上線要快。就算是某一次更新出錯了，你只要把有問題的模塊拿下來就好了，不用那么大張旗鼓的回退。尤其對于互聯網企業來講，是一個致命的吸引力。
4. 微服務的架構在地理容災方面會有一定的成本降低
做過地理容災的人都知道，現在說兩地三中心，同城備份，跨域備份，很多時候都是以一整套系統為單位進行復制，在不同的地理位置去構建完全一樣的系統以備萬一，花錢就是兩倍，三倍甚至更多，這顯然是CXO們不樂意看到的情景。
到了微服務時代，每一個服務組件都是可以替換的，而且每一個組件都要求有自愈的功能，我們就可以在組件的粒度上去進行更精細的控制，而且更能充分的發揮備份系統的能力，最終達到降低成本的目的。
5. 微服務帶來了技術異構的可能性
如今的技術沒有哪個是完美的，最簡單的，C沒有自動管理內存的能力，最終寫出了很多泄露內存的代碼，Java倒是規避了這個，但時不時的GC也很讓人困擾。因此很難用同一個技術棧去搞定一個系統所有的問題。從老板們的眼睛來看，當你為了系統1%的問題而大動干戈的時候，就得考慮技術異構了。
先放著一個觀點，沒事兒別談技術異構，建議直到“忍無可忍，無需再忍”的時候再搞，例如搞一個Web系統模塊，每個都很獨立，但是使用框架五花八門，Spring MVC有，Struts2有，純Servlet也有，請問你的維護組遇到這么五花八門的模塊的時候，沒有罵娘嗎？
異構過多維護成本過大，不做異構會在研發上付出較大代價之間，建議傾向前者。
實施之前的評估，你要考慮的問題有：
- 團隊的學習曲線
- 新技術帶來的品質問題（更傾向于非功能性問題，例如性能，穩定性，安全性問題等）
- 維護團隊維護新組件的成本
（未完待續...下一章開始真正進入討論實施的話題）
