# 10 微服务之所见

## 单体地狱

一旦应用程序成为了一个庞大、复杂的单体，敏捷开发和交付的任何一次尝试都将原地徘徊。一个主要问题是应用程序实在非常复杂。对于任何一个开发人员来说显得过于庞大。最终，正确修复 bug 和实现新功能变得非常困难而耗时。

* 应用程序越大，启动时间越长。
* 复杂的单体应用本身就是持续部署的障碍。
* 当不同模块存在资源需求冲突时，单体应用可能难以扩展。
* 可靠性不足，任何模块的一个 bug，可能会拖垮整个进程，影响到整个应用的可用性。
* 单体应用使得采用新框架和语言变得非常困难。

## 微服务概述

微服务架构是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

### 微服务的优点

* 它解决了复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务。
* 这种架构使得每个服务都可以由一个团队独立专注开发。
* 微服务架构模式可以实现每个微服务独立部署。
* 微服务架构模式使得每个服务能够独立扩展。

### 微服务的缺点

* 微服务是一个分布式系统，其使得整体变得复杂。
* 微服务的另一个挑战是分区数据库架构。
* 测试微服务应用程序也很复杂。
* 微服务架构模式的另一个主要挑战是实现了跨越多服务变更。
* 部署基于微服务的应用程序也是相当复杂的。
* 每个服务都有多个运行时实例。还有更多的移动部件需要配置、部署、扩展和监控。

### 微服务特征

* 一系列的独立的服务共同组成系统
* 单独部署，跑在自己的进程中
* 每个服务为独立的业务开发
* 分布式管理
* 非常强调隔离性

## 微服务的实践

要实际的应用微服务，需要解决以下问题：

* 客户端如何访问这些服务
* 每个服务之间如何通信
* 如此多的服务，如何实现？
* 备份方案，应急处理机制

### 客户端如何访问这些服务

一般在后台 N 个服务和 UI 之间一般会一个代理或者叫 `API Gateway`，它的作用包括：

* 提供统一服务入口，让微服务对前台透明
* 聚合后台的服务，节省流量，提升性能
* 提供安全，过滤，流控等 API 管理功能

`API Gateway` 最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除它们之间的耦合，不过 `API Gateway` 也有可能成为单点故障点或者性能的瓶颈。

![API Gateway](https://3391885248-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M3u58XVueZWq507CWAj%2Fuploads%2Fgit-blob-b9f23b11b3379247b2a3f25cb61bc2209db2f80c%2FAPI_Gateway.png?alt=media)

### 服务之间如何通信

所有的微服务都是独立的 Java 进程跑在独立的虚拟机上，所以服务间的通信就是 IPC（Inter Process Communication），已经有很多成熟的方案。现在基本最通用的有**同步调用**和**异步消息调用**两种方式。

#### 同步调用

* REST（JAX-RS，Spring Boot）
* RPC（Thrift, Dubbo）

同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。一般 REST 基于 HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了 HTTP 的 SDK 就能调用，所以相对使用的广一些。RPC 传输协议更高效，安全更可控，如果有统一个的开发规范和统一的服务框架时，开发效率优势更明显些。

#### 异步消息调用

* Kafka
* Notify
* MessageQueue

异步消息的方式在分布式系统中有特别广泛的应用，它既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，自己处理自己的业务，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据**最终一致性**；还有就是后台服务一般要实现**幂等性**，因为消息送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的**Broker**。

![broker](https://3391885248-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M3u58XVueZWq507CWAj%2Fuploads%2Fgit-blob-173061bf17bdd0a0e0527005f52993d3318864fb%2Fbroker.png?alt=media)

### 服务发现

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？

这涉及到服务发现。一般有两类做法，也各有优缺点：

* 基于客户端的服务注册与发现
* 基于服务端的服务注册与发现

服务发现基本都是通过 Zookeeper 等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到 ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过 ZK 寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK 会发通知给服务客户端。

#### 基于客户端的服务注册与发现

优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如 Dubbo。

![基于客户端的服务注册与发现](https://3391885248-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M3u58XVueZWq507CWAj%2Fuploads%2Fgit-blob-afd315c58a38ab0e1f25045e309b38731c803ab5%2F%E5%9F%BA%E4%BA%8E%E5%AE%A2%E6%88%B7%E7%AB%AF%E7%9A%84%E6%9C%8D%E5%8A%A1%E6%B3%A8%E5%86%8C%E4%B8%8E%E5%8F%91%E7%8E%B0.png?alt=media)

#### 基于服务端的服务注册与发现

优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。

![基于服务端的服务注册与发现](https://3391885248-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-M3u58XVueZWq507CWAj%2Fuploads%2Fgit-blob-613b49a93f682e944b297d66c4d75d6f58c6c2f0%2F%E5%9F%BA%E4%BA%8E%E6%9C%8D%E5%8A%A1%E7%AB%AF%E7%9A%84%E6%9C%8D%E5%8A%A1%E6%B3%A8%E5%86%8C%E4%B8%8E%E5%8F%91%E7%8E%B0.png?alt=media)

#### 备份方案

分布式最大的特性就是网络是不可靠的，通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。所以当系统是由一系列的服务调用链组成的时候，必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：

* 重试机制
* 限流
* 熔断机制
* 负载均衡
* 降级（本地缓存）

参考文章：\
[再谈微服务](https://www.funtl.com/zh/micro-service-intro/)