Dubbo is a distributed service framework dedicated to providing high-performance and transparent RPC remote service invocation solutions, as well as SOA service governance solutions.
Simply put, dubbo is a service framework. If there is no distributed demand, it is actually unnecessary. Only when it is distributed, there is a demand for a distributed service framework like dubbo, and it is essentially a service call. To put it bluntly, it is a distributed framework for remote service invocation (say goodbye to WSdl
in the Web Service mode, and register on dubbo in the way of server and consumer)
1. What scenarios is Dubbo suitable for?
When the website becomes larger, it is inevitable to split the application for service, in order to improve development efficiency, optimize performance, and save key competitive resources.
When there are more and more services, the URL address information of the services will explode, configuration management will become very difficult, and the single point pressure of the F5 hardware load balancer will also increase.
With further development, the dependencies between services become complicated and misunderstood, and it is not even clear which application should be started before which application, and architects cannot fully describe the architectural relationship of the application.
Then, the call volume of the service is increasing, and the capacity problem of the service is exposed. How many machines does this service need? When should the machine be added? Wait...
When you encounter these problems, you can use Dubbo to solve them.
2. Compared with Taobao HSF, what are the characteristics of Dubbo?
1. The deployment method of Dubbo is lighter than HSF . HSF requires the use of specified containers such as JBoss, and also needs to add sar package extensions to containers such as JBoss, which is more intrusive to the user's operating environment. If you want to run in Weblogic or Websphere On other containers, you need to expand the container to be compatible with HSF's ClassLoader loading, while Dubbo has no requirements and can run in any Java environment.
2. Dubbo is more scalable than HSF, and it is very convenient for secondary development . It is impossible for one framework to cover all requirements. Dubbo always maintains the concept of treating third parties equally, that is, all functions can be modified without modifying Dubbo's native code. Expansion in the periphery, including Dubbo's own built-in functions, is also implemented by extension, just like the third party. It is very difficult for HSF if you want to add functions or replace some parts of the implementation. For example, Alipay and Taobao use different The HSF branch of HSF, because the core code was changed when adding functions, had to copy a branch for independent development. Even if HSF is open source at this stage, it is difficult to reuse unless the architecture is rewritten.
3. HSF relies on many internal systems , such as configuration center, notification center, monitoring center, single sign-on, etc. If you want to open source, you need to do a lot of stripping work, and Dubbo has set aside extension points for the integration of each system, and All dependencies have been sorted out, and an alternative solution is provided for the open source community, which users can use directly.
4. Dubbo has more functions than HSF . In addition to ClassLoader isolation, Dubbo is basically a superset of HSF. Dubbo also supports more protocols and integration of more registries to adapt to more website architectures.