微服务架构的前世此生（六）：微服务架构带来的问题

上次讲了微服务的前世此生（五）：CAP 原则与 BASE 理论，此次咱们再说微服务架构的前世此生（六）：微服务架构带来的问题。

1、客户端如何访问服务？

传统的开发方式，全部的服务都是本地的，客户端能够直接调用，如今按功能拆分红独立的服务，客户端如何访问？

后台有 N 个服务，前台就须要管理 N 个服务，一个服务下线/更新/升级，前台就要从新部署，这明显不符合咱们拆分的理念，另外，N 个服务的调用也是一个不小的网络开销。还有通常微服务在系统内部，一般是无状态的，用户登陆信息和权限管理最好有一个统一的地方维护管理（OAuth2）。

因此，通常在后台 N 个服务和客户端之间通常会一个代理（API Gateway），做用以下：

- 提供统一服务入口，聚合接口使得服务对调用者透明，客户端与后端的耦合度下降
- 聚合后台服务，节省流量，提升性能，提高用户体验
- 提供安全、流控、过滤、缓存、计费、监控等 API 管理功能

2、服务之间如何通讯？

由于服务都是独立部署的，因此通讯也就成了问题，不过好在业界已经有不少成熟的解决方案，好比：

**同步通讯：**

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

**异步通讯：**

- RabbitMQ，Kafka

3、这么多服务如何查找？

在微服务架构中，为了高可用，广泛采用集群方式构建服务。一个服务可能随时下线，也可能应对临时访问压力增长新的服务节点。

服务之间如何相互感知？服务如何管理？这就是服务发现的问题了。基本都是经过相似 ZooKeeper 等相似技术作服务注册信息的分布式管理。当服务上线时，服务提供者将本身的服务信息注册到 ZooKeeper（或相似框架），并经过心跳维持长连接，实时更新连接信息。服务调用者经过 ZooKeeper 寻址，找到一个服务，还能够将服务信息缓存在本地以提升性能。当服务下线时，ZooKeeper 会发通知给服务客户端。

 

4、服务挂了怎么办？

在微服务架构中，一个请求须要调用多个服务是很是常见的。如客户端访问 A 服务，而 A 服务须要调用 B 服务，B 服务须要调用 C 服务，因为网络缘由或者自身的缘由，若是 B 服务或者 C 服务不能及时响应，A 服务将处于阻塞状态，直到 B 服务 C 服务响应。此时如有大量的请求涌入，容器的线程资源会被消耗完毕，致使服务瘫痪。服务与服务之间的依赖性，故障会传播，形成连锁反应，会对整个微服务系统形成灾难性的严重后果，这就是服务故障的“雪崩”效应。

雪崩是系统中的蝴蝶效应致使，其发生的缘由多种多样，从源头咱们没法彻底杜绝雪崩的发生，可是雪崩的根本缘由来源于服务之间的强依赖，因此咱们能够提早评估作好服务容错。解决方案大概能够分为如下几种：

- 请求缓存：支持将一个请求与返回结果作缓存处理；
- 请求合并：将相同的请求进行合并而后调用批处理接口；
- 请求限流：当请求过多时，可能会拖垮整个网站，一般会采起限流措施，下降机器的负载；
- 服务隔离：限制调用分布式服务的资源，某一个调用的服务出现问题不会影响其余服务调用；
- 服务熔断：牺牲局部服务，保全总体系统稳定性的措施；
- 服务降级：服务熔断之后，客户端调用本身本地方法返回缺省值。

下一篇讲给你们带来微服务架构生态体系，请关注。若是您想要学习视频，请点击获取java微服务架构视频教程。