The way NettyClient calls remote service

  java, netty, spring


When using netty to develop rpc, one of the problems facing the client side is how the client can easily call remote services. Rmi in java gives a good example through proxy mode. Through proxy, calling remote service is as simple as calling local service for users. For published services, interfaces using java are exposed to users, who introduce the service interface and then configure the interface. Several specific calling methods are briefly described here.

Not using ioc

public void proxyDemo(){
        HelloService helloService = client.rpcProxy(HelloService.class, Pair.of(500L, TimeUnit.MILLISECONDS));
        System.out.println(helloService.say("proxy demo"));

This is the most direct way to use it. It returns the proxy class through jdk’s proxy and then calls it directly. However, if multiple invocations are involved in the general project, one proxy class for each new is wasteful, and the integration of ioc containers can be considered. The following are the calling methods using spring.

Java config mode

    public HelloService buildHelloService(RpcProxyFactory rpcProxyFactory){
        return rpcProxyFactory.proxyBean(HelloService.class,100/*timeout*/);

The advantage is that the service-api interface can be directly shared. the disadvantage is that java config is slightly less intuitive than xml, but it is better to adapt.

Xml mode

<bean id="helloService" class="com.codecraft.rpc.spring.SpringProxyFactoryBean">
        <property name="innerClassName">
        <property name="timeoutInMillis">

This is a slightly more complicated configuration, but it is acceptable. Please refer tonavi

Xml for custom schema

<dubbo:reference id="helloService" interface="com.codecraft.rpc.service.demo.HelloService" timeout="200"/>

According to dubbo’s method, customize schema.dubbo-config-springThis method is simple to use, but extending spring’s xsd is slightly more complicated.

Client redefines interface

Using spring’s scanner method, the client side writes the interface again to add comments, and then the client side scans the assembly and repeats the definition. It is not recommended. For details, please refer torpc-spring