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.
Its core parts include:
1. Remote communication: Provides abstract encapsulation of various long-connection-based NIO frameworks, including various threading models, serialization, and information exchange methods in the "request-response" mode.
2. Cluster fault tolerance: Provides transparent remote procedure calls based on interface methods, including multi-protocol support, and cluster support such as soft load balancing, failure tolerance, address routing, and dynamic configuration.
3. Automatic discovery: Based on the registry directory service, the service consumer can dynamically find the service provider, making the address transparent, so that the service provider can smoothly increase or decrease the machine.
What can Dubbo do?
1. Transparent remote method call, just like calling a local method to call a remote method, just simple configuration, without any API intrusion.
2. Soft load balancing and fault tolerance mechanism can replace hardware load balancers such as F5 in the intranet, reducing costs and reducing single points.
3. The service is automatically registered and discovered, and the address of the service provider is no longer required. The registration center queries the IP address of the service provider based on the interface name, and can smoothly add or delete service providers.
Knowledge points involved in Dubbo:
1. Service registration:
For the service provider, it needs to publish services, and due to the complexity of the application system, the number and types of services are also expanding; for the service consumer, it is most concerned about how to obtain the services it needs, and faces complex applications. system that needs to manage a large number of service calls. Moreover, for service providers and service consumers, they may also have both roles, that is, they need to provide services and consume services.
Through unified management of services, the process and management of service publishing/use by internal applications can be effectively optimized. The service registry can complete the external unification of services through specific protocols. The registration center provided by Dubbo has the following types to choose from:
a, Multicast registry b, Zookeeper registry c, Redis registry d, Simple registry
2, Remote communication and information exchange
Long-distance communication needs to specify the protocol agreed upon by both parties. On the basis of ensuring that both parties understand the semantics of the protocol, efficient and stable message transmission must also be ensured. Dubbo inherits the current mainstream network communication framework, mainly including the following:
a:Mina b:Netty c:Grizzly
3,Dubbo支持多种协议
Dubbo协议
Hessian协议
HTTP协议
RMI协议
WebService协议
Thrift协议
Memcached协议
Redis协议
A,最底部的为dubbo服务的集群（服务者）,即对外界暴露服务，dubbo本身就
是支持集群模式，而且支持多种通信协议(dubbo,rmi,http...)。主要部署核心的业务代码。
B,右边的注册中心，dubbo提供了也是提供了多种注册中心， zookeeper注册中心是其中一
种同样无单点故障问题，dubbo服务依赖于注册中心，在dubbo服务启动时，回向注册中心
去进行一个服务的注册（发布服务）。对服务进行管理。
C,接下来看tomcat集群,主流的tomcat集群搭配(nginx+tomcat+redis/memcache)都是非常
的简单的，所有控制器都放到其中，控制器中依赖的服
务实现是来之后端dubbo集群的，而dubbo服务是注册到zookeeper上的，只需要连上注册
中心就获取到了我们所需要的服务，并且进行调用。主要是对控制器层做一个集群，提高
可用性和性能。
D,tomcat左下角是一个NOSQL集群，主要是处理一个session的共享/分布式缓存。
E,最上层是nginx的集群主要是把静态页面全都放到nginx中即可，注意，如果使用restful风
格，并且使用JS MVC框架的话！完全不需要把页面部署到tomcat中，让tomcat只跑控制代
码即可。restful架构的话页面时全静态，数据全都走json的方式即可。
F,上诉扩展瓶颈在nginx上，解决的方式就算使用在nginx之前套LVS吧，或者硬件做一个负载。
