Dew Microservices Ecosystem

Dew manages JVM parameters automatically based on the container resource limits defined in app.containerResourcesLimits and app.containerResourcesRequests.

While you can manually set -Xms or -Xmx in app.runOptions, Dew provides a more automated way to manage memory using the following priority and rules:

1. Manual Override: If JAVA_OPTIONS contains -Xmx or -Xms, those values are used first.
2. Memory Ratio: If JAVA_MAX_MEM_RATIO is provided, -Xmx is set to (Max Available Memory) / JAVA_MAX_MEM_RATIO. (e.g., a ratio of 50 sets -Xmx to 50% of available memory).
3. Automatic Scaling (if no ratio provided):
   • If system memory $\le$ 300M: -Xmx is set to 25% of available memory.
   • If system memory $>$ 300M: -Xmx is set to 50% of available memory.
4. Initial Memory (-Xms):
   • If JAVA_INIT_MEM_RATIO is 0, -Xms is not set.
   • If JAVA_INIT_MEM_RATIO is non-zero, -Xms is set to -Xmx / JAVA_INIT_MEM_RATIO.
   • If JAVA_INIT_MEM_RATIO is not provided, it defaults to 100 (making -Xms equal to -Xmx).

Dew provides abstracted interfaces for distributed capabilities, supporting Redis, Hazelcast, and RabbitMQ.

Supported Features by Implementation

|= | Feature | Redis | Hazelcast | Rabbit | MQTT | Distributed Cache | * | | | | Distributed Map | * | * | | | Distributed Lock | * | * | | | MQ | * | * | * | * (pub-sub only) | Leader Election | * | | | |=

Enabling Cluster Support

1. Add boot-starter.
2. Add a specific SPI dependency (e.g., cluster-spi-redis).
3. Configure the implementation in application.yml under dew.cluster.

Distributed Cache

Access via Dew.cluster.cache.

Dew.cluster.cache.set("key", "value", 1);
String val = $.json.toJson(Dew.cluster.cache.get("key"));

Distributed Map

Create named instances of distributed maps.

ClusterMap<TestMapObj> mapObj = Dew.cluster.map.instance("test_obj_map", TestMapObj.class);
mapObj.put("test", new TestMapObj());

Distributed Lock

Use tryLock or the simplified tryLockWithFun to ensure automatic unlocking.

ClusterLock lock = Dew.cluster.lock.instance("test_lock");
// Automatically unlocks after 1s if not manually released
if (lock.tryLock(0, 1000)) {
    try {
        // business logic
    } finally {
        lock.unLock();
    }
}

// Simplified version
lock.tryLockWithFun(0, 1000, () -> {
    // business logic (auto-unlocks)
});

Message Queue (MQ)

Supports pub-sub and req-resp patterns.

// Pub-Sub
Dew.cluster.mq.subscribe("topic", msg -> logger.info(msg.getBody()));
Dew.cluster.mq.publish("topic", "payload");

// Req-Resp
Dew.cluster.mq.response("topic", msg -> logger.info(msg.getBody()));
Dew.cluster.mq.request("topic", "request_data");

Note: For pub-sub, the topic must exist; subscribe will create it automatically.

Leader Election

ClusterElection election = Dew.cluster.election.instance("election_name");
if (election.isLeader()) {
    // perform leader tasks
}

// Distributed Lock Example
ClusterLock lock = Dew.cluster.lock.instance("my_lock");
lock.tryLockWithFun(0, 5000, () -> {
    // Critical section
});

Dew supports an authentication cache that allows business systems to cache login information generated by an external authentication system. This requires a cluster cache implementation (e.g., Redis).

Configuration

Configure token behavior in dew.security:

• token-flag: The header/parameter name for the token (default: X-Dew-Token).
• token-in-header: If true, token is in header; otherwise, in URL parameters.
• token-kinds: Define different token types (e.g., PC, Android) with specific expire-sec and revision-history-limit.

Using OptInfo

OptInfo is the base class for login information. You can extend it to include custom user attributes.

Important: If you use a custom subclass of OptInfo, you must register it at startup using DewContext.setOptInfoClazz(YourCustomClass.class).

API Workflow

1. Login: After successful authentication, call Dew.auth.setOptInfo(optInfo).
2. Access: In subsequent requests, call Dew.context().optInfo() to retrieve the user info.
3. Logout: Call Dew.auth.removeOptInfo().

Custom Auth Adapter

If the default Redis-based adapter is insufficient, implement the AuthAdapter interface and register it:

Dew.auth = new CustomAuthAdapter();

// Setting login info
Dew.auth.setOptInfo(new OptInfoExt()
    .setAccountCode("user123")
    .setToken(token));

// Retrieving login info
Optional<OptInfoExt> info = Dew.auth.getOptInfo();

Dew recommends using a protocol-agnostic response format via the Resp class. This ensures consistency across HTTP, RPC, and MQ interactions.

Response Format

{
    "code": "", // Response code (e.g., 200 for success)
    "message": "", // Error description or status message
    "body": // Response payload
}

Usage

public Resp<String> myMethod() {
    return Resp.success("Success Data");
    // or
    return Resp.notFound("Not Found");
}

HTTP Status Codes and Fallbacks

• Resp codes are independent of HTTP status codes. Usually, HTTP status is 200.
• To trigger a circuit breaker (like Hystrix) to treat a response as a failure, use .fallback().
• Resp.serverError("msg") returns HTTP 200 with a body containing code: 500.
• Resp.serverError("msg").fallback() returns HTTP 500.
• The framework automatically converts all 5xx exceptions into HTTP 500 status codes.

public Resp<String> test() {
    return Resp.success("enjoy!");
}

// To force an HTTP 500 for circuit breaking:
public Resp<String> error() {
    return Resp.serverError("Critical Error").fallback();
}

The Dew project is organized into several functional areas. Developers can leverage specific starters and modules depending on their microservice needs:

Framework Modules (framework/modules)

• parent-starter: The parent POM module.
• boot-starter: Core module containing Spring Boot Web dependencies.
• Cluster Capabilities: Interfaces and implementations for various clustering technologies:
  • cluster-common: Cluster capability interfaces.
  • cluster-hazelcast: Hazelcast implementation.
  • cluster-rabbit: RabbitMQ implementation.
  • cluster-redis: Redis implementation.
  • cluster-mqtt: MQTT implementation.
  • cluster-rocket: Rocket MQ implementation.
  • cluster-skywalking: Skywalking implementation.
• Utility Starters:
  • idempotent-starter: Idempotency handling.
  • dbutils-starter: Dynamic database processing.
  • ossutils-starter: OSS (Object Storage Service) processing.
  • hbase-starter: Spring Boot HBase integration.
  • test-starter: Unit testing support.

DevOps and Tools

• sdkgen-maven-plugin: Plugin for automatic SDK generation and uploading.
• devops: Contains Maven plugins (dew-maven-plugin, dew-maven-agent), execution scripts, and CI/CD configurations (GitLab CI, Jenkins).

When you execute mvn -P devops deploy -Ddew_devops_profile=<profile>, the plugin performs an intelligent deployment workflow:

1. Dependency Analysis: Identifies all Maven modules from the root pom.xml and sorts them by dependency order.
2. Change Detection: Compares the current Git commit against the last deployed version to identify changed files.
3. Module Filtering: Determines which modules need deployment based on the detected changes.
4. Preparation & Build:
   • JVM Services (Spring Boot): Runs mvn package spring-boot-maven-plugin:repackage to create a fat JAR.
   • Frontend Projects: Runs npm install, installs @tarojs/cli, sets NODE_ENV=test, and executes npm run build:h5 to generate the dist folder.
5. Containerization: Executes docker build and docker push to publish images to Harbor for both JVM services and frontend projects.
6. Deployment:
   • JVM Libraries/Pom Projects: Runs mvn deploy to the Maven repository and creates a ConfigMap to record the version.
   • JVM Services/Frontend Projects: Deploys the deployment and service to Kubernetes and creates a ConfigMap to record the version.

Dew recommends a specific hierarchical structure for large-scale projects to separate build logic, core services, SDKs, terminals, and documentation.

Key components include:

• sources/basics: Core dependencies (parent, common, common-service) that must be deployed to a Maven repository.
• sources/services: Individual microservices.
• sources/sdk: Language-specific SDKs (Java, JS, REST, etc.).
• sources/terminals: Client applications (Android, iOS, WeChat, etc.).
• docs: Documentation managed via Asciidoc and Maven.
• env: Environment configurations (e.g., Spring Cloud Config stored in Git).
• .gitmodules: Defines Git submodules for all constituent projects.

----
X Build Project
|- sources
|  |- basics
|  |  |- parent
|  |  |- common
|  |  |- common-service
|  |  |- <...>
|  |- services
|  |  |- <service 1>
|  |  |- <service ...>
|  |- sdk
|  |  |- <java>
|  |  |- <js>
|  |  |- <rest>
|  |  |- <...>
|  |- terminals
|  |  |- <android>
|  |  |- <ios>
|  |  |- <wechat>
|  |  |- <...>
|  |- docs
|  |  |- src
|  |  |  |- main
|  |  |  |  |- asciidoc
|  |  |  |  |  |- book.adoc
|  |  |  |  |  |- <...>
|  |  |  |  |- resources
|  |  |  |  |  |- images
|  |  |  |  |  |- <...>
|  |  |  |- pom.xml
|  |  |- .gitignore
|  |- env
|  |  |- application.yml
|  |  |- <...>
|  |  |- .gitignore
|  |- pom.xml
| .gitmodules
| .gitignore
| README.adoc
----