前世
想想过去的JavaWeb是如何构建的，最早是使用MVC的传统设计模式，即模型（Model），视图（View），控制器（Controller）构成。简单来说控制器接收请求转发到对应的模型层进行业务逻辑处理。处理完成后再通过控制器转发到视图层渲染展示。这是一种前后端集成开发的模式也就是前后端不分离。SpringMVC应运而生
亚当斯密在国富论中提到社会的分工是促进社会进步提高生产率的一种方式之一。同理将前后端分离提高开发效率也是如此。前端只负责视图的渲染和界面的设计美化。后端负责逻辑处理和数据反馈。在这中间会使用JSON来进行交互。然后把API暴露给前端，前端需要什么数据，进行什么处理只需要请求对应的接口就可以了。这也是SpringBoot的主要应用场景。
今生
想想过去我们写的程序是不是都放在一个工程目录下的，也就是他们是糅合在一起的。随着单体应用的规模和复杂度的增长，在该应用程序上进行开发的各个团队的沟通与合作成本没有减少。每当各个团队需要修改代码时，整个应用程序都需要重新构建、重新测试和重新部署。那么我们能不能单独把每一项服务拿出来。每一个服务的大小适当。当我们需要添加一项服务，修改一项服务时就不用牵一发而动全身了。这样是不是我们常说的降低了耦合度呢。
微服务的特征
应用程序逻辑分解为具有明确定义了职责范围的细粒度组件，这些组件互相协调提供解决方案。
每个组件都有一个小的职责领域，并且完全独立部署。微服务应该对业务领域的单个部分负责。此外，一个微服务应该可以跨多个应用程序复用。
微服务通信基于一些基本的原则（注意，我说的是原则而不是标准），并采用HTTP和JSON（JavaScript Object Notation）这样的轻量级通信协议，在服务消费者和服务提供者之间进行数据交换。
服务的底层采用什么技术实现并没有什么影响，因为应用程序始终使用技术中立的协议（JSON是最常见的）进行通信。这意味着构建在微服务之上的应用程序能够使用多种编程语言和技术进行构建。
微服务利用其小、独立和分布式的性质，使组织拥有明确责任领域的小型开发团队。这些团队可能为同一个目标工作，如交付一个应用程序，但是每个团队只负责他们在做的服务。
总结
我们再来看一看“微服务” 可以拆分成两部分，一个是“微”，一个是“服务”。想想我们在大学期间写的最多的图书管理系统。这里图书管理系统就是一个服务，他里面有登录服务，借书服务，还书服务等。我们以前开发的时候会将他们整合在一起合成一个服务。微服务就是将这些登录服务，借书服务拿出来单独作为一个服务。当我们需要对它进行修改，测试时就不会影响借书服务和还书服务。当然这会涉及到服务间通信问题。
