细想一下微服务的进化铺垫，我们为什么要拆服务？是由于单体应用的臃肿庞大且耦合性过高的特性。所以我们在拆分的过程中，更多的考虑方面是在如何避免单体应用的耦合问题，不然拆出来的一样是一个相互牵扯的单体微应用，所以我们的关注点应该是在每个服务的松散耦合上，确定好它的边界，让每个服务能做到真正的松耦合，而不仅仅是大小问题。
诚然，小服务确实是维护性更高。但我们微服务的目标，更多的是定义我们的工作方式，比如定义为可由小团队自主开发，并且交付时间短，与其他团队协作少，不会相互影响的工作方式。
所以我们服务的设计和定义，需遵循我们的目标法则去规划的，而这个法则就是服务内的高内聚和服务间的低耦合。
微服务架构通过把一些小的，松耦合的服务组织在一起，重新定义了我们的应用，这样的结果是提升了我们开发阶段的效率，特别是可维护性，可测试性和可部署性，通过这样的方式影响着团队的效率提升。
服务的本质每个构成微服务架构体系的服务，本质都是一个可独立运行的应用程序。
这个服务是由一组边界清晰，高内聚的职责组成，而且它可以做自己的负载均衡，独立部署，独立发布，能够快速脱离单体应用的局限性快速上线。
这也是微服务的优势所在，只要做到接口兼容或者版本兼容，不必做过多的服务依赖。
优点微服务的优点众多，但我认为它最重要的是改变着我们的工作方式，如：
更加契合敏捷开发
我们知道，敏捷开发这种软件工程方法已经在很多公司中采用了，敏捷开发的意义在于更快速的交付可运行版本以及迭代做功能最小闭环，它是这个信息时代的必然产物。当我们采用微服务时，在团队自治的同时，意味着更快速的开发和交付。
敏捷开发带来的不仅仅是开发模式上的改变，也带来了组织结构的变化，衍生出更多的小团队自治，小团队实施敏捷开发，带来更快的功能迭代和独立发布，即使出现问题也不会影响整个应用。
Devops文化的推广
在Neal Ford的微服务理念中，Microservices are the first post DevOps revolution architecture，DevOps所涵盖的一系列文化和理念，是微服务演进过程中必不可少的先决条件。
微服务的流行，更好的推动了Devops文化，它们是相辅相成的。
比较确定的说，在传统的运维模式下，是很难有效实现微服务架构的，因为微服务在治理层面需要自动化基础设施、自动化部署、自动化验证、以及利用有效的工具完成运维、监控、告警等。而只有将DevOps与微服务紧密的结合起来，才能达到事半功倍的效果。
技术栈的选择
当我们采用单体服务时，它所使用的编程语言就已经确定了，但微服务支持使用不同的语言开发，允许你选择合适的技术栈。
我们的企业发展能存活的根本是什么？就是能赚钱才能活下去，换言之也就是对成本的控制。当我们能够采用适合自己的成本投入方式，在各个环节和服务采用最合适的技术栈，能够给企业的投入成本做一定的保障。
组织结构的变化
组织结构变化会给我们带来什么好处？
其实我们一直在暗示着，服务的职责要单一，做到专，然而这个专并不仅仅在服务的职责层面上，还有在组织结构上， 微服务势必会影响到我们的中台战略能力，所以我们更需要不同的组专注于不同的技术和业务。
简单点说，让专业的人做专业的事！这样才能更好的提高整体的生产效率，而不是事事都有牵绊。
云生态下的新技术冲击
这个似乎并不是优点，但我相信对很多人来说，这又确切是个优点，因为这些技术对所有有技术抱负的人来说，造就了一个很好的时代。
当我们采用微服务时，目光已经不能仅局限于应用层面的开发了，容器化，服务编排工具，服务网格，云原生等新生的技术，让我们知道如何更好的治理好自己的服务群，支撑自己的服务更好的扩展。
挑战