微服务是面向服务架构（SOA）的变体，使用各种相互依赖的模块来标识它们之间的相互关系，并可衡量每个模块之间的松耦合程度。
基于微服务的架构主要关注：
- 自然地强制执行模块化结构。
- 适用于持续交付软件开发过程。
- 对应用程序的一小部分进行更改只需要重建和重新部署一个或少量服务
- 坚持诸如此类的原则
- 细粒度接口（可独立部署的服务）
- 业务驱动的开发（例如域驱动设计）
- 云应用程序架构
- 多语言编程和持久性
- 轻量级容器部署
- 分散的持续交付
- DevOps提供全面的服务监控
将单个App开发为一套小型服务，每个小型服务都在自己的流程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务围绕业务功能构建，可通过全自动部署机制独立部署。这些服务至少集中管理，可以用不同的编程语言编写，并使用不同的数据存储技术。
微服务的优点包括
- 新技术和流程适应变得更加容易。您可以使用我们创建的新微服务来尝试新技术。
- 更快的发布周期。
- 可扩展到云。
应用和团队的两个方面的功能分解是构建成功的微服务架构的关键。这样才能实现松耦合（REST接口）和高内聚（多个服务可以相互组合以定义更高级别的服务或应用程序）。功能分解提供了敏捷性，灵活性，可伸缩性和其他功能，但业务目标仍然是创建应用程序。
聚合器微服务设计模式
第一种，也许是最常见的是聚合器微服务设计模式。在最简单的形式中，聚合器可能就是一个简单的网页，它调用多个服务来实现应用程序所需的功能。由于使用轻量级REST机制公开了每个服务（服务A，服务B和服务C），因此网页可以检索数据并相应地处理/显示数据。
代理微服务设计模式
代理微服务设计模式是聚合器的变体。在这种情况下，不需要在客户端上进行聚合，但可以根据业务需要调用不同的微服务。
链式微服务设计模式
链式微服务设计模式对请求产生单个合并响应。在这种情况下，来自客户端的请求由服务A接收，服务A然后与服务B通信，服务B又可以与服务C通信。所有服务可能使用同步HTTP请求/响应消息传递。
共享数据微服务设计模式
微服务的设计原则之一是自治。这意味着该服务是全栈并且可以控制所有组件 - UI，中间件，持久性，事务。这允许服务是多语言，并使用正确的工具来完成正确的工作。例如，如果可以使用NoSQL数据存储，则更合适，在SQL数据库中会干扰数据独立性。
在这种设计模式中，一些在链条中的微服务可能共享缓存和数据库存储。这只有在两个服务之间存在强耦合时才有意义。有些人可能认为这是一种反模式，但在某些情况下可能需要业务需求来遵循这一点。对于基于微服务设计的绿地应用来说，这肯定是一种反模式。
异步消息微服务设计模式
虽然REST设计模式非常普遍，并且很好理解，但它具有同步的限制，因此阻塞。可以实现异步，但这是以特定于应用程序的方式完成的。由于这一点，一些微服务架构可能会选择使用消息队列而不是REST请求/响应。
Spring Boot :
Spring Boot是一个旨在简化新服务创建的框架。对于最简单的用例，所需的库已经捆绑在所谓的Spring starter配件组合和版本中。我们不必将应用程序部署到应用服务器中，而是独立运行我们的应用程序或在Docker容器中运行，因为应用已经包含服务器。Spring Boot可用于设置基于REST的微服务。
Spring Boot针对大多数用例简化了构建基于Java的微服务。与Dropwizard等框架不同，它更易于使用，并提供更丰富的功能集。Spring Boot提供了大量额外的库和集成，如Ribbon，Zuul，Hystrix，与MongoDB，Redis，GemFire，Elasticsearch，Cassandra或Hazelcast等数据库的集成。
借助Maven和Gradle，Java开发人员可以支持功能强大且受到广泛支持的构建系统，这些构建系统比Play Framework等框架的专用构建系统更常见，更易于集成到现有结构中。与传统的Web应用程序相比，Spring Boot很精简。对于大多数项目，向项目添加依赖项足以从头开始获得良好项目起步，无需调整默认配置。