Many springcloud and dubbo distinction in micro service architecture, the article, mainly emphasize the subset of dubbo just springcloud, just service governance tool, not a complete solution, but look at the both, feeling completely not compatible, concept is completely different,
Springboot development of typical application directory as follows:

Controller, the service interface, Serviceimpl implementation, dao level, such as
1, sprinbcloud is using HTTP calls the REST interface controller layer , just like the App or the front page to access a REST interface, just using the RestTemplate encapsulation simplifies the HTTP invocation code (httpClient writing too complicated); Sprinbcloud unable to invoke the Service interface, Feign way is in the consumer end and a special interface class, seems to be written in the Java API way calls, the actual controller is the same with the restTemplate call layer,
2, while Dubbo need to provide the interface class, is to call the Service layer interface , sharing their server Service interface into package, the client import can call like write native code, but the Dubbo unable to invoke the Controller, the Controller class without interface! The client can't way to Java API calls,

So what kind of better? Springcloud can be generalized in any language, because all the HTTP call json data, don't need according to the Java API to write, this way coupling is small, can with different language service invocation of third party applications; Dubbo, similar to local call writing, Java standard writing (in recent years has support for the node. Js and python language), and is more suitable for Java technology stack, is more suitable for homogeneous micro service components do not need to third party applications integration with other language situation, personal feeling, the meaning of the service interface, is to encapsulate business logic, controller and only in processing the request and returns, so the micro service call service more reasonable, after all, is the background calls, especially micro service all of our team, is a business application of dismantling, makes little sense to invoke the controller, in many cases the front-end different micro controller, can be called directly why the back-end call again, unless it is call a service of a third party,
Call a service of a third party, generally used for application integration relatively loose, according to the third party call directly with restTemplate line interface document, not like a decomposed into multiple micro coupling between service, is often difficult to request the third party applications use the same service registry, so I tend to use dubbo,

In my opinion, please discuss!
Here are a few questions:
1, the service application to invoke the controller or the service?
2, springcloud can invoke the service interface?
3, Dubbo can invoke the controller? How do you call?
4, it is necessary to use? So that both can call?

CodePudding user response:

Is a person view

1, the service application to invoke the controller or the service?

According to the business, if the system partition is more, then use controller, the front end through corresponding multiple routing background feel more appropriate ( but the service between the adjustable
Using need consider the serialization and deserialization of parameters, the parameters of the larger impact performance

If the business is much, but system partition, then use the service, just need to change the backend

2, springcloud can invoke the service interface?

I don't know, only use it to invoke the controller

3, Dubbo can invoke the controller? How do you call?

I don't know, it only changed the service

4, it is necessary to use? So that both can call?

If the system partition is more similar to multiple platforms, so many platform can use springcloud, internal calls using dubbo

CodePudding user response:

reference 1/f, big D, the moonlight reply:

view is

1, the service application to invoke the controller or the service?

According to the business, if the system partition is more, then use controller, the front end through corresponding multiple routing background feel more appropriate ( but the service between the adjustable
Using need consider the serialization and deserialization of parameters, the parameters of the larger impact performance

If the business is much, but system partition, then use the service, just need to change the backend

2, springcloud can invoke the service interface?

I don't know, only use it to invoke the controller

3, Dubbo can invoke the controller? How do you call?

I don't know, it only changed the service

4, it is necessary to use? So that both can call?

If the system partition is more similar to multiple platforms, so many platform can use springcloud, internal calls using dubbo

Usage from your practice is indeed different, invoke the controller and service respectively, 1 answer didn't see, front-end call direct request to the backend, micro service call should be between the back-end call,

CodePudding user response:

refer to the second floor berg369 response:

Quote: refer to 1st floor in the moonlight, big D response:

Is a person view

1, the service application to invoke the controller or the service?

According to the business, if the system partition is more, then use controller, the front end through corresponding multiple routing background feel more appropriate ( but the service between the adjustable
Using need consider the serialization and deserialization of parameters, the parameters of the larger impact performance

If the business is much, but system partition, then use the service, just need to change the backend

2, springcloud can invoke the service interface?

I don't know, only use it to invoke the controller

3, Dubbo can invoke the controller? How do you call?

I don't know, it only changed the service

4, it is necessary to use? So that both can call?

If the system partition is more similar to multiple platforms, so many platform can use springcloud, internal calls using dubbo

Usage from your practice is indeed different, invoke the controller and service respectively, 1 answer didn't see, front-end call direct request to the backend, micro service call should be between the back-end call,

Actually I mean

Scene need to call the service number for use dubbo, fewer with spring - cloud,

In view of the front end, different request call service,

In view of the background, a service receives a request, multiple services processing

Can put the development environment of the two frameworks are set up, each person's habits and the emphasis of the business is not the same,,,,

CodePudding user response:

Online can't see someone said springcloud unable to call the Service interface layer, or Dubbo unable to invoke the Controller interface of this statement, please be familiar with the master to solve it,

CodePudding user response:

1, the service application to invoke the controller or the service?
If you refer to micro service between micro service calls, so it must be called directly dubbo service
2, springcloud can invoke the service interface?
If you refer to provide interfaces to the front, you can call in the controller of dubbo service, front is certainly not RPC remote call,,
3, Dubbo can invoke the controller? How do you call?
Dubbo itself is a RPC service framework, why do you want to call the controller?
4, it is necessary to use? So that both can call?
First you need to clear one thing, the dubbo service applies to micro service between calls, second, the provider and consumer of dubbo points for consumer you to also can be encapsulated into the front controller to change, or you in other micro service business layer directly invoke dubbo service can also


Based on the above answer, don't know the building Lord did understand?