A Brief Introduction to Distributed Architecture with Dubbo Implementation

Preface

More and more internet companies are turning their projects into services, which is a future development trend. This article uses a previous SSM project to help newcomers get started quickly.

Brief Discussion of Distributed Architecture

Distributed architecture may sound sophisticated, but its history makes it clear. Using an e‑commerce system as an example, we examine three stages.

Single System

For a startup, all business logic resides in one project because the user base is small and speed of development is critical.

Vertical Split – Multiple Applications

When traffic grows, applications are deployed on several servers and Nginx is used for reverse proxy and simple load balancing.

SOA Service‑Oriented Architecture

When the system becomes large (e.g., separate user, order, payment, and logistics services), tightly coupling them leads to heavy release overhead. Therefore, the project should be split into independent applications that can be developed and deployed separately.

Each application is independent, can consume services exposed by others, and can also provide its own services.

Dubbo‑Based Implementation

Dubbo is a widely used Chinese distributed service framework. The following code shows how to define a service interface and its implementation.

Providing a Service

Define the API in the SSM‑API module:

/**
 * Function: User API
 * @author chenjiec
 * Date: 2017/4/4 21:46
 * @since JDK 1.7
 */
public interface UserInfoApi {
    /**
     * Get user information
     * @param userId
     * @return
     * @throws Exception
     */
    public UserInfoRsp getUserInfo(int userId) throws Exception;
}

Implement the interface in the SSM‑SERVICE module:

import com.alibaba.dubbo.config.annotation.Service;
/**
 * Function:
 * @author chenjiec
 * Date: 2017/4/4 21:51
 * @since JDK 1.7
 */
@Service
public class UserInfoApiImpl implements UserInfoApi {
    private static Logger logger = LoggerFactory.getLogger(UserInfoApiImpl.class);
    @Autowired
    private T_userService t_userService;
    @Override
    public UserInfoRsp getUserInfo(int userId) throws Exception {
        logger.info("User query Id=" + userId);
        UserInfoRsp userInfoRsp = new UserInfoRsp();
        T_user t_user = t_userService.selectByPrimaryKey(userId);
        if (t_user == null) {
            t_user = new T_user();
        }
        CommonUtil.setLogValueModelToModel(t_user, userInfoRsp);
        return userInfoRsp;
    }
}

Dubbo Configuration Files

spring‑dubbo‑config.xml – registers the application, Zookeeper registry, monitor, protocol, provider and consumer settings:

<dubbo:application name="ssm-service" owner="crossoverJie" organization="ssm-crossoverJie" logger="slf4j"/>
    <dubbo:registry id="dubbo-registry" address="zookeeper://192.168.0.188:2181" file="/tmp/dubbo.cachr"/>
    <dubbo:monitor protocol="registry"/>
    <dubbo:protocol name="dubbo" port="20880"/>
    <dubbo:provider timeout="15000" retries="0" delay="-1"/>
    <dubbo:consumer check="false" timeout="15000"/>

spring‑dubbo‑provider.xml – scans the implementation package for @Service annotations:

<dubbo:annotation package="com.crossoverJie.api.impl"/>

spring‑dubbo‑consumer.xml – declares a reference to the remote service:

<dubbo:reference id="userInfoApi" interface="com.crossoverJie.api.UserInfoApi"/>

Admin Console Installation

Download the Dubbo source, build the dubbo-admin module, deploy the generated WAR to Tomcat, and modify dubbo.properties to point to your Zookeeper address.

dubbo.registry.address=zookeeper://127.0.0.1:2181
dubbo.admin.root.password=root
dubbo.admin.guest.password=guest

Login with the default credentials (root/root or guest/guest) to view registered services and consumers.

Consumer Project

A separate consumer project defines its own API (e.g., SalaryInfoApi) and implements it by invoking the previously defined UserInfoApi:

/**
 * Function: Salary API
 */
public interface SalaryInfoApi {
    public SalaryInfoRsp getSalaryInfo(int userId) throws Exception;
}

@Service
public class SalaryInfoApiImpl implements SalaryInfoApi {
    private static Logger logger = LoggerFactory.getLogger(SalaryInfoApiImpl.class);
    @Autowired
    UserInfoApi userInfoApi;
    @Override
    public SalaryInfoRsp getSalaryInfo(int userId) throws Exception {
        logger.info("Salary query Id=" + userId);
        SalaryInfoRsp rsp = new SalaryInfoRsp();
        UserInfoRsp userInfo = userInfoApi.getUserInfo(userId);
        rsp.setUsername(userInfo.getUserName());
        return rsp;
    }
}

The consumer only needs to depend on the SSM‑BOOT module, which already contains the necessary Dubbo consumer configuration.

Testing

A JUnit test verifies that the consumer can successfully call the provider:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"classpath*:/spring/*.xml"})
public class SalaryInfoApiImplTest {
    @Autowired
    private SalaryInfoApi salaryInfoApi;
    @Test
    public void getSalaryInfo() throws Exception {
        SalaryInfoRsp salaryInfo = salaryInfoApi.getSalaryInfo(1);
        System.out.println(JSON.toJSONString(salaryInfo));
    }
}

Conclusion

Using Dubbo to build a distributed service allows large systems to be split into independent sub‑applications, reducing the impact of failures. In production, each service typically runs in a master‑slave configuration, and automated deployment, monitoring, and log analysis tools (e.g., Jenkins, ELK) become essential.