使用SpringBoot构建微服务

GitHub: https://github.com/binbinm/SpringMicroservices

1 总述

1.1 基于微服务的架构的特点

• 有约束的 微服务具有范围有限的单一职责集。微服务遵循UNIX的理念，即应用程序是服务的集合，每个服务只做一件事，并只做好一件事。
• 松耦合的 基于微服务的应用程序是小型服务的集合，服务之间使用非专属调用协议（如HTTP和REST）通过非特定实现的接口彼此交互。与传统的应用程序架构相比，只要微服务的接口没有改变，微服务的所有者可以更加自由地对微服务进行修改。
• 抽象的 微服务完全拥有自己的数据结构和数据源。微服务所拥有的数据只能由该微服务修改，可以通过该微服务数据库的访问控制实现，仅允许该微服务访问。
• 独立的 每个微服务可以独立于应用程序中其他的微服务进行编译和部署。这与依赖更重的单体应用程序相比，对变化进行隔离和测试更容易。

这些特点对于基于云的开发很重要。

1.2 基于云的应用程序的特点

• 拥有庞大而多样化的用户群 不同的用户需要不同的功能，用户不想在使用这些功能前等待漫长的应用程序发布周期。微服务允许功能快速交付，因为一个微服务的范围很小，而且是通过一个定义明确的接口对其进行访问。
• 极高的运行时间要求 由于微服务的分散性，使用微服务架构可以更容易地将故障和问题隔离到应用程序的特定模块中，而不会使整个应用程序崩溃。这可以减少应用程序的整体宕机时间，并使其对问题更有抵御能力。
• 不均匀的容量需求 一个基于云的应用程序，在不同时间和条件下，各组件的负载不同且在不断发生变化。由于使用微服务架构的应用程序被分解为可以彼此独立部署的小组件，所以可以更容易将重点放在正处于高负载的组件上，并将这些组件在云中的多个服务器上进行水平伸缩。

构建一个成功的微服务架构，需要结合架构师、软件开发人员、DevOps工程师三个关键角色的视角。

• 架构师的工作是看到大局，了解应用程序如何分解为单个微服务，以及微服务如何交互，以达到交付解决方案的目的。
• 软件开发人员编写代码，并详细了解如何将编程语言和开发框架用于交付微服务。
• DevOps工程师需要为所有生产环境和非生产环境提供最优的服务部署和管理方案，保障每个环境中的一致性和可重复性。

2 设计微服务架构

2.1 分解业务问题

分离业务领域是一门艺术，并不是非黑即白。可以使用以下指导方针将业务问题识别和分解为备选的微服务。

• 描述业务问题，并关注用来描述问题的名词。在描述问题时，反复使用的同一名词通常意味着他们是核心业务领域并且适合创建微服务。
• 注意动词。动词突出了动作，通常代表问题域的自然轮廓。
• 寻找数据内聚。将业务问题分解成离散的部分时，要寻找彼此高度相关的数据。微服务应完全拥有自己的数据。

根据上述指导方针，可以得到一个简化数据模型。

2.2 建立微服务粒度

2.2.1 划分微服务粒度的思想

构建微服务架构时，粒度的问题很重要，可以采用以下思想来确定正确的解决方案。

• 开始的时候可以让微服务涉及的范围更广一些，然后将其重构到更小的微服务。在开始的时候，容易出现的一个极端情况是将所有的事情变成微服务，但是将问题域分解为过小的微服务通常会导致过早的复杂性，因为微服务变成了细粒度的数据服务。
• 重点关注服务如何相互交互。这有助于建立问题域的粗粒度接口，从粗粒度重构到细粒度是比较容易的。
• 随着对问题域的理解不断增长，服务的职责将随着时间的推移而改变。通常，当需要新的应用功能时，最初的微服务可能会发展为多个微服务，原始的微服务则可以充当这些新服务的编排层，负责将其他部分的功能封装起来。

2.2.2 微服务的坏味道

如果微服务过于粗粒度，可能会看到以下现象。

• 微服务承担过多的职责。服务中业务逻辑的一般流程很复杂，并且似乎正在执行一组过于多样化的业务规则。
• 微服务正在跨大量表来管理数据。
• 测试用例太多。随着时间的推移，服务的规模和职责会增长，到了最后如果需要数百测试用例，那就可能需要重构。

如果微服务过于细粒度，可能会看到以下现象。

• 问题域的一部分微服务像兔子一样繁殖。如果一切都成为微服务，完成一项工作所需的微服务数量会快速增长，将这些微服务的业务逻辑组合起来会变得复杂和困难，
• 微服务彼此间严重相互依赖。在问题域的某一部分中，微服务相互回调才能完成单个请求。
• 微服务成为简单CRUD服务的集合。微服务是业务逻辑的表达，而不是数据源的抽象层。如果微服务只有CRUD相关逻辑，那可能被划分得太细粒度了。

2.3 定义服务接口

一般来说，可以使用以下指导方针思考微服务接口设计。

• 拥抱REST的理念。REST对服务的处理方式是将HTTP作为服务的调用协议并使用标准HTTP动词，围绕这些HTTP动词对基本行为进行建模。
• 使用URI来传达意图。用作服务端点的URI应描述问题域的不同资源，并为问题域内资源的关系提供一种基本机制。
• 请求和响应使用JSON。JSON是一个非常轻量级的数据序列化协议，并且比XML更容易使用。
• 使用HTTP状态码来传达结果。

所有这些指导方针都是为了使微服务接口易于理解和使用。如果微服务不容易使用，开发者就会另辟蹊径，破坏架构的意图。

3 何时不应该使用微服务

主要有以下几点考量因素

3.1 构建分布式系统的复杂性

因为微服务的分布式和细粒度，会在应用程序中引入一定的复杂性，但单体应用就不会。微服务架构需要高度的运维成熟度，除非愿意投入分布式应用程序所需的自动化和运维工作（监控、伸缩等），否则不要考虑使用微服务。

3.2 虚拟服务器/容器散乱

微服务最常用的部署模式之一就是在一个服务器上部署一个微服务实例，在一个基于微服务的大型应用程序中，最终可能需要大量的服务器或容器，这些服务器和容器需要单独搭建和维护，即使在云上运行这些微服务的成本较低，但管理和监控这些服务器的复杂性也是巨大的。必须对微服务的灵活性与运行大量服务器的成本进行权衡。

3.3 应用程序的类型

微服务是为了提高可复用性，并且对构建需要高度弹性和可伸缩的大型应用程序很有用，但如果只是用于构建一个小型的应用程序则不值得。

3.4 数据事务和一致性

开始时，需要考虑微服务的数据使用模式以及微服务消费者如何使用它们。如果应用程序需要跨多个数据源进行复杂的数据聚合或转换，那么微服务的分布式性质会让数据事务和一致性变得很困难。这样的微服务容易承担太多职责，也更容易遇到性能问题。
在微服务间执行事务没有标准，如果需要事务管理，就需要自己构建逻辑。另外，微服务间可以通过消息进行通信，但这会在数据更新中引入延迟，应用程序需要处理最终的一致性。