ServiceStage Best Practices

Hosting and Managing a Weather Forecast Microservice Application on ServiceStage

This section uses a weather forecast application to demonstrate the application scenarios of the microservice architecture and best practices of managing the runtime environment, building applications, and governing microservices on ServiceStage.

Enabling Security Authentication for an Exclusive ServiceComb Engine

The exclusive ServiceComb engine supports security authentication based on the Role-Based Access Control (RBAC) policy and allows you to enable or disable security authentication.

After security authentication is enabled for an engine, the security authentication account and password must be configured for all microservices connected to the engine. Otherwise, the microservice fails to be registered, causing service loss.

This section describes how to enable security authentication for an exclusive ServiceComb engine and ensure that services of microservice components connected to the engine are not affected.

Connecting ServiceComb Engine Dashboard Data to AOM through ServiceStage

For Java chassis applications connected to the ServiceComb engine, the real-time monitoring data on the ServiceComb engine dashboard is retained for 5 minutes by default. To permanently store historical monitoring data for subsequent query and analysis, use the custom metric monitoring function of ServiceStage to connect the microservice data displayed on the ServiceComb engine dashboard to AOM.

This section uses the application deployed using a software package as an example to describe how to complete the connection.

Migrating the Registered Microservice Engine Using ServiceStage Without Code Modification

This section describes how to migrate the microservice application components that are developed using the Java chassis microservice framework and registered with the professional ServiceComb engine to the exclusive ServiceComb engine without any code modification.

Hosting a Spring Boot Application on ServiceStage

Spring Boot is an open-source application development framework based on the Spring framework. It helps you quickly build production-level applications that can run independently.

This best practice uses the sample code provided by Spring to help you quickly deploy, access, and upgrade Spring applications on ServiceStage.

Using GitLab to Interconnect with Jenkins to Automatically Build and Upgrade Components Deployed on ServiceStage

After the code is developed, you need to pack the code into an image package or JAR package on Jenkins before each rollout, upload the image package to SWR or the JAR package to OBS, and then use ServiceStage to upgrade the component version. This process is complex. Frequent version tests cause low development and O&M efficiency and poor user experience.

If you manage your code on GitLab and use ServiceStage with components deployed to host applications, you can use GitLab to interconnect with Jenkins for automatic build and packaging to upgrade the components deployed on ServiceStage.

This practice uses the shell script output after Jenkins build and packaging to automatically build and package code after integration and upgrade components deployed on ServiceStage.

Using ServiceStage to Migrate Components Across AZs and Upgrade Components in Sequence Based on Release Management

In actual services, services need to be deployed in different AZs to improve availability due to equipment room faults.

However, when components are deployed in different AZs, each component must be configured as required. This is complex and error-prone. In addition, the components need to be deployed and run immediately after being created, and do not support on-demand deployment. If the component configurations are incorrect, the deployment fails. In this case, you need to delete the components, create them again, and then deploy them.

ServiceStage release management can be used to migrate and upgrade components across AZs.

• Batch clone release tasks can be used to migrate components across AZs.
• Batch upgrade release tasks can be used to upgrade components across AZs and specify the upgrade sequence of components in different AZs.