You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@servicecomb.apache.org by GitBox <gi...@apache.org> on 2018/09/15 07:40:26 UTC
[GitHub] WillemJiang closed pull request #62: move isolate-relationship to
general-development
WillemJiang closed pull request #62: move isolate-relationship to general-development
URL: https://github.com/apache/incubator-servicecomb-docs/pull/62
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/java-chassis-reference/en_US/SUMMARY.md b/java-chassis-reference/en_US/SUMMARY.md
index 3d72c84..eee5107 100644
--- a/java-chassis-reference/en_US/SUMMARY.md
+++ b/java-chassis-reference/en_US/SUMMARY.md
@@ -28,7 +28,6 @@
* [Highway RPC Protocol](build-provider/protocol/highway-rpc.md)
* [Communicate using HTTP2](build-provider/protocol/http2.md)
* [Boot-up Process](build-provider/bootup.md)
- * [Logical isolation between microservice instances](build-provider/definition/isolate-relationship.md)
* [Access Log Configuration](build-provider/access-log-configuration.md)
* [Writing Service Consumer](catalog/build-consumer.md)
* [Using Rest Template](build-consumer/using-resttemplate.md)
@@ -61,6 +60,7 @@
* [Get fuse and instance isolation alarm event information](general-development/AlarmEvent.md)
* [Shutdown gracefully](general-development/shutdown.md)
* [Handling exceptions](general-development/error-handling.md)
+ * [Multi-environment isolation between microservice instances](general-development/multienvironment.md)
* [Service Capability Open](edge/open-service.md)
* [Using Edge Service](edge/by-servicecomb-sdk.md)
* [Using confd and Nginx as edge services](edge/nginx.md)
diff --git a/java-chassis-reference/en_US/assets/isolation/app.png b/java-chassis-reference/en_US/assets/isolation/app.png
new file mode 100644
index 0000000..297118b
Binary files /dev/null and b/java-chassis-reference/en_US/assets/isolation/app.png differ
diff --git a/java-chassis-reference/en_US/assets/isolation/architecture.png b/java-chassis-reference/en_US/assets/isolation/architecture.png
new file mode 100644
index 0000000..6b8ed05
Binary files /dev/null and b/java-chassis-reference/en_US/assets/isolation/architecture.png differ
diff --git a/java-chassis-reference/en_US/assets/isolation/datacenter.png b/java-chassis-reference/en_US/assets/isolation/datacenter.png
new file mode 100644
index 0000000..017d1dc
Binary files /dev/null and b/java-chassis-reference/en_US/assets/isolation/datacenter.png differ
diff --git a/java-chassis-reference/en_US/assets/isolation/environment.png b/java-chassis-reference/en_US/assets/isolation/environment.png
new file mode 100644
index 0000000..c7fafed
Binary files /dev/null and b/java-chassis-reference/en_US/assets/isolation/environment.png differ
diff --git a/java-chassis-reference/en_US/assets/sc-meta.png b/java-chassis-reference/en_US/assets/sc-meta.png
deleted file mode 100644
index d8ffa84..0000000
Binary files a/java-chassis-reference/en_US/assets/sc-meta.png and /dev/null differ
diff --git a/java-chassis-reference/en_US/build-provider/definition/isolate-relationship.md b/java-chassis-reference/en_US/build-provider/definition/isolate-relationship.md
deleted file mode 100644
index bdffd36..0000000
--- a/java-chassis-reference/en_US/build-provider/definition/isolate-relationship.md
+++ /dev/null
@@ -1,49 +0,0 @@
-## Scene Description
-
-When doing service discovery, developers need to understand that the microservice can discover instances of those other services. ServiceComb provides hierarchical instance isolation.
-
-# Microservices instance hierarchical management
-
-To understand the isolation level between instances, you first need to understand a well-established microservice system structure defined by ServiceComb:
-
-
-
-In the microservice system structure, the top layer is the “project”, which is divided into multiple tenants under the project. The tenant contains multiple applications, and each application contains multiple environments, that is, the test and production environments can be separated.
-In a particular environment of a particular application, there are multiple microservices, and one microservice can have multiple versions at the same time.
-The above is the scope of all static metadata. A specific version of a particular service contains multiple microservice instances registered at runtime, because the information of the service instance is dynamic at runtime because of system scaling, failure, etc. The change, so the routing information of the service instance is again dynamic data.
-By hierarchically managing these data for microservices, this is natural to achieve logical isolation between instances.
-# isolation level description
-
-ServiceComb supports custom hierarchical configuration to meet the hierarchical management requirements of users. The following is the specific configuration instructions.
-
-* Application ID
-
-Defined by APPLICATIOIN\_ID, the default value is 'default'. When a microservice discovers an instance, it can only be discovered by consumers under the same APPLICATIOIN\_ID by default.
-
-* Domain name
-
-Defined by servicecomb.config.client.domainName, the default value is 'default'. As a micro service provider, it is used to indicate the tenant information that it belongs to. When a microservice finds an instance, it can only be discovered by consumers under the same tenant.
-
-* Data Center Information
-
-The data center consists of three attributes: servicecomb.datacenter.name, servicecomb.datacenter.region, servicecomb.datacenter.availableZone. Data center information does not provide isolation capabilities, and microservices can discover instances of other data centers. However, you can prioritize sending messages to a specified zone or zone by enabling instance affinity:
-
-```
-servicecomb:
- datacenter:
- name: mydatacenter
- region: my-Region
- availableZone: my-Zone
-```
-
-After this configuration, when the client routes, it will forward the request to the same instance with the same zone/region. Then, if the instances with the same region but different zones are different, select one according to the routing rule. Affinity is not logical isolation. As long as the network between the instances is connected, it is possible to access it; if the network is unreachable, the access will fail.
-
-* Environmental information
-
-It is configured in the yaml file by 'service\_description.environment'. It is also supported by the environment variable 'SERVICECOMB\_ENV'. It only supports the following enumeration : 'development', 'testing', 'acceptance', 'production'. The default value is ""\(empty\). When a microservice discovers an instance, it can only be discovered by consumers under the same environment by default.
-
-```
-service_description:
- environment: production
-```
-
diff --git a/java-chassis-reference/en_US/general-development/multienvironment.md b/java-chassis-reference/en_US/general-development/multienvironment.md
new file mode 100644
index 0000000..0741e23
--- /dev/null
+++ b/java-chassis-reference/en_US/general-development/multienvironment.md
@@ -0,0 +1,100 @@
+# Multi-environment isolation between microservice instances
+
+When doing service discovery, developers need to understand that the microservice can discover instances of those other services. ServiceComb provides hierarchical instance isolation.
+
+# Microservices instance hierarchical management
+
+To understand the isolation level between instances, you first need to understand a well-established microservice system structure defined by ServiceComb:
+
+
+
+In the microservice system structure, the top layer is the “project”, which is divided into multiple tenants under the project. The tenant contains multiple applications, and each application contains multiple environments, that is, the test and production environments can be separated. In a particular environment of a particular application, there are multiple microservices, and one microservice can have multiple versions at the same time. The above is the scope of all static metadata. A specific version of a particular service contains multiple microservice instances registered at runtime, because the information of the service instance is dynamic at runtime because of system scaling, failure, etc. The change, so the routing information of the service instance is again dynamic data. By hierarchically managing these data for microservices, this is natural to achieve logical isolation between instances.
+* Project corresponds to the project created under each region of Huawei cloud. Different projects are isolated from each other. If there is no new project under the region, it represents the region; for example, create a project named tianjing in North China (cn-north-1), if you want to register the microservice to the project, you can configure it in the microservice.yaml file：
+```yaml
+ servicecomb:
+ credentials:
+ project: cn-north-1_tianjing
+```
+* Environment indicates the current environment of the microservice instance. You can configure the current instance environment through service_description.environment in the microservice.yaml file.
+
+* Application represents a logical entity of a software application, representing a computer software application that has a business function presented to the user. The application name can be configured in the microservice.yaml file via the APPLICATION_ID.
+
+* Service is a description of the functional objects that are accessed on demand. There are multiple services under one application, and each service calls each other. The service name can be specified in the microservice.yaml file by service_description.name.
+
+* Version indicates the current service version. There may be multiple versions under one service. The current microservice version can be configured in the microservice.yaml file through service_description.version. When the consumer accesses, the default access is based on the routing rule, which can set by servicecomb.references.[providerName].version-rule in consumer.
+
+# Typical scene
+## Inter-application isolation and cross-application calls
+### Function introduction
+In the ServiceComb framework, an application contains multiple microservices.
+The same microservice instance can be deployed as a public service to multiple applications by specifying a different APPLICATION_ID.
+
+
+
+Different microservice instances, by default, are only allowed to call each other in the same application. When users need to call microservices between different applications, they need to enable cross-application calling.
+### Configuration instructions:
+1. To enable cross-application calls, you first need to enable cross-application call configuration in the microservice.yaml file on the provider side. The configuration items are as follows:
+```yaml
+ service_description:
+ properties:
+ allowCrossApp: true
+```
+2. When the Consumer side specifies the microservice name to call the provider, it needs to add the application ID to which the provider belongs. The format changes from [microserviceName] to [appID]:[microserviceName].
+
+### Code example:
+Assume that the application to which the consumer belongs is helloApp, the application to which the provider belongs is hellApp2, and the name of the microservice is helloProvider.
+* RestTemplate call mode
+When the consumer side develops the microservice consumer in the RestTemplate mode, you need to change [microserviceName] to [appID]:[microserviceName] in the called URL, as follows:
+```java
+RestTemplate restTemplate = RestTemplateBuilder.create();
+ResponseEntity<String> responseEntity = restTemplate.getForEntity(“cse://helloApp2:helloProvider/hello/sayHello?name={name}”, String.class, “ServiceComb”);
+```
+* RPC call mode
+When the consumer side develops a microservice consumer in RPC mode, the declared service provider proxy is as follows:
+```java
+@RpcReference(schemaId = “hello”, microserviceName = “helloApp2:helloProvider”)
+private Hello hello;
+```
+Cross-application calls are the same as calling microservices under the same application:
+```java
+hello.sayHello(“ServiceComb”);
+```
+
+# Typical scene
+## Development environment is isolated and rapidly developed
+### Function introduction
+By setting the environment, the ServiceComb framework can mark microservice instances as development, testing, acceptance, and production environments, and achieve natural isolation at the instance level. When the client looks for a server instance, it can only find server instance under the same environment.
+
+
+
+ServiceComb is strictly dependent on the contract when designing, so under normal circumstances, the contract has changed, you must modify the version of the microservice. However, if current is still development mode, then modify the interface is a very normal situation, when the modification is completed and the current service is started again, the newly generated contract and the old contract saved on the Service Center will conflict and report an error, causing the startup to fail, It is obviously unfriendly to developers by modifying the microservice version number or by deleting the cached data of the service on the Service Center each time.
+The ServiceComb framework supports rapid debugging of microservices in the development state by configuring the environment as development. When the interface is modified (the schema has changed), restart can be registered to the service center without modifying the version number.
+But if a consumer has already called the service before the restart, then the consumer side needs to be restarted to get the schema of the latest provider; for example, A->B, the B interface has been modified and restarted, then A is still using B's previous schema, The call may be in error. to avoid an unknown exception and A needs to be restarted.
+### Configuration instructions:
+Only the following enumerated values are supported: development, testing, acceptance, production. If not configured, the default value is "" (empty).
+* Method 1: Set by the JVM startup parameter -Dservice_description.environment=development (enumeration value);
+* Method 2: Specify by microservice.yaml configuration file:
+```yaml
+ service_description:
+ environment: development
+```
+* Method 3: Specify by environment variable SERVICECOMB_ENV (only for windows system), if it is development state, its value is configured as development;
+
+# Typical scene
+## Three centers in two places
+### Function introduction
+In the scenario of deploying services across regions in a three centers in two places solution, the same services exists in multiple availableZones. It is necessary to implement the application in the same AZ with priority. If there is a problem with the same AZ, it must be able to access another AZ. To ensure the reliability of the service.
+ServiceComb provides data center configuration to partition and manage microservices. The data center contains three attributes: servicecomb.datacenter.name, servicecomb.datacenter.region, servicecomb.datacenter.availableZone, data center information does not provide isolation capabilities, and microservices can discover instances of other data centers. However, you can prioritize sending messages to a specified zone or zone by enabling instance affinity.
+
+
+
+When the client is routing, the request will be forwarded to the instance with the same zone/region, and then the instance with the same region but different zones. When they are all different, select one according to the routing rules. Affinity is not logical isolation. As long as the network between the instances is interconnected, it is possible to access it; if the network is unreachable, the access will fail.
+When the cloud is deployed on the Huawei cloud, the values of the region and the availableZone can be associated with the Huawei cloud region (for example, cn-north-1) and the available region. However, because the different regions on the Huawei cloud do not communicate with each other, the network is not interconnected, so it does not support cross-region access; in addition to the region value corresponding to Huawei cloud, you can also define other values by yourself, and adjust accordingly according to the actual situation, which is very flexible.
+### Configuration instructions:
+```yaml
+servicecomb:
+ datacenter:
+ name: mydatacenter
+ region: my-Region
+ availableZone: my-Zone
+```
diff --git a/java-chassis-reference/zh_CN/SUMMARY.md b/java-chassis-reference/zh_CN/SUMMARY.md
index eac2340..20684ae 100644
--- a/java-chassis-reference/zh_CN/SUMMARY.md
+++ b/java-chassis-reference/zh_CN/SUMMARY.md
@@ -28,7 +28,6 @@
* [Highway RPC协议](build-provider/protocol/highway-rpc.md)
* [使用HTTP2通信](build-provider/protocol/http2.md)
* [程序启动逻辑](build-provider/bootup.md)
- * [微服务实例之间的逻辑隔离关系](build-provider/definition/isolate-relationship.md)
* [Access Log配置](build-provider/access-log-configuration.md)
* [开发服务消费者](catalog/build-consumer.md)
* [使用RestTemplate开发服务消费者](build-consumer/using-resttemplate.md)
@@ -61,6 +60,7 @@
* [获取熔断与实例隔离告警事件信息](general-development/AlarmEvent.md)
* [优雅停机](general-development/shutdown.md)
* [异常处理](general-development/error-handling.md)
+ * [微服务实例间多环境隔离](general-development/multienvironment.md)
* [服务能力开放](edge/open-service.md)
* [使用Edge Service做边缘服务](edge/by-servicecomb-sdk.md)
* [使用confd和Nginx做边缘服务](edge/nginx.md)
diff --git a/java-chassis-reference/zh_CN/assets/isolation/app.png b/java-chassis-reference/zh_CN/assets/isolation/app.png
new file mode 100644
index 0000000..297118b
Binary files /dev/null and b/java-chassis-reference/zh_CN/assets/isolation/app.png differ
diff --git a/java-chassis-reference/zh_CN/assets/isolation/architecture.png b/java-chassis-reference/zh_CN/assets/isolation/architecture.png
new file mode 100644
index 0000000..6b8ed05
Binary files /dev/null and b/java-chassis-reference/zh_CN/assets/isolation/architecture.png differ
diff --git a/java-chassis-reference/zh_CN/assets/isolation/datacenter.png b/java-chassis-reference/zh_CN/assets/isolation/datacenter.png
new file mode 100644
index 0000000..017d1dc
Binary files /dev/null and b/java-chassis-reference/zh_CN/assets/isolation/datacenter.png differ
diff --git a/java-chassis-reference/zh_CN/assets/isolation/environment.png b/java-chassis-reference/zh_CN/assets/isolation/environment.png
new file mode 100644
index 0000000..c7fafed
Binary files /dev/null and b/java-chassis-reference/zh_CN/assets/isolation/environment.png differ
diff --git a/java-chassis-reference/zh_CN/assets/sc-meta.png b/java-chassis-reference/zh_CN/assets/sc-meta.png
deleted file mode 100644
index d8ffa84..0000000
Binary files a/java-chassis-reference/zh_CN/assets/sc-meta.png and /dev/null differ
diff --git a/java-chassis-reference/zh_CN/build-provider/definition/isolate-relationship.md b/java-chassis-reference/zh_CN/build-provider/definition/isolate-relationship.md
deleted file mode 100644
index 375bfca..0000000
--- a/java-chassis-reference/zh_CN/build-provider/definition/isolate-relationship.md
+++ /dev/null
@@ -1,47 +0,0 @@
-## 场景描述
-
-进行服务发现的时候，开发者需要了解本微服务能够发现那些其他服务的实例。ServiceComb提供了分层次的实例隔离。
-
-# 微服务实例分层管理
-
-要了解实例间的隔离层次，首先需要了解ServiceComb定义的一个体系完备的微服务系统结构：
-
-
-
-在微服务系统结构中，顶层是“项目”，在项目下分为多个租户，租户中包含多个应用，而每个应用又包含多个环境，即测试和生产环境可以分开。在某个特定应用的特定环境中，包含多个微服务，而一个微服务又可以同时存在多个版本。以上，是所有静态元数据的范畴，某个特定服务的特定版本则包含多个在运行时注册上来的微服务实例，因为服务实例的信息在运行时随着系统的伸缩、故障等原因是动态变化的，所以服务实例的路由信息又为动态数据。通过分层管理微服务的这些数据，也就自然而然的实现了实例之间的逻辑隔离。
-
-# 隔离层次说明
-
-ServiceComb支持自定义分层配置，满足用户的实例分层管理需求，以下是具体配置说明。
-
-* 应用ID
-
-通过APPLICATIOIN\_ID来定义，缺省值为default。微服务在发现实例的时候，缺省只能够被相同APPLICATIOIN\_ID下的消费者发现。
-
-* Domain名称
-
-通过servicecomb.config.client.domainName来定义，缺省值为default。作为微服务提供者，用于表明自身所属租户信息。微服务在发现实例的时候，只能被相同租户下的消费者发现。
-
-* 数据中心信息
-
-数据中心包括3个属性：servicecomb.datacenter.name， servicecomb.datacenter.region, servicecomb.datacenter.availableZone。数据中心信息不提供隔离能力，微服务可以发现其他数据中心的实例。但是可以通过启用实例亲和性，来优先往指定的区域或者Zone发消息：
-
-```
-servicecomb:
- datacenter:
- name: mydatacenter
- region: my-Region
- availableZone: my-Zone
-```
-
-这样配置后，客户端在路由的时候，会优先将请求转发到zone/region都相同的实例，然后是region相同，但zone不相同的实例，都不相同的时候，则按照路由规则选择一个。亲和性不是逻辑隔离，只要实例之间网络是联通的，那么都有可能访问到；如果网络不通，则会访问失败。
-
-* 环境信息
-
-在yaml文件里通过service\_description.environment来配置，同时支持通过环境变量SERVICECOMB\_ENV配置，仅支持以下枚举值 development,testing,acceptance,production，缺省值为""\(空\)。微服务在发现实例的时候，缺省只能够被相同environment下的消费者发现。
-
-```
-service_description:
- environment: production
-```
-
diff --git a/java-chassis-reference/zh_CN/general-development/multienvironment.md b/java-chassis-reference/zh_CN/general-development/multienvironment.md
new file mode 100644
index 0000000..4860d52
--- /dev/null
+++ b/java-chassis-reference/zh_CN/general-development/multienvironment.md
@@ -0,0 +1,101 @@
+# 微服务实例间多环境隔离
+
+进行服务发现的时候，开发者需要了解本微服务能够发现那些其他服务的实例。ServiceComb提供了分层次的实例隔离。
+
+# 微服务实例分层管理
+
+要了解实例间的隔离层次，首先需要了解ServiceComb定义的一个体系完备的微服务系统结构：
+
+
+
+在微服务系统结构中，顶层是项目（project），项目中的应用分属于不同环境（environment），即测试和生产环境可以分开，每个环境下包含多个应用（application），在某个特定应用的特定环境中，包含多个微服务（service），一个微服务又可以同时存在多个版本（version）。
+以上，是所有静态元数据的范畴，某个特定服务的特定版本则包含多个在运行时注册上来的微服务实例，因为服务实例的信息在运行时随着系统的伸缩、故障等原因是动态变化的，所以服务实例的路由信息又为动态数据。通过分层管理微服务的这些数据，也就自然而然地实现了实例之间的逻辑隔离。
+* Project对应到华为云上各region下创建的project，不同的project互相隔离，如果该region下没有新建project，则代表该region；例如，在华北区（cn-north-1）下创建一个名字为tianjing的project，若想微服务注册到该project下，可以在microservice.yaml文件里配置：
+```yaml
+ servicecomb:
+ credentials:
+ project: cn-north-1_tianjing
+```
+* Environment表示当前微服务实例所属环境，可在microservice.yaml文件里通过service_description.environment配置当前实例环境。
+
+* Application代表一个软件应用的逻辑实体，表示一个有业务功能呈现给用户的计算机软件应用，可在microservice.yaml文件里通过APPLICATION_ID配置应用名。
+
+* Service是对按需取用的功能对象的一种描述，一个应用下存在多个服务，各服务间相互调用，可在microservice.yaml文件里通过service_description.name指定服务名。
+
+* Version表示当前服务的版本，一个服务下可存在多个版本，可在microservice.yaml文件里通过service_description.version配置当前微服务版本号；消费端进行访问时，默认按照路由规则进行访问，可以在消费端通过servicecomb.references.[providerName].version-rule设置版本规则。
+
+# 典型场景
+## 应用间隔离及跨应用调用
+### 功能介绍
+在ServiceComb框架中，一个应用下包含多个微服务。
+同一个微服务实例，可以作为公共服务部署到多个应用，通过指定不同的APPLICATION_ID来实现。
+
+
+
+不同的微服务实例，默认情况下，只允许在同一个应用里相互调用，当用户需要不同应用间的微服务相互调用时，就需要开启跨应用调用功能。
+### 配置说明：
+1. 若要开启跨应用调用，首先需在provider端的microservice.yaml文件开启跨应用调用配置。配置项如下：
+```yaml
+ service_description:
+ properties:
+ allowCrossApp: true
+```
+2. Consumer端指定微服务名称调用provider的时候，需要加上provider所属的应用ID，格式由[microserviceName]变为[appID]:[microserviceName]。
+
+### 代码示例：
+假设consumer所属应用为helloApp，provider所属应用为hellApp2，微服务名称为helloProvider。
+* RestTemplate调用方式
+当consumer端以RestTemplate方式开发微服务消费者时，需要在调用的URL中将[microserviceName]改为[appID]:[microserviceName]，如下：
+```java
+RestTemplate restTemplate = RestTemplateBuilder.create();
+ResponseEntity<String> responseEntity = restTemplate.getForEntity(“cse://helloApp2:helloProvider/hello/sayHello?name={name}”, String.class, “ServiceComb”);
+```
+* RPC调用方式
+当consumer端以RPC方式开发微服务消费者时，声明的服务提供者代理如下：
+```java
+@RpcReference(schemaId = “hello”, microserviceName = “helloApp2:helloProvider”)
+private Hello hello;
+```
+跨应用调用与同应用下调用微服务的方式相同：
+```java
+hello.sayHello(“ServiceComb”);
+```
+
+# 典型场景
+## 开发环境互相隔离及快速开发
+### 功能介绍
+ServiceComb框架通过设置environment，可以将微服务实例标记为开发、测试、预生产、生产环境，实现了在实例级别的天然隔离；客户端在查找服务端实例的时候，只能发现相同environment下的服务端实例。
+
+
+
+ServiceComb在设计时，严格依赖于契约，所以正常情况下契约变了，就必须要修改微服务的版本。但是如果当前还是开发模式，那么修改接口就是很正常的情况，当修改完毕再次启动当前服务时，新生成的契约和Service Center上保存的旧契约会冲突并报错，导致启动失败，如果每次都通过修改微服务版本号，或者删除该服务在Service Center上的缓存数据来解决，显然对开发人员很不友好。
+ServiceComb框架支持在开发态进行微服务的快速调试，通过将environment配置为development即可。当接口修改了（Schema发生了变化），重启就可以正常注册到服务中心，而不用修改版本号。
+但是如果有consumer已经调用了重启之前的服务，那么consumer端也需要重启才能获取最新provider的schema；比如A->B，B接口进行了修改并且重启，那么A这个时候还是使用B之前的schema，调用可能会出错，以免出现未知异常，A也需要重启。
+### 配置说明：
+仅支持以下枚举值：development,testing,acceptance,production，不配置的情况下缺省值为""（空）。
+* 方法1：通过JVM启动参数-Dservice_description.environment=development（枚举值）进行设置；
+* 方法2：通过microservice.yaml配置文件来指定：
+```yaml
+ service_description:
+ environment: development
+```
+* 方法3：通过环境变量SERVICECOMB_ENV来指定（仅限于windows系统），若是开发态，其值配置为development；
+
+# 典型场景
+## 两地三中心
+### 功能介绍
+在以两地三中心的解决方案进行跨地区部署服务的场景，同一套服务存在于多个availableZone中，需要实现优先调用同一个AZ内的应用，若本AZ出现问题，要能够访问另一个AZ下的应用，从而保证服务的可靠性。
+ServiceComb提供了数据中心配置，来实现对微服务的分区和管理。数据中心包含3个属性：servicecomb.datacenter.name, servicecomb.datacenter.region, servicecomb.datacenter.availableZone，数据中心信息不提供隔离能力，微服务可以发现其他数据中心的实例。但是可以通过启用实例亲和性，来优先往指定的区域或者Zone发消息。
+
+
+
+客户端在路由的时候，会优先将请求转发到zone/region都相同的实例，然后是region相同，但zone不相同的实例，都不相同的时候，则按照路由规则选择一个。亲和性不是逻辑隔离，只要实例之间网络是联通的，那么都有可能访问到；如果网络不通，则会访问失败。
+在华为云上部署时，可将region和availableZone的值与华为云的region（例如：cn-north-1）和可用区对应起来，但是因为华为云上的不同region目前网络不互通，所以此时不支持跨region访问；除了对应华为云的region值，也可以自行定义其他值，根据实际情况作相应调整，非常灵活。
+### 配置说明：
+```yaml
+servicecomb:
+ datacenter:
+ name: mydatacenter
+ region: my-Region
+ availableZone: my-Zone
+```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services