The project address

https://github.com/yinjihuan/kitty-cloud[1]

preface

After Kitty Cloud opened its open source, my friend asked me about issues on GitHub, asking why the project should integrate Feign and Dubbo frameworks to call the service. Today we’ll talk about this and how to switch between the two invocation methods in Kitty Cloud.

Why support both protocols?

As for supporting both protocols, this is an open source project, mainly to give users more choices. Of course, I didn’t develop the framework itself, I just used it.

One protocol is more unified, and it is not impossible to mix the two protocols, depending on the actual needs. For example, you have an internal ID distribution service with high call volume, which has extreme performance requirements. Then you can use Rpc instead of Http in this scenario. Other normal use of Http protocol is ok, special scenarios use Rpc protocol, complementary.

The best thing about using Http is that it’s easy to transfer content as text and debug everything. For example, if I want to test a service’s interface separately, I can call the Http interface directly on PostMan, or use Swagger.

If it’s Dubbo’s Rpc, I might need to Telnet it.

There is also the gateway layer forwarding, if Http protocol, directly forward over. If the Rpc protocol is used, the internal gateway needs special processing. Of course, there are other gateways that support Rpc. If we have two protocols, the gateway side can directly Http forward, and the internal service before the use of the protocol for users to decide.

In fact, after Spring Cloud gradually entered the enterprise, many people will encounter a problem that the old services are used to communicate with Dubbo. If Spring Cloud technology stack is transferred, it is bound to remove Dubbo.

It’s okay to refactor it if it’s small, but for large-scale applications, there are a lot of services. You’re unlikely to get fat in one bite. The refactoring will be done one by one, meaning that the old services will remain Dubbo until the refactoring is complete, but some services have become Spring Cloud architectures. At this time compatibility is an urgent need to solve the problem.

The emergence of Spring Cloud Alibaba provides a perfect solution to this problem, supporting both protocols and slowly transitioning.

For example

Here is an example:

In the following figure, there are two services. Both services start with Rpc protocol. Service A invokes service B through Rpc.


After reconstructing service B into Http, service A needs to invoke service B using Http.


Renovation Plan 1

In terms of implementation requirements, it is very simple to give the code called in service A and call it with Feign or RestTemplate. However, this means that I have reconstructed service B, and also need to change the code of service A. It is likely that not only service A is calling service B, maybe there are dozens of services, so I have to change the way of calling dozens of services.

It is obvious that this plan is not feasible. If you give a plan like this, your boss gives you a look, experience yourself…

Renovation Plan 2

Since option 1 was rejected, the requirement is obvious: you can reconstitute the Spring Cloud stack, but you can’t influence the users.

In order not to affect the user, it feels like the only way to start is to call Dubbo. If the target service is the old Rpc protocol, then the call method stays the same.

If the target service becomes a new Http protocol, it will need to be invoked in a new way so that the underlying compatibility will not affect the user.


Renovation Plan 3

The third option, which is the one we have now, is to make service B support dual protocols. With dual protocols, all callers need not change, because Rpc is still supported. If a new service is available, it can use Http to call the interface of the B service.


How to support both protocols?

The core of supporting the two protocols lies in Dubbo Spring Cloud. As the core component of Spring Cloud Alibaba, Dubbo Spring Cloud basically ADAPTS to Spring Cloud technology stack.

The interface is still isolated and placed in the API module, and FeignClient is defined on the interface.


Expose both protocols in the implementation class, with Dubbo’s @Service and @RestController annotations.


The user only needs to inject the interface, or @AutoWired for injection if they want to use Feign.

@Autowired
private UserRemoteService userRemoteService;
Copy the code

If you want to use Dubbo for the call, use @reference for injection.

@Reference(version = DubboConstant.VERSION_V100, group = DubboConstant.DEFAULT_GROUP, check = false)
private UserRemoteService userRemoteService;
Copy the code

Another important configuration is that Dubbo’s registry needs to be mounted to the Spring Cloud registry.

dubbo.registry.address=spring-cloud://localhost
Copy the code

Senior play

Currently, although dual-protocol is supported, the right of use is handed over to users. You can use whatever protocol you want to use to make the call, it’s hardcoded.

For more flexibility, we can extend at the bottom of Dubbo or Feign. For example, if the extension is based on Feign, the calls are made in Feign mode, and there is no need to inject the client with @Reference. We can configure which protocol calls to use by integrating the configuration center. At the bottom of Feign, you configure content to decide whether or not to make Rpc calls. If you want to go Rpc can use Dubbo’s generalization call.


About the author: Yin Jihuan, a simple technology lover, the author of Spring Cloud Micro-service – Full stack Technology and Case Analysis, Spring Cloud Micro-service Introduction combat and Progress, the founder of the public account Monkey World. Personal wechat jihuan900, welcome to hook up.

The resources

[1]

kitty-cloud: https://github.com/yinjihuan/kitty-cloud