進行服務發現的時候，開發者需要了解本微服務能夠發現那些其他服務的實例。ServiceComb提供了分層次的實例隔離。
微服務實例分層管理
要了解實例間的隔離層次，首先需要了解ServiceComb定義的一個體系完備的微服務系統結構：
在微服務系統結構中，頂層是項目（project），項目中的應用分屬於不同環境（environment），即測試和生產環境可以分開，每個環境下包含多個應用（application），在某個特定應用的特定環境中，包含多個微服務（service），一個微服務又可以同時存在多個版本（version）。
以上，是所有靜態元數據的範疇，某個特定服務的特定版本則包含多個在運行時註冊上來的微服務實例，因爲服務實例的信息在運行時隨着系統的伸縮、故障等原因是動態變化的，所以服務實例的路由信息又爲動態數據。通過分層管理微服務的這些數據，也就自然而然地實現了實例之間的邏輯隔離。 * Project對應到華爲雲上各region下創建的project，不同的project互相隔離，如果該region下沒有新建project，則代表該region；例如，在華北區（cn-north-1）下創建一個名字爲tianjing的project，若想微服務註冊到該project下，可以在microservice.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來實現。
不同的微服務實例，默認情況下，只允許在同一個應用裏相互調用，當用戶需要不同應用間的微服務相互調用時，就需要開啓跨應用調用功能。
配置說明：
- 若要開啓跨應用調用，首先需在provider端的microservice.yaml文件開啓跨應用調用配置。配置項如下：
service_description:
properties:
allowCrossApp: true
- Consumer端指定微服務名稱調用provider的時候，需要加上provider所屬的應用ID，格式由[microserviceName]變爲[appID]:[microserviceName]。
代碼示例：
假設consumer所屬應用爲helloApp，provider所屬應用爲hellApp2，微服務名稱爲helloProvider。
* RestTemplate調用方式
當consumer端以RestTemplate方式開發微服務消費者時，需要在調用的URL中將[microserviceName]改爲[appID]:[microserviceName]，如下：
RestTemplate restTemplate = RestTemplateBuilder.create();
ResponseEntity<String> responseEntity = restTemplate.getForEntity(“cse://helloApp2:helloProvider/hello/sayHello?name={name}”, String.class, “ServiceComb”);
- RPC調用方式
當consumer端以RPC方式開發微服務消費者時，聲明的服務提供者代理如下：
@RpcReference(schemaId = “hello”, microserviceName = “helloApp2:helloProvider”)
private Hello hello;
跨應用調用與同應用下調用微服務的方式相同：
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配置文件來指定：
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值，也可以自行定義其他值，根據實際情況作相應調整，非常靈活。
配置說明：
servicecomb:
datacenter:
name: mydatacenter
region: my-Region
availableZone: my-Zone