微服务架构的理解及使用

微服务架构的理解

定义：将功能分解成一系列服务的一种架构模式。

着重点：相对于应用系统的功能性需求，更着重于应用系统的扩展性、灵活性，还有性能、运维、安全、测试、监控等非功能性需求。

核心思想：分而治之，将一个应用拆分成多个松耦合的服务，这些服务之间通过某种协议（REST、RPC等）进行互相协作，其中一个关键点就是各服务之间的松耦合，各服务之间通过一种“标准”的协议进行沟通，不需要理解对方服务的实现逻辑、实现方式，只要在对方不影响自己所提供的服务功能即可。

微服务中的服务：服务是一个可以独立运行、提供范围有限的功能（可以是业务功能，也有可能是非业务功能）的组件（微服务是可以单独部署运行的）。

优点：

• 松耦合：服务提供者和服务消费者互不影响。
• 抽象：当前微服务对自己所拥有的数据有绝对控制权，其他微服务只有通过该服务才能够访问此数据。
• 独立：每个微服务都可以在不影响其他微服务的情况下进行编译、打包和部署。
• 应对用户需求的多样性：不同的微服务承担不同的职责，快速部署上线能力可以让用户需求尽早实现。
• 更高可用性和弹性：微服务架构可以认为是一个去中心化的应用，每一个微服务都可以随时上线或下线。

缺点：

• 可用性降低：微服务之间都是通过远程调用进行协作的，远程调用必然是不稳定的。
• 处理分布式事务较棘手：当一个请求的业务涉及多个微服务时，保障数据的一致性就成为一个棘手的问题。
• 全能对象（God Classes）阻止业务拆分：几乎涉及了每个服务的对象，难以拆分。如电商系统的订单对象。
• 学习难度曲线加大：需要开发人员学习掌握一系列的微服务开发技术，加大了进入门槛。
• 组织架构变更：虽然对于单独一个微服务的部署简化了，但是整个应用部署的复杂度却提升了，需要涉及服务编排和服务治理等一系列处理，可能还需要协调不同的团队，以及在人事组织上进行调整来适应这种变化。

微服务架构的设计

微服务架构的设计一定是与时俱进的，因此我们也不可能在第一次设计时就设计出一个完美的架构体系

微服务架构如何设计呢？简单可概括为三步：

1. 把应用中关键的需求定义出来；
2. 识别出采用微服务架构时应用中所包含的所有服务；
3. 规划出各服务之间的协作关系。

注意：在服务拆分和服务协作规划时，一定要专注于业务，专注于业务，专注于业务；

当识别出应用的每一个微服务后，我们就需要考虑这些微服务之间如何进行协作。定义各个微服务之间协作关系最有效的方式就是根据每一个业务进行分析。有些业务场景可能只需要某一个服务就可以完成，有些业务场景则可能需要两个或多个服务才可以。这些协作可能是实时同步的，也可能是异步执行，我们可以根据这些具体需求来确定使用何种方式进行交互（是使用REST、RPC，还是消息）。此外，还有一个需要我们第一时间去考虑的问题就是用户的服务请求最初是由哪个服务承担的。

微服务粒度

那么如何衡量我们所设计的微服务粒度是否合适呢？

粗粒度的微服务的两种表现：

1. 当前微服务承担了太多的职责，在服务中塞了过多的业务逻辑和业务规则，而且业务流程也非常复杂，难以理解（常常会有感觉好像还是在开发单体系统一样）。
2. 当前微服务拥有众多数据的管理权限。对于一个粒度合适的微服务来说，其所管辖的数据也是有限的。当此微服务所管辖的数据众多，并且这些数据之间也没有合适的业务关联，那么显然该微服务粒度太粗了。

细粒度的微服务的两种表现：

1. 每一个微服务几乎都需要和其他的微服务进行沟通，每个微服务只承担其中很少量的业务处理，造成了一个外部请求需要经过太多的微服务才能够完成处理。
2. 当想单拎出一个服务时，发现几乎不可能，因为每一个微服务都依赖于其他微服务，同时又被其他微服务所依赖。

注意：在最初构建粗颗粒度的服务要优于过细的微服务，因为粗粒度的微服务会随着系统升级而逐渐细化形成粒度合适的微服务，而过细的微服务在构建和管理上非常复杂，也难以重构、合并成合适的大小。

微服务拆分原则

1. 单一职责原则：一个微服务承担太多职责的话，也会导致微服务业务之间的耦合，将微服务保持足够小，仅拥有一个业务职责，保持微服务的业务单一性，从而提升应用的稳定性。
2. 共同封闭原则：当修改某一项业务时，只需要在一个微服务中单独修改。一方面可以减少微服务的数量，另外一方面当在不同团队协作开发的场景中，减少了不同微服务开发团队之间沟通成本。

微服务自治原则

微服务的运行和维护自治：

团队越大，那么沟通与协助成本就会越高。所以你的微服务你负责——“你构建，你运行”。

微服务的业务和数据自治：

每个微服务拥有其业务领域对象下的数据，只有该微服务可以对这些数据进行操作（包含读取与更改），而其他微服务只有通过该服务才能访问到这些数据，不能直接通过数据库进行沟通。

微服务交互原则

• 使用REST协议：建议使用HTTP作为服务的调用协议，并在服务处理上使用HTTP标准动词（GET、PUT、POST和DELETE）
• 使用URI表达：服务端点的URI能够清晰表达出所要解决的问题、提供的方法、相应资源信息及资源之间的关联关系。
• 使用JSON数据格式：JSON是轻量级数据格式协议，及自带序列化和反序列化机制，并且对于前端开发来说非常容易使用与整合。
• 使用HTTP标准状态码：HTTP协议本身具有非常丰富的状态码，并且通俗易懂。

微服务架构迁移

从单体架构应用迁移到微服务架构，有一个很重要的指导思想就是不要大规模进行重构，而是一小步一小步来。

不应使用微服务架构的情形

当我们在开发时遇到下属情形时应避免使用微服务架构：

• 构建分布式架构非常吃力时

  构建微服务架构的同时也就把更为复杂的服务编排、服务治理及服务运维等引入到你的组织架构中，这种与构建单体架构的复杂度不可同日而语，微服务架构的开发还需要更高级的服务运维技术支持。

• 服务器蔓延时

  服务器和运维是一笔不小的开销。

• 采用小型应用、快速产品原型时

  微服务架构的诞生是为了解决可复用，并且需要快速扩展的大型应用的问题。

• 对数据事务的一致性有一定要求时

  分布式事务管理始终是分布式架构开发的头等难题，可能会成为系统应用的一个瓶颈。