微服务架构要解决哪些问题？
客户端是如何访问这么多服务的？
我们都知道，微服务会有很多的服务，共同去组成一个完整的系统，而每个系统都部署的不同的服务器有不同的地址，而客户端不可能把所有的地址都记住，然后去访问它们。因此出现了 API 网关。
服务和服务之间是如何通信的？
除了客户端会调用服务外，服务和服务之间也会相互调用。比如订单系统调用库存系统。
同步通信：
HTTP（Apache Http Client）
RPC(Dubbo，只支持Java，Apache Thrift， gPRC)
异步通信：
消息队列（Kafka，RabbitMQ，RocketMQ等）
这么多服务，我们如何去管理它？
服务出现了这么多，肯定需要一个治理中心。于是出现了服务的注册和发现。
基于客户端的服务注册与发现
Zookeeper（为什么它是基于客户端的服务注册和发现？）
基于服务端的服务注册和发现
Netflix Eureka（为什么它是基于服务端的服务注册和发现？）
如果某个服务挂了，该怎么处理？
对于同一个功能的服务，我们会分出来好多服务来进行负载均衡和达到高可用。
如果某个服务挂了，可以采取以下方案。
重试机制
服务熔断
服务降级
服务限流
正文到此结束(点击广告是对作者最大的支持)
