{"action":"created","issue":{"url":"https://api.github.com/repos/Netflix/eureka/issues/502","labels_url":"https://api.github.com/repos/Netflix/eureka/issues/502/labels{/name}","comments_url":"https://api.github.com/repos/Netflix/eureka/issues/502/comments","events_url":"https://api.github.com/repos/Netflix/eureka/issues/502/events","html_url":"https://github.com/Netflix/eureka/issues/502","id":72279991,"number":502,"title":"2.x Named Eureka Server Groups","user":{"login":"qiangdavidliu","id":6243760,"avatar_url":"https://avatars.githubusercontent.com/u/6243760?v=3","gravatar_id":"","url":"https://api.github.com/users/qiangdavidliu","html_url":"https://github.com/qiangdavidliu","followers_url":"https://api.github.com/users/qiangdavidliu/followers","following_url":"https://api.github.com/users/qiangdavidliu/following{/other_user}","gists_url":"https://api.github.com/users/qiangdavidliu/gists{/gist_id}","starred_url":"https://api.github.com/users/qiangdavidliu/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/qiangdavidliu/subscriptions","organizations_url":"https://api.github.com/users/qiangdavidliu/orgs","repos_url":"https://api.github.com/users/qiangdavidliu/repos","events_url":"https://api.github.com/users/qiangdavidliu/events{/privacy}","received_events_url":"https://api.github.com/users/qiangdavidliu/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/Netflix/eureka/labels/2.x","name":"2.x","color":"bfd4f2"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-04-30T21:02:25Z","updated_at":"2015-05-01T16:41:54Z","closed_at":null,"body":"## Problem To Solve\r\nEureka2 write is designed so that a full network can be partitioned into several eureka2 sub-networks, where each sub-network contains an eureka2 write cluster taking registrations from all instances from their sub-network. One example of such a setup is deployment in AWS's regional model, where an eureka2 write cluster need to exist per region to service registrations from all instances in that region.\r\n\r\nIn normal cases an eureka2 read cluster that exist in sub-network A (e.g. us-east-1) only need to connect to it's local write cluster for interest information. However there are cases where read clusters may need to (in addition to the local write cluster) also connect to one or more remote write clusters for informations, and/or to one or more remote read clusters for information (since interest subscriptions can be served from write or read servers analogously).\r\n\r\nPer the above, for interest subscription, read clusters should not really care about whether it is connecting to a write cluster or a read cluster, or whether it is connecting to a local cluster or a remote cluster. Rather it needs to have some way to specify a set of source \"clusters\" that are available to provide interest data to this read cluster.\r\n\r\n## Named clusters and multiplexing read servers\r\nA proposal to the above problem is to define global unique names for each cluster (write and read), which can then be shared at bootstrap time for a new read cluster as sources of data.\r\n\r\n**(Read) Server Side**\r\nWhen a read server boots up, it will load configuration that specifies all it's known data sources, and for each data source associate an EurekaRegistry and EurekaInterestClient. All the individual named registries will then be proxied by a registry that understands names and can route interest subscriptions to specific registries. The read server need at least one data source defined that is used as the default data source for this read server.\r\n\r\n**Configuration example**\r\n<pre>\r\neureka.interest.dataSource.names=[write-useast1, read-uswest2]  // first one defined in the list is the default\r\n\r\neureka.interest.dataSource.write-useast1.resolverType=dns\r\neureka.interest.dataSource.write-useast1.serverList=[dnsName:interestPort]\r\neureka.interest.dataSource.write-useast1.lazyLoad=false\r\n\r\neureka.interest.dataSource.read-uswest2.resolverType=eureka\r\neureka.interest.dataSource.read-uswest2.serverList=[dnsName:interestPort for west2 write cluster]\r\neureka.interest.dataSource.read-uswest2.lazyLoad=true\r\n</pre>\r\n\r\n**Client Side**\r\nWhen an eureka2 client communicates with a read server for interest subscription, it can optionally specify a dataSource as well. When the interest subscription is received by the read server, it will attempt to route the interest subscription to the correct registry for the specified dataSource. If no dataSource is specified, the default dataSource is used.\r\n\r\n**Client API Change**\r\nExtend Interest to be able to optionally specify a source.\r\n```java\r\npublic abstract class Interest<T> {\r\n\r\n    public enum Operator {Equals, Like}\r\n    private final String sourceName;\r\n\r\n    protected Interest() {\r\n        this(null);\r\n    }\r\n\r\n    protected Interest(String sourceName) {\r\n        this.sourceName = sourceName;\r\n    }\r\n\r\n    public abstract boolean matches(T data);\r\n}\r\n```\r\nThe Interests DSL will need to change to accomodate optionally specifying a dataSource, for example\r\n```java\r\npublic final class Interests {\r\n    public static class InterestsWithSource {\r\n        private final String sourceName;\r\n\r\n        InterestsWithSource(String sourceName) {\r\n            this.sourceName = sourceName;\r\n        }\r\n\r\n        // contain all static methods in Interests.java as instance methods, but obeys sourceName\r\n    }\r\n\r\n    private static final InterestsWithSource WITH_DEFAULT_SOURCE = new InterestsWithSource(null);\r\n    \r\n    // change all static methods to reference WITH_DEFAULT_SOURCE's equivalent methods.\r\n    \r\n    public InterestsWithSource fromDataSource(String sourceName) {\r\n        return new InterestsWithSource(sourceName);\r\n    }\r\n}\r\n```\r\n\r\nUsage would be\r\n```java\r\nInterest interest = Interests.forVip(\"someVip\");  // use default source\r\nInterest interestFromAnotherSource = Interests.fromDataSource(\"someSource\").forVip(\"someVip\");\r\n```\r\n"},"comment":{"url":"https://api.github.com/repos/Netflix/eureka/issues/comments/98174776","html_url":"https://github.com/Netflix/eureka/issues/502#issuecomment-98174776","issue_url":"https://api.github.com/repos/Netflix/eureka/issues/502","id":98174776,"user":{"login":"NiteshKant","id":820005,"avatar_url":"https://avatars.githubusercontent.com/u/820005?v=3","gravatar_id":"","url":"https://api.github.com/users/NiteshKant","html_url":"https://github.com/NiteshKant","followers_url":"https://api.github.com/users/NiteshKant/followers","following_url":"https://api.github.com/users/NiteshKant/following{/other_user}","gists_url":"https://api.github.com/users/NiteshKant/gists{/gist_id}","starred_url":"https://api.github.com/users/NiteshKant/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/NiteshKant/subscriptions","organizations_url":"https://api.github.com/users/NiteshKant/orgs","repos_url":"https://api.github.com/users/NiteshKant/repos","events_url":"https://api.github.com/users/NiteshKant/events{/privacy}","received_events_url":"https://api.github.com/users/NiteshKant/received_events","type":"User","site_admin":false},"created_at":"2015-05-01T16:41:54Z","updated_at":"2015-05-01T16:41:54Z","body":"@tbak I am just questioning the change in the client via introduction of data sources. \r\n\r\nMultiple server groups inside the _same_ client does not sound the correct abstraction to me. I see the following usecases:\r\n\r\n- Read server configured to read from multiple regions: This is a server level configuration and the decision to use which client should be split at the time of query for an interest, choosing an appropriate client for the query. This does not require introducing the data source concept at the client level.\r\n- Users querying for cross-region data. This should be an attribute of the interest and should not need any configuration on the client. I do not think \"datasource\" is the correct terminology for this. We should be explicit that it is a cross-region query, something like `Interests.forVip(\"vip\").inRegion(\"us-east-1\")`. In this case it will be an out-of-band understanding for the user that whether the application is running in an environment which supports cross-region queries. If not, the interest should error out.\r\n\r\nI can see from where the proposal is coming i.e. to generalize the implementation in the server to be available for all clients but I think the usage is pretty different for an end user vis-a-vis a eureka server."}}