Alibaba Cloud Microservice Demo

This project provides GraalVM native image support for OpenTelemetry-java-instrumentation 1.32.0. It enables building native images for applications that use the OpenTelemetry (OT) Java agent.

It addresses two limitations in the standard GraalVM agent support:

1. premain actions: Provides a native version of the OT agent premain via GraalVM's substitution mechanism to handle initialization without bytecode transformation.
2. JDK class modifications: Provides native image runtime versions of JDK transformations to avoid conflicts with GraalVM's own internal modifications.

This project is a demonstration of microservices running on Alibaba Cloud. The architecture consists of several key components:

Core Applications

• frontend: A Java application using SpringMVC and Thymeleaf template engine.
• cartservices: A Java application providing shopping cart operations, powered by Apache Dubbo for RPC.
• productservice: A Java application providing product listing and query operations, powered by Spring Cloud Alibaba.

Underlying Technologies

• Apache Dubbo: Used for Remote Procedure Call (RPC).
• Spring Cloud Alibaba: Used for service-to-service communication.
• Nacos: Used for Service Discovery and Configuration management.
• Alibaba Cloud EDAS: Used for deployment and hosting.
• Alibaba Cloud ARMS: Used for monitoring.
• Alibaba Cloud SAE: Used for serverless deployment (infrastructure-less hosting).

Standard GraalVM native-image-agent interception may miss certain reflections used by OpenTelemetry (e.g., when the OT build system generates reflection results at build time via Gradle).

To ensure these reflections are available at runtime, use OTFeature. This class works with the GraalVM Feature mechanism to register necessary reflection data during the native image build process.

When building a native image, you need to define how the premain phase behaves. There are two primary approaches:

1. Environment Detection: Check the java.vm.name system property. For native images, this property is set to Substrate VM.

   String vm = System.getProperty("java.vm.name");
   if ("Substrate VM".equals(vm)) {
       // Native image specific logic
   } else {
       // Standard JVM logic
   }

2. GraalVM Substitutions: Use GraalVM's substitution API to replace original premain methods with native-compatible versions at build time. This project uses Target_io_opentelemetry_javaagent_OpenTelemetryAgent as the substitution entry point.

String vm = System.getProperty("java.vm.name");
if ("Substrate VM".equals(vm)) {
    // In native image
    ...
} else {
    // In JVM
    ...
}

To successfully support agent instrumentation in a native image, two components must work in tandem:

1. GraalVM Side: The compiler must be capable of compiling code that has been instrumented by an agent into a native image. This requires specific support (e.g., via the agent support PR).
2. Agent Side: The agent developer must define how the agent behaves within a native image environment. This includes handling premain behaviors and managing JDK class transformations. The opentelemetry-agent-native project serves as a reference implementation for this adaptation.

Some local configuration files in this repository are encrypted using git-crypt. You must install it to access these profiles. Follow the installation instructions for your operating system below.

### MAC OS
```shell script
brew install git-crypt

Linux (CentOS)

yum install gcc-c++
yum install openssl-devel

Linux (Ubuntu)

apt-get install g++
apt-get install libssl-dev

Linux (Manual Build - All Distros)

git clone https://github.com/AGWA/git-crypt
cd ./git-crypt
make
make install

Windows

1. Download the .exe file from git-crypt-windows.
2. Copy the file to /{git-path}/Git/cmd/.

You can build the docker images for this project using either docker-compose or individual build scripts located in the sub-modules.

Using docker-compose

Run this command from the root directory to build all images defined in the compose file:

docker-compose build

Using sub-module scripts

Navigate to the src directory. Each sub-module contains a build.sh file. Run the script within the specific module directory to build its corresponding image:

./build.sh

To deploy the application to a Kubernetes cluster using the provided YAML manifests, navigate to the kubernetes-manifests/ directory and apply all files:

Apply manifests

cd kubernetes-manifests/
for i in *.yaml; do kubectl apply -f $i; done

Delete deployment

for i in *.yaml; do kubectl delete -f $i; done

To build the container images for the microservices located in directories A, B, C, or gateway, follow these steps:

1. Navigate to the specific service directory (e.g., A/).
2. Run the build script: ./build.sh.
3. Tag the resulting image using docker tag.
4. Push the image to your registry using docker push.

# Example workflow within a service directory like A/
./build.sh
docker tag <image_id> <registry>/<repo>:<tag>
docker push <registry>/<repo>:<tag>

Deploy the mse-go-demo application to a Kubernetes cluster using Helm 3. This command creates the namespace if it does not exist and uses the example values file for configuration.

helm3 upgrade mse-go-demo1 helm/mse-go-demo \
  --namespace default --create-namespace \
  --install \
  --values helm/mse-go-demo/values.example.yaml

To run the entire microservice stack locally using Docker Compose, use the following commands:

Start deployment

docker-compose -f docker-compose.yml up

Stop and undeploy

docker-compose -f docker-compose.yml down