How Huawei Cloud EventGrid and Apache EventMesh Use gRPC to Simplify Event‑Driven Integration

In the SaaS era, businesses demand architectures that support rapid, secure, and efficient application changes. Composable applications—modular, business‑centric components—address this need, but integration standards between apps (often limited to a single protocol like HTTP or TCP) remain a challenge.

EventGrid: A Serverless Event Bus

EventGrid is Huawei Cloud's next‑generation, serverless event bus for the cloud‑native era. It ingests events from traditional apps, cloud services, and SaaS partners, offering high availability, loose coupling, and distributed event‑driven architecture. Core functions include event aggregation, schema validation, filtering, routing, transformation, and delivery, plus fault‑tolerant retry, dead‑letter storage, query, tracing, and workflow capabilities.

Architecture Overview

EventGrid connects to various cloud services as event sources, such as distributed messaging (RocketMQ, Kafka, Pulsar), object storage (OBS), and distributed cache (Redis). Sources generate management, data, and custom events, which are pushed via the EventGrid SDK to the Event Bus Runtime. Tenants can configure multiple event channels; default channels store Huawei Cloud events, while custom channels store application‑specific events. Consumers subscribe to channels, defining source, target, filter, and transformation rules. Event delivery can be synchronous (HTTP) for applications/microservices or asynchronous (message queues) for SaaS partners.

EventMesh Integration

EventGrid adopts Apache EventMesh as its runtime engine. EventMesh separates applications from the event store, supports hybrid‑cloud and traditional data‑center scenarios, and offers a plugin architecture for connectors (e.g., RocketMQ, Kafka) and authentication methods (BasicAuth, TokenAuth).

gRPC Support in EventMesh v1.4.0

Version 1.4.0 adds full gRPC support, enabling high‑performance, bidirectional asynchronous communication via Protobuf‑defined APIs. This unifies previous TCP and HTTP SDKs, allowing lightweight runtimes and multi‑language SDKs (Java, Go, JavaScript, etc.).

service PublisherService {
   rpc publish(SimpleMessage) returns (Response);
   rpc requestReply(SimpleMessage) returns (SimpleMessage);
   rpc batchPublish(BatchMessage) returns (Response);
}

Events use the SimpleMessage model, supporting synchronous, asynchronous, and batch publishing. The message header carries producer metadata (env, region, ip, etc.), while fields like producerGroup, topic, ttl, uniqueId, and seqNum manage routing and lifecycle.

message RequestHeader {
    string env = 1;
    string region = 2;
    string idc = 3;
    string ip = 4;
    string pid = 5;
    string sys = 6;
    string username = 7;
    string password = 8;
    string language = 9;
    string protocolType = 10;
    string protocolVersion = 11;
    string protocolDesc = 12;
}

message SimpleMessage {
   RequestHeader header = 1;
   string producerGroup = 2;
   string topic = 3;
   string content = 4;
   string ttl = 5;
   string uniqueId = 6;
   string seqNum = 7;
   string tag = 8;
   map<string, string> properties = 9;
}

Subscription Services

service ConsumerService {
   rpc subscribe(Subscription) returns (Response);
   rpc subscribeStream(stream Subscription) returns (stream SimpleMessage);
   rpc unsubscribe(Subscription) returns (Response);
}

Subscriptions support cluster (single consumer) and broadcast (all consumers) modes, with webhook (HTTP) or gRPC streaming targets. Load balancing uses round‑robin by default, with pluggable algorithms, and retries up to three times before failing over.

Threading and Performance

EventMesh configures separate thread pools for sending, client management, and pushing messages (e.g., eventMesh.server.sendmsg.threads.num=50). Incoming gRPC requests are dispatched to these pools, preventing blocking and improving concurrency.

public void publish(SimpleMessage request, StreamObserver<Response> responseObserver){
    EventEmitter<Response> emitter = new EventEmitter<>(responseObserver);
    threadPoolExecutor.submit(() -> {
        SendAsyncMessageProcessor processor = new SendAsyncMessageProcessor(eventMeshGrpcServer);
        try {
            processor.process(request, emitter);
        } catch (Exception e) {
            logger.error("Publish error", e);
            ServiceUtils.sendRespAndDone(StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR, e.getMessage(), emitter);
        }
    });
}

Non‑Blocking vs. Blocking Stubs

gRPC offers non‑blocking stubs for fire‑and‑forget scenarios and blocking stubs for request‑reply flows. EventMesh SDK currently uses blocking stubs; future work will adopt non‑blocking stubs for higher throughput.

Multi‑Language SDKs

Prior to v1.3.0 only Java SDK existed. With gRPC, EventMesh can generate SDKs for Java, Go, NodeJS, PHP, Python, C#, C++, enabling broader ecosystem integration (e.g., KNative, Dapr).

Unified TCP/HTTP via gRPC

gRPC supports Unary, Server Streaming, Client Streaming, and Bidirectional Streaming RPCs. EventMesh v1.4.0 leverages Unary and Bidirectional Streaming to provide five SDK APIs: Event Publish, Broadcast, Request‑Reply, Webhook Subscription, and Event Stream Subscription, simplifying protocol choice for developers.

Getting Started

Documentation and sample code are available for deploying EventMesh Runtime and using the SDK. Example commands to start the runtime on Linux:

tar -zxvf Eventmesh_1.3.0-release.tar.gz
cd bin
sh start.sh
tail -f ./logs/eventmesh.out

Sample steps to run a gRPC publisher and subscriber are provided in the eventmesh-example project.

By introducing gRPC, EventGrid and EventMesh achieve standardized, protocol‑agnostic event integration, paving the way for further standardization in schema, governance, and other integration domains.