上次讲了微服务的前世今生（五）：CAP 原则与 BASE 理论，这次我们再说微服务架构的前世今生（六）：微服务架构带来的问题。
一、客户端如何访问服务？
传统的开发方式，所有的服务都是本地的，客户端可以直接调用，现在按功能拆分成独立的服务，客户端如何访问？
后台有 N 个服务，前台就需要管理 N 个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不符合我们拆分的理念，另外，N 个服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth2）。
所以，一般在后台 N 个服务和客户端之间一般会一个代理（API Gateway），作用如下：
- 提供统一服务入口，聚合接口使得服务对调用者透明，客户端与后端的耦合度降低
- 聚合后台服务，节省流量，提高性能，提升用户体验
- 提供安全、流控、过滤、缓存、计费、监控等 API 管理功能
二、服务之间如何通信？
因为服务都是独立部署的，所以通信也就成了问题，不过好在业界已经有很多成熟的解决方案，比如：
**同步通信：**
- REST（JAX-RS，Spring Boot）
- RPC（Dubbo，Thrift）
**异步通信：**
- RabbitMQ，Kafka
三、这么多服务如何查找？
在微服务架构中，为了高可用，普遍采用集群方式构建服务。一个服务可能随时下线，也可能应对临时访问压力增加新的服务节点。
服务之间如何相互感知？服务如何管理？这就是服务发现的问题了。基本都是通过类似 ZooKeeper 等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到 ZooKeeper（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过 ZooKeeper 寻址，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZooKeeper 会发通知给服务客户端。
四、服务挂了怎么办？
在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问 A 服务，而 A 服务需要调用 B 服务，B 服务需要调用 C 服务，由于网络原因或者自身的原因，如果 B 服务或者 C 服务不能及时响应，A 服务将处于阻塞状态，直到 B 服务 C 服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
雪崩是系统中的蝴蝶效应导致，其发生的原因多种多样，从源头我们无法完全杜绝雪崩的发生，但是雪崩的根本原因来源于服务之间的强依赖，所以我们可以提前评估做好服务容错。解决方案大概可以分为以下几种：
- 请求缓存：支持将一个请求与返回结果做缓存处理；
- 请求合并：将相同的请求进行合并然后调用批处理接口；
- 请求限流：当请求过多时，可能会拖垮整个网站，通常会采取限流措施，降低机器的负载；
- 服务隔离：限制调用分布式服务的资源，某一个调用的服务出现问题不会影响其他服务调用；
- 服务熔断：牺牲局部服务，保全整体系统稳定性的措施；
- 服务降级：服务熔断以后，客户端调用自己本地方法返回缺省值。
下一篇讲给大家带来微服务架构生态体系，请关注。如果您想要学习视频，请点击获取java微服务架构视频教程。