What Must I Check Before Migrating Services from the Professional to the Exclusive Microservice Engine?

Background

The professional microservice engine is a logical multi-tenant engine. Since all tenants share one engine, any engine fault will interrupt all registered services. To prevent such fault and ensure service continuity, switch services from the professional microservice engine to the commercial exclusive microservice engine.

Switching has the following advantages:

1. Physical isolation. An exclusive microservice engine is physically isolated, since one tenant uses one engine exclusively. If the engine is faulty, other engines are not affected.
2. Multiple AZs. An exclusive microservice engine can be deployed in multiple AZs to improve reliability.
3. Large capacity. You can create many exclusive microservice engines and each one supports 2000 instances, compared to 500 instances per tenant of a professional microservice engine.

After you switch from the professional edition (the engine name is Cloud Service Engine) to the exclusive edition (the engine name can be customized), the engine functions remain the same and user configurations and service data have been migrated to the new engine.

Precautions

1. Check whether you are using a professional microservice engine. To do this, confirm that the instance is registered with the engine named Cloud Service Engine.
2. Create an exclusive microservice engine before the migration. Select one with 100, 500, or 2000 instances.
3. The new engine's VPC must be the VPC where the component to be upgraded is deployed.
4. Migration switches over registry center and configuration center addresses. Switchover causes all services registered with the old engine to be registered with the new one. During this process, there may be mixed registries, preventing services from being discovered or invoked and affecting availability.
5. Confirm the deployment mode. If it is ServiceStage application hosting, contact O&M personnel to obtain a quick migration solution. Otherwise, change the registry and configuration center addresses to the address of the new exclusive engine. In this case, you are advised to get a risk evaluation from O&M personnel and confirm a reliable solution before migrating with diversified deployment modes.
6. The migration includes both instance and configuration migration, so back up data in the configuration center first. Contact O&M personnel for any assistance. Migration includes both dynamic and global configurations. Global configuration: On the professional engine console, switch to the environments one by one and check whether a global configuration exists. If yes, export the global configuration for backup. Dynamic configuration: Check whether a dynamic configuration exists. If yes, export and save it. Ignore the microservice and microservice scope without dynamic configuration.
7. Upgrade each microservice before the migration to avoid failure by external factors.
8. Check whether the JAVA_ARGS parameter exists. If yes, check whether the following information exists:

   spring.cloud.servicecomb.discovery.address
   spring.cloud.servicecomb.credentials.enabled
   spring.cloud.servicecomb.credentials.accessKey
   spring.cloud.servicecomb.credentials.secretKey
   spring.cloud.servicecomb.credentials.akskCustomCipher
   spring.cloud.servicecomb.credentials.project

   If yes, they are no longer needed after the migration and can be deleted.

9. If importing a configuration file in the original 2.x configuration center format failed, a message indicates that the file is empty or the format is incorrect. In this case, rectify the fault by referring to What Do I Need to Know Before Upgrading an Exclusive ServiceComb Engine?.