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做为统计
