Version：1.1.0.B036一提供方Api定义如下Interface RpcApi{void sayHi();void sayHi(String content);}提供方实现类型如下RpcApi implements RpcApi{void sayHi(){//do something}；void sayHi(String content){//do something};}消费方调用如下CustomerRpcServie{@RpcReference(XXXX)RpcApi rpcApi；rpcApi.sayHi();}提供方RpcApi定义如上时，调用时会报找不到sayHi method，因为加了nickname之后RPCAPI Path变了二将提供方RpcApi修改为如下方式，增加@ApiOperation注解Interface RpcApi{@ApiOperation(nickname="sayHiNoParam")void sayHi();@ApiOperation(nickname="sayHiWithParam")void sayHi(String content);}提供方RpcApi定义如上时，消费方调用时会报找不到sayHi()这个无参的接口，debug发现在寻址时Map<String, SwaggerConsumerOperation> opMap = new HashMap<>()；该数据中只有sayHi(String content)接口数据，因为这个opMap将method.getName()作为key请确认是Bug还是我使用方式的问题，谢谢！

在CSE框架下有没有类似serverlet拦截器、过滤器的框架或机制，如果有的话能够提供一个完整的使用样例？

我的SimpleServiceImpl中有一个属性，想通过spring iot 注入，该如何实现

本帖最后由 李白云 于 2018-2-5 10:44 编辑请问两种通信协议有性能测试方面的数据吗？

什么是RPC RPC即Remote Procedure Call(远程方法调用)，是Openstack中一种用来实现跨进程(或者跨机器)的通信机制。Openstack中同项目内(如nova, neutron, cinder...)各服务(service)及通过RPC实现彼此间通信。Openstack中还有另外两种跨进程的通信方式：数据库和Rest API。 Openstack中服务主要以进程的形式实现。也可以以线程的形式实现，但是Python中的线程是协作模型，无法发挥系统中多CPU(或多CPU核心)的能力。 RCP只定义了一个通信接口，其底层的实现可以各不相同。目前Openstack中的主要采用AMQP来实现。AMQP( Advanced Message Queuing Protocol)是一种基于队列的可靠消息服务协议，具体可参考http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol。作为一种通信协议，AMQP同样存在多个实现，如Apache Qpid, RabbitMQ等。 基本概念 • Exchange：根据 Routing key 转发消息到对应的 Message Queue 中 • Routing key：用于 Exchange 判断哪些消息需要发送对应的 Message Queue • Publisher：消息发送者，将消息发送的 Exchange 并指明 Routing Key，以便 Message Queue 可以正确的收到消息 • Consumer：消息接受者，从 Message Queue 获取消息 消息发布者 Publisher 将 Message 发送给 Exchange 并且说明 Routing Key。Exchange 负责根据 Message 的 Routing Key 进行路由，将 Message 正确地转发给相应的 Message Queue。监听在 Message Queue 上的 Consumer 将会从 Queue 中读取消息。 Routing Key 是 Exchange 转发信息的依据，因此每个消息都有一个 Routing Key 表明可以接受消息的目的地址，而每个 Message Queue 都可以通过将自己想要接收的 Routing Key 告诉 Exchange 进行 binding，这样 Exchange 就可以将消息正确地转发给相应的 Message Queue RPC的使用场景 Openstack中RPC的主要使用场景： 1、随机调用某server上的一个方法： Invoke Method on One of Multiple Servers 这个应该是Openstack中最常用的一种RPC调用，每个方法都会有多个server来提供，client调用时由底层机制选择一个server来处理这个调用请求。 像nova-scheduler, nova-conductor都可以以这种多部署方式提供服务。 这种场景通过AMQP的topic exchange实现。 所有server在binding中为binding key指定一个相同的topic， client在调用时使用这个topic既可实现。 2、调用某特定server上的一个方法： Invoke Method on a Specific Server 一般Openstack中的各种scheduler会以这种方式调用。通常scheduler都会先选定一个节点，然后调用该节点上的服务。 这种场景通过AMQP的topic exchange实现。 每个server在binding中为其binding key指定一个自己都有的topic， client在调用时使用这个topic既可实现。 3、调用所有server上的一个方法： Invoke Method on all of Multiple Servers 这种其实就是一个广播系统。就像开会议，台上的人讲话，台下的人都能听到。 Openstack中有些rpcapi.py的某些方法带有fanout=True参数，这些都是让所有server处理某个请求的情况。 例子： neutron中所有plugin都会有一个AgentNotifierApi，这个rpc是用来调用安装在compute上的L2 agent。因为存在多个L2 agent(每个compute上都会有)，所以要用广播模式。 这种场景通过AMQP的fanout exchange实现。 每个server在binding中将其队列绑定到一个fanout exchange， client在调用时指定exchange类型为fanout即可。server和client使用同一个exchange。