單體式應用向微服務架構遷移實踐經驗
1、這些都是推動微服務誕生的重要因素
2、領域驅動設計指導我們如何分析并模型化復雜的業務
3、敏捷方法論幫助我們消除浪費，快速反饋；
4、持續交付促使我們構建更快、更可靠、更頻繁的軟件部署和交付能力；
5、虛擬化和基礎設施自動化( Infrastructure As Code)則幫助我們簡化環境的創建、安裝；
6、DevOps文化的流行以及特性團隊的出現，使得小團隊更加全功能化
獨立測試與部署
單塊架構系統運行在一個進程中，因此系統中任何程序的改變，都需要對整個系統重新測試并部署。 而對于微服務架構而言，不同服務之間的打包、測試或者部署等，與其它服務都是完全獨立的。對某個服務所做的改動，只需要關注該服務本身。從這個角度來說，使用微服務后，代碼修改、測試、打包以及部署的成本和風險都比單塊架構系統降低很多。
按需伸縮
單塊架構系統由于單進程的局限性，水平擴展時只能基于整個系統進行擴展，無法針對某一個功能模塊按需擴展。 而服務架構則可以完美地解決伸縮性的擴展問題。系統可以根據需要，實施細粒度的自由擴展。
錯誤隔離性
微服務架構同時也能提升故障的隔離性。例如，如果某個服務的內存泄露，只會影響自己，其他服務能夠繼續正常地工作。與之形成對比的是，單塊架構中如果有一個不合格的組件發生異常，有可能會拖垮整個系統。
團隊全功能化
康威定律（Conway’s law）指出：一個組織的設計成果，其結構往往對應于這個組織中的溝通結構（organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations）。傳統的開發模式在分工時往往以技術為單位，比如UI團隊、服務端團隊和數據庫團隊，這樣的分工可能會導致任何功能上的改變都需要跨團隊溝通和協調。而微服務則倡導圍繞服務來分工，團隊需要具備服務設計、開發、測試到部署所需的所有技能。
