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