1、怎么维护url的?
通过注册中心维护URL(zookeeper,redis)
2、单点压力比较大问题
F5一般用来做硬件的负载均衡。
可以用企业数据总线中的软负载均衡,部署多个相同服务的多个服务实例,让其中一个对外提供服务就可以了。
3、怎么管理服务之间的依赖关系
由企业数据总线自动的去整理服务之间的依赖关系。
dubbo是依赖zookeeper基础之上完成这些功能的,redis也是可以的。
4、如果服务器的调用的量越来越大,服务器的容量问题怎么去评判扩容的标准。
dubbo里面提供了一套完善的监控平台,可以监控服务调用量,并发量,相应时间。
Dubbo的核心内容:
1、远程通信(Dubbo也是一个RPC框架).
2、集群容错:调用某一个服务可能会是失败的,可能下面有相关的下游的服务
可能会导致级联失败的场景。
有点类似于微服务中的回退机制,只要在服务被访问的时候超时了或者重试的时候失败了,就可以认为这个服务挂掉了,会及时的告诉服务器。
3、服务注册与发现:
4、负载均衡:
dubbo的架构(2.6.2)
现在阿里的dubbo交给apache来管理了
官网:http://dubbo.apache.org/en-us/index.html
dubbo的架构图如下:
在上面的图中:Provider提供者,叫做服务提供者、Container:称之为容器、Registry:服务注册、Consumer:服务消费者、Monitor:监控中心 首先Provider是依赖于容器启动的,容器可以为jetty,tomca。一旦容器启动会将服务的提供者的信息会注册到服务中心里面去(注册的内容是ip地址+端口号),可以认为是zk 服务消费者将会订阅注册中心里面的数据。当Consumer初始化的时候就会去订阅Registry里的服务。Registry这个节点当有新的数据过来的时候,这时就会发送通知异步的向消费者发送一个通知,消费者就可以拿到对应的ip地址和端口号。然后直接通过rpc调用远程服务端的Provider提供的功能。不提供服务的实现,只提供服务的接口,这种方式叫做rpc。Consumer和Provider不在同一个机器上,它俩肯定会实现网络通信。最后所有的操作将会交给Monitor做为统计