Dubbo has a lot of features, so you don’t need to reinvent the wheel a lot of times. Here are some features that you may not know, but are very useful.

01 directly connected to the Provider

In the development and testing environment, may need to bypass the registry, testing only designated service provider, this time may need A point-to-point direct, point-to-point direct mode, will be in the service interface, ignore the registry provider list, A point-to-point interface configuration, do not affect B interface to get the list from registry (note: This feature is only recommended for development and test environments.

<dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" version="1.0.0" url="Dubbo: / / 172.18.1.205:20888 /" />Copy the code

02 versions

When an interface is implemented and upgraded incompatibly, you can use the version number to transition. Services with different version numbers do not reference each other. The usage is as follows:

<dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" version="1.0.0" />Copy the code

Using the dubbo feature, we can achieve grayscale publishing of some functions as follows:

  • The old implementation definition of the interface version=”1.0.0″, the new implementation of the interface version=”2.0.0″
  • Version =”*”

When Provider and Consumer are defined this way, the old and new interface implementations each take 50% of the traffic.

With dubbo, incompatible versions can also be migrated:

  • During low-pressure periods, upgrade half of the Provider to the new version.
  • Upgrade all customers to the new version;
  • Then upgrade the remaining half of the providers to the new version.

03 Echo Test

Echo test is used to check whether the service is available. Echo test is performed according to the normal request flow to test whether the whole call is smooth and can be used for monitoring. All services automatically implement the EchoService interface and can be used by forcing any service reference to an EchoService.

EchoService echoService = (EchoService) demoService;
System.out.println(echoService.$echo("hello"));Copy the code

04 Implicit parameters

Arguments can be passed implicitly between Consumer and Provider via RpcContext setAttachment() and getAttachment(), for example, the Controller layer intercepts login tokens, If the memberId obtained by token is passed to dubbo service, the KV pair set by setAttachment() will be cleared after the completion of a remote call, that is, multiple remote calls will be set for multiple times. Usage:

  • The set of a service
RpcContext.getContext().setAttachment("CRT_MEMBER_ID"."13828886888");Copy the code
  • The client get
RpcContext.getContext().getAttachment("CRT_MEMBER_ID")Copy the code

05 context

The context holds the environment information required during the current invocation. All configuration information will be converted to the URL parameter RpcContext, which is a temporary state logger of ThreadLocal. The state of the RpcContext changes when an RPC request is received or initiated. For example, if A calls B and B calls C, RpcContext records information about B dialed by A before B dialed Con machine B, and RpcContext records information about C dialed by B after B dialed C. Usage:

boolean isConsumerSide = RpcContext.getContext().isConsumerSide();Copy the code

06 Local Camouflage

Local masquerading is often used for service degradation, such as a validation service where, when all service providers fail, the client does not throw an exception but returns authorization failure through Mock data. The mock implementation class is executed when the Provider throws an RpcException (which must be thrown) instead of returning the result remotely:

<dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" version="1.0.0" mock="com.alibaba.dubbo.demo.consumer.mock.DemoServiceMock"/>Copy the code

DemoServiceMock implementation source code:

public class DemoServiceMock implements DemoService {    
       public String sayHello(String name) {        
              return "mock-value"; }}Copy the code

07 Generalization call

The generalized interface invocation method is mainly used when the client does not have API interfaces and model class elements. All POJOs in parameters and return values are represented by Map. It is usually used for framework integration, for example, to achieve a universal service testing framework that can invoke all service implementations through GenericService. Usage:

<dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" generic="true"/>Copy the code

Call source code:

Public class Main {public static void Main (String[] args) {public static void Main (String[] args) { // Reference the remote service, which encapsulates all connections to the registry and service provider, ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>(); // Reference. SetInterface ("com.alibaba.dubbo.demo.DemoService");        
              reference.setVersion("1.0.0"); // Declare reference. SetGeneric (true); / / com. Alibaba. Dubbo. RPC. Service. The interface GenericService can replace all references to use GenericService GenericService = reference. The get (); // Call Object Result = genericService without converting basic types such as Date,List,Map, etc.$invoke("sayYes", new String[] {
                     "java.lang.String"
              }, 
              new Object[] {"afei"});        
              System.out.println("result --> "+result); Teacher = new HashMap<String, Object> teacher = new HashMap<String, Object>(); teacher.put("id"."1");        
              teacher.put("name"."admin");        
              teacher.put("age"."18");        
              teacher.put("level"."3");        
              teacher.put("remark"."Test"); // If POJO is returned, Map Result = genericService is automatically converted.$invoke("justTest", new String[] 
                 {"com.alibaba.dubbo.demo.bean.HighTeacher"}, new Object[]{teacher});                  System.out.println("result --> "+result); }}Copy the code

08 Access Logs

If you want to record each request information, you can enable the access log, similar to the access log of Ngnix. Note: The amount of logs is large. Please pay attention to the disk capacity. Usage mode (if configured locally, global access logs will be invalid) : configure globally:

<dubbo:provider accesslog="/app/dubbo-demo.log"/>Copy the code

Configuration part:

<dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" accesslog="/app/demo.log"/>  <dubbo:service interface="com.alibaba.dubbo.demo.TestService" ref="testService" accesslog="/app/test.log"/>Copy the code

Log format style:

172.18.1.205 10:23:20 [2017-11-22] : 56144 - > 172.18.1.205:20886 - com. Alibaba. Dubbo. Demo. DemoService: 1.0.0 sayHello(java.lang.String) ["afei"]Copy the code

09 Delayed Exposure

If the service needs time to warm up, such as initializing the local cache, waiting for relevant resources to be in place, etc., delay can be used for delay exposure. How many milliseconds to delay Dubbo exposing the service after the Spring container has initialized. Usage:

<dubbo:provider delay="5000"/>Copy the code

Or:

<dubbo:service delay="5000" interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" version="1.0.0"/>Copy the code