Nacos服务发现与配置管理

// Generated by the protocol buffer compiler. DO NOT EDIT! // source: networking/v1alpha3/virtual_service.proto package istio.networking.v1alpha3; public final class VirtualServiceOuterClass { private VirtualServiceOuterClass() {} public static void registerAllExtensions( com.google.protobuf.ExtensionRegistryLite registry) { } public static void registerAllExtensions( com.google.protobuf.ExtensionRegistry registry) { registerAllExtensions( (com.google.protobuf.ExtensionRegistryLite) registry); } public interface VirtualServiceOrBuilder extends // @@protoc_insertion_point(interface_extends:istio.networking.v1alpha3.VirtualService) com.google.protobuf.MessageOrBuilder { /** * <pre> * The destination hosts to which traffic is being sent. Could * be a DNS name with wildcard prefix or an IP address. Depending on the * platform, short-names can also be used instead of a FQDN (i.e. has no * dots in the name). In such a scenario, the FQDN of the host would be * derived based on the underlying platform. * A single VirtualService can be used to describe all the traffic * properties of the corresponding hosts, including those for multiple * HTTP and TCP ports. Alternatively, the traffic properties of a host * can be defined using more than one VirtualService, with certain * caveats. Refer to the * [Operations Guide](https://istio.io/docs/ops/best-practices/traffic-management/#split-virtual-services) * for details. * *Note for Kubernetes users*: When short names are used (e.g. "reviews" * instead of "reviews.default.svc.cluster.local"), Istio will interpret * the short name based on the namespace of the rule, not the service. A * rule in the "default" namespace containing a host "reviews" will be * interpreted as "reviews.default.svc.cluster.local", irrespective of * the actual namespace associated with the reviews service. _To avoid * potential misconfigurations, it is recommended to always use fully * qualified domain names over short names._ * The hosts field applies to both HTTP and TCP services. Service inside * the mesh, i.e., those found in the service registry, must always be * referred to using their alphanumeric names. IP addresses are allowed * only for services defined via the Gateway. * *Note*: It must be empty for a delegate VirtualService. * </pre> * * <code>repeated string hosts = 1;</code> * @return A list containing the hosts. */ java.util.List<java.lang.String> getHostsList(); /** * <pre> * The destination hosts to which traffic is being sent. Could * be a DNS name with wildcard prefix or an IP address. Depending on the * platform, short-names can also be used instead of a FQDN (i.e. has no * dots in the name). In such a scenario, the FQDN of the host would be * derived based on the underlying platform. * A single VirtualService can be used to describe all the traffic * properties of the corresponding hosts, including those for multiple * HTTP and TCP ports. Alternatively, the traffic properties of a host * can be defined using more than one VirtualService, with certain * caveats. Refer to the * [Operations Guide](https://istio.io/docs/ops/best-practices/traffic-management/#split-virtual-services) * for details. * *Note for Kubernetes users*: When short names are used (e.g. "reviews" * instead of "reviews.default.svc.cluster.local"), Istio will interpret * the short name based on the namespace of the rule, not the service. A * rule in the "default" namespace containing a host "reviews" will be * interpreted as "reviews.default.svc.cluster.local", irrespective of * the actual namespace associated with the reviews service. _To avoid * potential misconfigurations, it is recommended to always use fully * qualified domain names over short names._ * The hosts field applies to both HTTP and TCP services. Service inside * the mesh, i.e., those found in the service registry, must always be * referred to using their alphanumeric names. IP addresses are allowed * only for services defined via the Gateway. * *Note*: It must be empty for a delegate VirtualService. * </pre> * * <code>repeated string hosts = 1;</code> * @return The count of hosts. */ int getHostsCount(); /** * <pre> * The destination hosts to which traffic is being sent. Could * be a DNS name with wildcard prefix or an IP address. Depending on the * platform, short-names can also be used instead of a FQDN (i.e. has no * dots in the name). In such a scenario, the FQDN of the host would be * derived based on the underlying platform. * A single VirtualService can be used to describe all the traffic * properties of the corresponding hosts, including those for multiple * HTTP and TCP ports. Alternatively, the traffic properties of a host * can be defined using more than one VirtualService, with certain * caveats. Refer to the * [Operations Guide](https://istio.io/docs/ops/best-practices/traffic-management/#split-virtual-services) * for details. * *Note for Kubernetes users*: When short names are used (e.g. "reviews" * instead of "reviews.default.svc.cluster.local"), Istio will interpret * the short name based on the namespace of the rule, not the service. A * rule in the "default" namespace containing a host "reviews" will be * interpreted as "reviews.default.svc.cluster.local", irrespective of * the actual namespace associated with the reviews service. _To avoid * potential misconfigurations, it is recommended to always use fully * qualified domain names over short names._ * The hosts field applies to both HTTP and TCP services. Service inside * the mesh, i.e., those found in the service registry, must always be * referred to using their alphanumeric names. IP addresses are allowed * only for services defined via the Gateway. * *Note*: It must be empty for a delegate VirtualService. * </pre> * * <code>repeated string hosts = 1;</code> * @param index The index of the element to return. * @return The hosts at the given index. */ java.lang.String getHosts(int index); /** * <pre> * The destination hosts to which traffic is being sent. Could * be a DNS name with wildcard prefix or an IP address. Depending on the * platform, short-names can also be used instead of a FQDN (i.e. has no * dots in the name). In such a scenario, the FQDN of the host would be * derived based on the underlying platform. * A single VirtualService can be used to describe all the traffic * properties of the corresponding hosts, including those for multiple * HTTP and TCP ports. Alternatively, the traffic properties of a host * can be defined using more than one VirtualService, with certain * caveats. Refer to the * [Operations Guide](https://istio.io/docs/ops/best-practices/traffic-management/#split-virtual-services) * for details. * *Note for Kubernetes users*: When short names are used (e.g. "reviews" * instead of "reviews.default.svc.cluster.local"), Istio will interpret * the short name based on the namespace of the rule, not the service. A * rule in the "default" namespace containing a host "reviews" will be * interpreted as "reviews.default.svc.cluster.local", irrespective of * the actual namespace associated with the reviews service. _To avoid * potential misconfigurations, it is recommended to always use fully * qualified domain names over short names._ * The hosts field applies to both HTTP and TCP services. Service inside * the mesh, i.e., those found