技術方法論：向微服務邁進：

理論：“軟件研發中任何一項技術、方法、架構都不可能是銀彈"—Fred Brooks

哪些場景適合用微服務，呢些不適用？（微服務存在哪些理解誤區、應用前提） 一些被驗證過、被總結為經驗的最佳實踐有哪些？
目的：微服務的驅動力
微服務的目的：The goal of microservices is to sufficiently decompose the application in order to facilitate agile application development and deployment.

微服務的目的就是有效的拆分應用，以實現敏捷開發和部署。

為什么需要微服務？
凡事應先有目的，有預期收益再談行動才合理。
有人說邁向微服務的目的是為了追求更先進的架構形式？這句話沒什么含量，任何一次架構演進都是為了更加先進而沒有為了倒退的。
有人說微服務是信息發展的必然階段，為了應對日益龐大的壓力，獲得更好的性能。這個觀點看似合理具體，準確，實則不然。筆者個人態度是反對以獲得更好性能為主要目的的，這可以是輔助功能，現在單體通過采用可擴縮設計，同樣能夠集群部署，更重要的是云計算數據中心算力可以認為是無限的，且能通過擴展硬件的手段解決問題就別用復雜的軟件方法（原因在于銀彈中說過：硬件的成本能持續下降而軟開不行），而且性能也不會因為采用了微服務架構就憑空產生。把系統拆分為微服務，一旦在某個關鍵地方卡住了業務流程，其整體的結果往往還不如單體。沒有清晰的職責劃分，導致擴展性失效，多加機器往往還不如單機。
所以 軟件系統選擇微服務架構，通常比較常見的、合理的驅動力來自組織內部、外部兩方面，先列舉一些外部因素：當意識到沒有什么技術可以包打天下；當個人能力成為明顯的制約；內部因素：變化特別快的創！
新業務系統往往會自主選擇微服務，因為頻繁的更迭會讓開發者疲憊不堪；
總之，選擇微服務一定是經過權衡利弊的。微服務最主要的目的是對系統進行有效的拆分，實現物理層面的隔離。微服務的核心價值就是拆分之后的系統能讓局部單個服務有可能實現敏捷的卸載、部署、開發、升級。局部的持續更迭，是系統具備 Phoenix 特性的必要條件。
前提：微服務需要的條件
第一個先決條件就是決策者必須堅定不移的使用微服務，溝通決定設計；
第二個前提條件就是組織中具備一些對微服務有充分理解、有一定實踐經驗的技術專家。雖然微服務對于開發者來說是友善的，但對于架構者確要求很高，

我敢斷言你的社交是不超過5個知己好友，15個可信任的伙伴，35個普通朋友，150個說得上話的人。——鄧巴數