前言
最近SOA、Agile、Cloud、DevOps、Microservice等這些概念甚嚣塵上，追求務實的程式員兄弟們也是被折騰得夠嗆。對于這些概念，如果你不去了解，顯得很low；等你去了解了，又發現不知所雲。免不得爆一句粗口：真tm瞎扯淡...吐槽歸吐槽，下面還是一起看看，微服務到底說的是啥？
微服務是啥
别急，先來看看微服務是怎麼做的？
傳統軟體開發，經典的3層結構，代碼達成war包，部署在j2ee容器（tomcat/jboss）裡即可。
乍一看，沒毛病啊，咱這幾年都是這麼整的，系統也玩得很溜啊。
确實，在業務相對簡單的場景下，這樣做确實沒啥大問題。但是當業務膨脹到一定級别，比如一個大的crm，涉及幾十個大功能點。這時候怕是任何一位開發同學想改點代碼都感覺有點菊緊吧。
某官方給出的缺點，可參考下：
- 開發效率低：所有的開發在一個項目改代碼，遞交代碼互相等待，代碼沖突不斷
- 代碼維護難：代碼功能耦合在一起，新人不知道何從下手
- 部署不靈活：建構時間長，任何小修改必須重新建構整個項目，這個過程往往很長
- 穩定性不高：一個微不足道的小問題，可以導緻整個應用挂掉
- 擴充性不夠：無法滿足高并發情況下的業務需求
再來看看，所謂的微服務是怎麼做的
1個應用拆成3個應用就叫微服務了？沒錯，簡單來說， 微服務的目的是根據業務有效的拆分應用，實作靈活開發和部署 。
微服務的一些特點，慢慢體會吧：
- 分布式服務組成的系統
- 按照業務而不是技術來劃分組織
- 做有生命的産品而不是項目
- Smart endpoints and dumb pipes（我的了解是強服務個體和弱通信）
- 自動化運維（DevOps）
- 容錯
- 快速演化
微服務怎麼實踐
理論很豐滿，現實很骨感，具體怎麼落地啊？這需要回答下面幾個問題：
- 用戶端如何通路這些服務？
- 服務之間如何通信？
- 這麼多服務，怎麼找?
- 服務挂了怎麼辦？
解決了上述問題後，你會發現微服務的優點和挑戰一樣多。
優點
- 每個服務足夠内聚，足夠小，代碼容易了解、開發效率提高
- 服務之間可以獨立部署，微服務架構讓持續部署成為可能；
- 每個服務可以各自進行x擴充和z擴充，而且，每個服務可以根據自己的需要部署到合适的硬體伺服器上；
- 容易擴大開發團隊，可以針對每個服務（service）元件開發團隊；
- 提高容錯性（fault isolation），一個服務的記憶體洩露并不會讓整個系統癱瘓；
- 系統不會被長期限制在某個技術棧上。
挑戰
- 開發人員要處理分布式系統的複雜性
- 服務管理的複雜性
- 應用微服務架構的時機如何把握？對于業務還沒有理清楚、業務資料和處理能力還沒有開始爆發式增長之前的創業公司，不需要考慮微服務架構模式，這時候最重要的是快速開發、快速部署、快速試錯。
微服務對我們的觸動我覺得更多的是思維上的，對于微服務架構， 技術上不是問題，意識比工具重要。