技术方法论：向微服务迈进：
理论：“软件研发中任何一项技术、方法、架构都不可能是银弹"—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个说得上话的人。——邓巴数
