Configuring the Service Opening Platform

Prerequisites

• An instance (platform) and its cascaded instance (subsidiary) can communicate with each other.

  If the two instances are in different VPCs, create a VPC peering connection. For details, see VPC Peering Connection.

• If the two instances are located in different networks and communicate with each other through an air wall, their IP address and port number must be configured on the air wall. In addition, the air wall must use the TCP protocol for secure access. A dedicated VPN or tunnel can also be used to implement cross-network interworking.

Configuring Instance Cascading

Cascade the platform instance and its subsidiary instances so that the platform instance can open each subsidiary instance as backend service APIs.

1. Enable cascading for subsidiary instances.
   1. Log in to the ROMA Connect console that displays subsidiary instance A. On the Instances page, click View Console.
   2. Choose Instance Information > Configuration Parameters and locate the cascade parameter.
   3. Click Edit on the right of the parameter, set Current Value to on, and click Save.
   4. Click to set more cascading parameters.
      

      Table 1 Subsidiary instance configuration

      Parameter	Description
      cascade_auth_key	Encryption key used for authentication between APIs in the cascading relationship. The cascade_auth_key values of the subsidiary instance and platform instance must be the same.
      cascade_instance_ids	Enter the platform instance ID.

   5. Repeat 1.a to 1.d to enable cascading for subsidiary instance B.
2. Enable cascading for the platform instance.
   1. Log in to the ROMA Connect console that displays the platform instance. On the Instances page, click View Console.
   2. Choose Instance Information > Configuration Parameters and locate the cascade parameter.
   3. Click Edit on the right of the parameter, set Current Value to on, and click Save.
   4. Click to set more cascading parameters.
      

      Table 2 Platform instance configuration

      Parameter	Description
      cascade_auth_key	Encryption key used for authentication between cascading APIs. The subsidiary and platform instances must use the same cascade_auth_key value.
      cascade_instance_ids	You do not need to set this parameter in the platform instance.

Configuring a Load Balance Channel Between Instances

Configure the load balance channel from the platform instance to each subsidiary instance. When the platform instance calls the API of the subsidiary instance as the backend service, the dedicated authentication channel can be used to avoid authentication conflicts.

1. In the navigation pane of the platform instance console, choose API Connect > API Policies. On the Load Balance Channels tab, click Create Load Balance Channel.
2. On the page displayed, configure load balance channel information.

   Table 3 Basic information

   Parameter	Description
   Name	Enter a load balance channel name. Using naming rules facilitates future search.
   Port	Enter the access port number in the load balance channel. You can determine the port number based on the protocol used by the API in the subsidiary instance. For HTTP, set this parameter to 80. For HTTPS, set this parameter to 443.
   Routing Algorithm	Select an algorithm for routing backend service requests. The load balance channel determines which servers the algorithm will send the requests to. WRR: Requests are forwarded to each cloud server in order of server weight. WLC: Requests are forwarded to the cloud server with the fewest live connections in order of server weight. SH: Requests are forwarded to the cloud server by source IP address. Requests with the same source IP address are forwarded to the same server unless the server is unavailable. URI hashing: Requests are forwarded to the cloud server by request path. Requests from the same path are forwarded to the same server unless the server is unavailable.

3. Configure servers.
   1. Specify the way to add servers. Set Mode to Specify IP addresses if you want to access subsidiary instance APIs.
   2. Click Create Server Group. In the dialog box displayed, configure group information and click OK.
      Servers can be added to different groups.

      Table 4 Server group configuration

      Parameter	Description
      Group Name	Enter a server group name. Using naming rules facilitates future search.
      Weight	Enter the weight of the server group. The larger the weight, the more requests can be forwarded to the servers in the group.
      Description	Enter a brief description of the server group.

   3. Click Add Backend Server Address.
   4. Configure backend server information.

      Table 5 Backend server information

      Parameter	Description
      Backend Server Address	Enter the API access address of the subsidiary instance. IP address format: Set this parameter to the EIP of the subsidiary instance if the two instances communicate with each other over a public network. Set this parameter to the APIC connection address of the subsidiary instance if the two instances communicate with each other over a VPC intranet. Domain name format: Enter the access domain name of the API.
      Standby Node	Enabled: The backend server serves as a standby node. It works only when all non-standby nodes are faulty.
      Port	Access port number of the backend server. If the port number is 0, the port of the load balance channel is used.
      Server Status	Specify whether to enable the server. Requests are distributed to the server only after it is enabled.

4. Configure the health check.

   The health check function is enabled by default. If you do not need the health check, disable this function.

   Table 6 Health check configurations

   Parameter	Description
   Protocol	Select the protocol used for the health check. Options: TCP, HTTP, or HTTPS
   Two-Way Authentication	Available for Protocol set to HTTPS. Specify whether to enable two-way authentication between ROMA Connect and backend servers.
   Path	Mandatory for Protocol set to HTTP or HTTPS. Enter the health check URL.
   Method	Mandatory for Protocol set to HTTP or HTTPS. Select the HTTP request method used for the health check. The value can be GET or HEAD.
   Check Port	Enter the destination port of the health check. By default, the port number configured for the load balance channel is used.
   Healthy Threshold	Number of consecutive successful checks required for a server to be considered healthy. Example: If set to 2, ROMA Connect declares the ECS status to be healthy when the check is successful twice in a row.
   Unhealthy Threshold	Number of consecutive failed checks required for a server to be considered unhealthy. Example: If set to 5, ROMA Connect declares the ECS status to be abnormal when the check fails five times in a row.
   Timeout Interval(s)	Response timeout of a health check, in seconds. If no response is received within this time, the health check fails.
   Interval (s)	Interval between consecutive checks, in seconds.
   Status Codes	Mandatory for Protocol set to HTTP or HTTPS. If specified HTTP status codes are returned, the response is successful.

5. Click Finish.
6. Repeat 1 to 5 to configure the load balance channel from the platform instance to other subsidiary instances.

Creating an API on the Platform Instance

Create and open APIs in the platform instance, and use the subsidiary instance APIs as the backend service. Each subsidiary or partner calls other subsidiary instances' APIs opened by the platform instance.

For details about how to create an API, see Creating an API. Only the backend configuration is different, as shown as follows.