Deploying Applications on Apache Dubbo

Deploying Istio Environment

Mon, 01 Jan 0001 00:00:00 +0000

1. Preparation

Docker, Helm, and kubectl environments are installed.
Dubbo-go CLI tools and dependencies are installed.

2. Deploy Istio Environment

Install the Istio base CRD and istiod components using Helm. You can also refer to the Istio Documentation for installation using istioctl.

$ helm repo add istio https://istio-release.storage.googleapis.com/charts
$ kubectl create namespace istio-system
$ helm install istio-base istio/base -n istio-system
$ helm install istiod istio/istiod --namespace istio-system

Delete the Istio horizontal pod autoscaler resources

Deploying Dubbo-go application in Istio environment

Mon, 01 Jan 0001 00:00:00 +0000

In this chapter, we will quickly create a set of Dubbo-go Server and Client applications using the application template and deploy them in an Istio cluster; observe, debug, and verify service discovery and successful calls.

1. Preparation

The dubbo-go CLI tool and dependency tools are installed, grpc_cli (for local debugging if needed).
The docker, helm, and kubectl environments are installed. (Arm machines must support docker buildx)
The task Deployment of Istio Environment is complete.

2. Developing the Server-side Dubbo-go Application

2.1 Create Project Template with dubbogo-cli

$ mkdir mesh-app-server
$ cd mesh-app-server
$ dubbogo-cli newApp . 
$ tree .
.
├── Makefile
├── api
│ └── api.proto
├── build
│ └── Dockerfile
├── chart
│ ├── app
│ │ ├── Chart.yaml
│ │ ├── templates
│ │ │ ├── _helpers.tpl
│ │ │ ├── deployment.yaml
│ │ │ ├── service.yaml
│ │ │ └── serviceaccount.yaml
│ │ └── values.yaml
│ └── nacos_env
│ ├── Chart.yaml
│ ├── templates
│ │ ├── _helpers.tpl
│ │ ├── deployment.yaml
│ │ └── service.yaml
│ └── values.yaml
├── cmd
│ └── app.go
├── conf
│ └── dubbogo.yaml
├── go.mod
├── go.sum
└── pkg
 └── service
 └── service.go

The generated project includes several directories:

Traffic Management

Mon, 01 Jan 0001 00:00:00 +0000

In this section, we will continue from the previous task 【Deploying Dubbo-go Applications in Istio Environment】.

In the previous task, we deployed a set of Dubbo-go Server and Client applications in the cluster and verified that service discovery and invocation were successful. In this section, we will create a new version of the server application. By configuring VirtualService and DestinationRule, we will achieve routing management and traffic shifting capabilities.

1. Preparation

The dubbo-go CLI tool and dependencies have been installed, as well as grpc_cli (for local debugging if needed).
Docker, Helm, and kubectl environments have been installed. (Arm machines need to support docker buildx)
The task 【Deploying Dubbo-go Applications in Istio Environment】 has been completed.

2. Develop Multi-Version Dubbo-go Applications.

2.1 Create Another Project Template Using dubbogo-cli

$ dubbogo-cli newApp .

2.2 Develop and Deploy Client Dubbo-go Application v2:

Write Business Logic

Modify the implementation method of package/service/service.go to return version number v2.0.0

func (s *GreeterServerImpl) SayHello(ctx context.Context, in *api.HelloRequest) (*api.User, error) {
	return &api.User{Name: "Hello " + in.Name, Id: "v2.0.0"}, nil
}

Modify the following configuration file to use the xds protocol as the registration center, loading the service structure named GreeterServerImpl.

Graceful Shutdown

Mon, 01 Jan 0001 00:00:00 +0000

Graceful Shutdown

Background

In a stable production environment, container scheduling is fully managed by k8s, and microservice governance is maintained and managed by the service framework or operations personnel. In scenarios like releasing a new version or scaling up/down, old container instances will be terminated and replaced with new ones. If this replacement process is not handled properly in high-traffic online production environments, it can lead to a large number of erroneous requests in a short time, triggering alarms and even affecting normal business operations. For larger organizations, the losses from issues during the release process can be enormous. Hence, the need for graceful shutdown has arisen. This requires the service framework to provide stable guarantees during the service offline process on top of stable service invocation and traditional service governance capabilities, thus reducing operational costs and improving application stability.

Proxyless Service Mesh

Mon, 01 Jan 0001 00:00:00 +0000

1. What is Proxyless Service-Mesh?

1.1 Brief Analysis of Service Mesh

Istio is the most popular open-source service mesh today. It consists of a control plane and a data plane, as shown in the architecture below, image sourced from istio official website

The control plane located at the bottom half of the image is responsible for the distribution of resources like configurations, service information, and certificates. The data plane, located at the upper half, focuses on the communication traffic between services; traditional service meshes intercept all business network traffic through proxies, which need to be aware of the configuration resources issued by the control plane to manage traffic directions as required.