RPC Communication (Dubbo)
Relevant source files
The following files were used as context for generating this wiki page:
- zheng-upms/zheng-upms-rpc-service/src/main/resources/META-INF/spring/applicationContext-dubbo-provider.xml
- zheng-upms/zheng-upms-server/src/main/resources/applicationContext-dubbo-consumer.xml
- zheng-cms/zheng-cms-rpc-service/src/main/resources/META-INF/spring/applicationContext-dubbo-provider.xml
- zheng-cms/zheng-cms-admin/src/main/resources/applicationContext-dubbo-consumer.xml
- zheng-upms/zheng-upms-rpc-api/pom.xml
- zheng-cms/zheng-cms-rpc-api/pom.xml
- zheng-upms/zheng-upms-rpc-service/pom.xml
- zheng-api/zheng-api-rpc-service/src/main/resources/META-INF/spring/applicationContext-dubbo-consumer.xml
The zheng project employs a microservices architecture, utilizing Apache Dubbo as the framework for Remote Procedure Call (RPC) communication between its various modules. This allows for a decoupled system where services, such as User Permission Management (zheng-upms) and Content Management (zheng-cms), can interact with each other over the network.
The core of this architecture relies on a service registry, Zookeeper, which allows service providers to register their available services and consumers to discover them dynamically. The configuration is managed through Spring XML files, defining providers, consumers, registry details, and communication protocols. This structure promotes separation of concerns, with distinct modules for service APIs (*-rpc-api), service implementations (*-rpc-service), and service consumers (e.g., -server, -admin, -web modules).
Architecture Overview
The RPC architecture follows a standard Dubbo pattern involving three key roles: Provider, Consumer, and Registry.
- Provider: An application that exposes its services. In
zheng, these are typically the*-rpc-servicemodules. - Consumer: An application that subscribes to and invokes remote services. Examples include
zheng-upms-serverandzheng-cms-admin. - Registry: A central server (Zookeeper) that providers register with and consumers query to find services.
The following diagram illustrates the high-level interaction between these components.
This diagram shows service providers registering with Zookeeper and consumers discovering them to make direct RPC calls.
Sources: zheng-upms/zheng-upms-rpc-service/src/main/resources/META-INF/spring/applicationContext-dubbo-provider.xml:13, zheng-upms/zheng-upms-server/src/main/resources/applicationContext-dubbo-consumer.xml:12
Module Structure
The project is organized into specific Maven modules to manage RPC dependencies and contracts effectively. This separation is crucial for maintaining a clean architecture.
*-rpc-api: These modules contain only the Java interfaces that define the service contracts. Consumers depend on these modules to get the API for remote calls.*-rpc-service: These modules contain the concrete implementations of the service interfaces defined in the*-rpc-apimodules. They also contain the Dubbo provider configuration to expose these implementations as services.
The diagram below shows the dependency relationship between the modules for the zheng-upms system.
This diagram illustrates that both the consumer (zheng-upms-server) and the provider (zheng-upms-rpc-service) depend on the API contract module (zheng-upms-rpc-api).
Sources: zheng-upms/zheng-upms-rpc-api/pom.xml:24-28, zheng-upms/zheng-upms-rpc-service/pom.xml:17-21
Service Provider Configuration
Service providers are configured in applicationContext-dubbo-provider.xml files within the *-rpc-service modules. These files define which services are exposed and how they are published.
Sources: zheng-upms/zheng-upms-rpc-service/src/main/resources/META-INF/spring/applicationContext-dubbo-provider.xml, zheng-cms/zheng-cms-rpc-service/src/main/resources/META-INF/spring/applicationContext-dubbo-provider.xml
Key Configuration Elements
| XML Tag | Attribute | Example Value | Description |
|---|---|---|---|
<dubbo:application> | name | zheng-upms-rpc-service | Sets the name of the current application, used for identification in the registry. |
<dubbo:registry> | address | zookeeper://zkserver:2181 | Specifies the address of the Zookeeper registry center. |
<dubbo:protocol> | name | dubbo | Defines the protocol to use for RPC. |
<dubbo:protocol> | port | 20881 | The port on which the service is exposed. Each provider module uses a different port (e.g., 20881, 20882). |
<dubbo:service> | interface | com.zheng.upms.rpc.api.UpmsApiService | The fully qualified name of the service interface being exposed. |
<dubbo:service> | ref | upmsApiService | A reference to the Spring bean that implements the service interface. |
<dubbo:service> | timeout | 10000 | Sets the timeout for the service call in milliseconds. |
Example Provider Configuration
The following snippet from the zheng-upms-rpc-service module shows how the UpmsApiService is exposed.
<!-- zheng-upms/zheng-upms-rpc-service/src/main/resources/META-INF/spring/applicationContext-dubbo-provider.xml -->
<dubbo:application name="zheng-upms-rpc-service"/>
<dubbo:registry address="zookeeper://zkserver:2181"/>
<dubbo:protocol name="dubbo" port="20881"/>
<!-- ... -->
<!-- 接口服务 -->
<bean id="upmsApiService" class="com.zheng.upms.rpc.service.impl.UpmsApiServiceImpl"/>
<dubbo:service interface="com.zheng.upms.rpc.api.UpmsApiService" ref="upmsApiService" timeout="10000"/>
Exposed Services
The following tables list some of the services exposed by the upms and cms provider modules.
zheng-upms-rpc-service (Port: 20881)
| Service Interface | Spring Bean Reference |
|---|---|
UpmsSystemService | upmsSystemService |
UpmsOrganizationService | upmsOrganizationService |
UpmsUserService | upmsUserService |
UpmsRoleService | upmsRoleService |
UpmsPermissionService | upmsPermissionService |
UpmsApiService | upmsApiService |
UpmsLogService | upmsLogService |
zheng-cms-rpc-service (Port: 20882)
| Service Interface | Spring Bean Reference |
|---|---|
CmsArticleService | cmsArticleServiceImpl |
CmsCategoryService | cmsCategoryServiceImpl |
CmsCommentService | cmsCommentServiceImpl |
CmsTagService | cmsTagServiceImpl |
CmsTopicService | cmsTopicImpl |
Service Consumer Configuration
Service consumers are configured in applicationContext-dubbo-consumer.xml files within modules that need to call remote services. These files define which remote services to subscribe to.
Sources: zheng-upms/zheng-upms-server/src/main/resources/applicationContext-dubbo-consumer.xml, zheng-cms/zheng-cms-admin/src/main/resources/applicationContext-dubbo-consumer.xml
Key Configuration Elements
| XML Tag | Attribute | Example Value | Description |
|---|---|---|---|
<dubbo:application> | name | zheng-upms-server | Sets the name of the consuming application. |
<dubbo:registry> | address | zookeeper://zkserver:2181 | Specifies the address of the Zookeeper registry. |
<dubbo:registry> | file | ./zheng-upms-server-dubbo.cache | A local file path for caching registry data, improving performance and fault tolerance. |
<dubbo:consumer> | check | false | If false, Dubbo will not throw an exception at startup if the provider is not available. |
<dubbo:reference> | id | upmsApiService | The bean ID for the remote service proxy, which can be injected into other Spring beans. |
<dubbo:reference> | interface | com.zheng.upms.rpc.api.UpmsApiService | The fully qualified name of the service interface to consume. |
<dubbo:reference> | mock | true | Enables service mocking for scenarios like service degradation or testing when the provider is unavailable. |
Example Consumer Configuration
The following snippet from zheng-cms-admin shows how it subscribes to both cms and upms services.
<!-- zheng-cms/zheng-cms-admin/src/main/resources/applicationContext-dubbo-consumer.xml -->
<dubbo:application name="zheng-cms-admin"/>
<dubbo:registry file="./zheng-cms-admin-dubbo.cache" address="zookeeper://zkserver:2181"/>
<!-- 订阅服务 -->
<dubbo:consumer check="false"/>
<!-- 文章 -->
<dubbo:reference id="cmsArticleService" interface="com.zheng.cms.rpc.api.CmsArticleService" mock="true"/>
<!-- ... more cms services -->
<!-- 接口服务 -->
<dubbo:reference id="upmsApiService" interface="com.zheng.upms.rpc.api.UpmsApiService" mock="true"/>
Sources: zheng-cms/zheng-cms-admin/src/main/resources/applicationContext-dubbo-consumer.xml:11-20, 38
RPC Invocation Flow
The sequence diagram below details the process of a consumer invoking a remote method on a provider.
This diagram shows a consumer first querying Zookeeper to get the provider's address and then making a direct RPC call to the provider.
Sources: zheng-upms/zheng-upms-server/src/main/resources/applicationContext-dubbo-consumer.xml:12, 29, zheng-upms/zheng-upms-rpc-service/src/main/resources/META-INF/spring/applicationContext-dubbo-provider.xml:13, 15
Summary
The zheng project's RPC layer, built with Dubbo and Zookeeper, establishes a robust foundation for its microservices architecture. By separating service contracts (-rpc-api) from implementations (-rpc-service) and using a central registry, the system achieves loose coupling and high scalability. This allows independent development, deployment, and scaling of different functional modules like zheng-upms and zheng-cms while ensuring seamless communication between them.