Vivo Comment Middleware: Traffic and Data Isolation Using Dubbo, Sentinel, and MongoDB

The article introduces the design and implementation of the Vivo comment middle‑platform, which provides common capabilities such as comment publishing, likes, reporting, and custom sorting. It serves more than ten front‑end services (short video, browser, home screen, shop, etc.) and faces challenges of high availability, traffic spikes, and data isolation across different business lines.

1. Traffic Isolation

1.1 Traffic Grouping – High‑traffic services (e.g., the Vivo browser) are assigned dedicated clusters to avoid interference with other services.

The platform exposes Dubbo interfaces. By attaching a tag to each request, Dubbo’s tag‑routing mechanism routes the call to the appropriate provider cluster.

RpcContext.getContext().setAttachment(Constants.REQUEST_TAG_KEY, "browser");

Providers are also tagged. Two tagging methods are supported: dynamic rule tagging (higher priority) and static rule tagging. Dynamic tagging is managed by the internal operation system.

1.2 Multi‑tenant Rate Limiting – A single cluster may serve multiple businesses, so a per‑tenant rate‑limiting strategy is required. Sentinel’s hotspot‑parameter flow control is used, with the business identifier (clientCode) as the hotspot parameter.

Example Sentinel rule (JSON):

{
    "resource": "com.vivo.internet.comment.facade.comment.CommentFacade:comment(com.vivo.internet.comment.facade.comment.dto.CommentRequestDto)",
    "grade": 1,
    "count": 3000,
    "clusterMode": false,
    "paramFieldName": "clientCode",
    "paramFlowItemList": [
        {"object": "vivo-community", "count": 1000, "classType": "java.lang.String"},
        {"object": "vivo-shop", "count": 2000, "classType": "java.lang.String"}
    ]
}

When a limit is hit, Sentinel throws ParamFlowException . The platform converts this exception into a business‑friendly response via DubboAdapterGlobalConfig.setProviderFallback :

DubboAdapterGlobalConfig.setProviderFallback((invoker, invocation, ex) ->
    AsyncRpcResult.newDefaultAsyncResult(FacadeResultUtils.returnWithFail(FacadeResultEnum.USER_FLOW_LIMIT), invocation));

Dynamic rule distribution is achieved through a custom configuration center that pushes Sentinel rules to the services at runtime.

public class VivoCfgDataSourceConfig implements InitializingBean { private static final String PARAM_FLOW_RULE_PREFIX = "sentinel.param.flow.rule"; @Override public void afterPropertiesSet() { // Build data source, register listener, and push rules } }

Two ways to specify the hotspot parameter in Sentinel are discussed, and the article notes an enhancement that allows specifying a field of a parameter object as the hotspot key.

Enhanced hotspot‑parameter check snippet:

public static boolean passCheck(ResourceWrapper resourceWrapper, /*@Valid*/ ParamFlowRule rule, /*@Valid*/ int count, Object... args) {
    Object value = args[paramIdx];
    if (value instanceof ParamFlowArgument) {
        value = ((ParamFlowArgument) value).paramFlowKey();
    } else {
        if (StringUtil.isNotBlank(rule.getClassFieldName())) {
            value = getParamFieldValue(value, rule.getClassFieldName());
        }
    }
    // ... remaining logic
}

2. MongoDB Data Isolation

To prevent cross‑business data leakage and to balance DB load, two isolation strategies are employed: physical isolation (separate MongoDB clusters) and logical isolation (shared cluster with table or row segregation).

2.1 Physical Isolation – The system supports multiple MongoDB data sources. A proxy MultiMongoDbFactory selects the appropriate SimpleMongoDbFactory based on the business code stored in a thread‑local context.

public class MultiMongoDbFactory extends SimpleMongoDbFactory {
    private final Map
mongoDbFactoryMap = new ConcurrentHashMap<>();
    public void addDb(String dbKey, SimpleMongoDbFactory mongoDbFactory) {
        mongoDbFactoryMap.put(dbKey, mongoDbFactory);
    }
    @Override
    public DB getDb() throws DataAccessException {
        String customerCode = CustomerThreadLocalUtil.getCustomerCode();
        String dbKey = VivoConfigManager.get(ConfigKeyConstants.USER_DB_KEY_PREFIX + customerCode);
        if (dbKey != null && mongoDbFactoryMap.get(dbKey) != null) {
            return mongoDbFactoryMap.get(dbKey).getDb();
        }
        return super.getDb();
    }
}

A custom MongoTemplate bean is created using this factory:

@Bean
public MongoTemplate createIgnoreClass() {
    MultiMongoDbFactory multiMongoDbFactory = multiMongoDbFactory();
    if (multiMongoDbFactory == null) return null;
    MappingMongoConverter converter = new MappingMongoConverter(new DefaultDbRefResolver(multiMongoDbFactory), new MongoMappingContext());
    converter.setTypeMapper(new DefaultMongoTypeMapper(null));
    return new MongoTemplate(multiMongoDbFactory, converter);
}

2.2 Logical Isolation – When a dedicated cluster is not feasible, table‑level isolation is used. Each business gets its own collection name generated at runtime via SpEL in the @Document annotation:

@Document(collection = "comment_info_#{T(com.vivo.internet.comment.common.utils.CustomerThreadLocalUtil).getCustomerCode()}")
public class Comment {
    // fields omitted
}

The combination of physical and logical isolation ensures that different business lines can coexist without data interference while keeping the architecture non‑intrusive.

3. Conclusion

The presented practices enable the comment middle‑platform to support heterogeneous traffic loads, achieve high availability, and maintain clean separation of data and resources across multiple front‑end services. Similar isolation techniques are also applied to Redis and Elasticsearch clusters.