tk/Ocelot
1
0
Fork 0
mirror of https://github.com/nsnail/Ocelot.git synced 2025-06-19 00:58:15 +08:00
Code Issues Packages Projects Releases Wiki Activity

Feature/should not start if specified using service discovery but no provider registered (#584)

Browse Source 
* #580 added failing test

* #580 added failing test for dynamic reroutes

* #580 added failing test for validator

* #580 validation tests passing

* #580 acceptance tests passing

* #580 got rid of the list in sdp factory

* +semver: breaking #580 service discovery provider returned by delegate must be the same as name in config, this is a breaking change because you have to specify consul now

* #580 removed use servide discovery property from file config, we dont need it, just use the service name as indicator the user wants to use service discovery for the given reroute
This commit is contained in:
Tom Pallister
2018-08-31 18:28:43 +01:00
committed by GitHub
parent 0a7d81038e
commit 55277cac45
26 changed files with 821 additions and 255 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
docs/features/configuration.rst
View File

@ -64,7 +64,6 @@ Here is an example ReRoute configuration, You don't need to set all of these thi
"UseCookieContainer": true,
"UseTracing": true
},
"UseServiceDiscovery": false,
"DangerousAcceptAnyServerCertificateValidator": false
}

441
docs/features/loadbalancer.rst
View File

@ -1,111 +1,330 @@
Load Balancer
=============
Ocelot can load balance across available downstream services for each ReRoute. This means you can scale your downstream services and Ocelot can use them effectively.
The type of load balancer available are:
LeastConnection - tracks which services are dealing with requests and sends new requests to service with least existing requests. The algorythm state is not distributed across a cluster of Ocelot's.
RoundRobin - loops through available services and sends requests. The algorythm state is not distributed across a cluster of Ocelot's.
NoLoadBalancer - takes the first available service from config or service discovery.
CookieStickySessions - uses a cookie to stick all requests to a specific server. More info below.
You must choose in your configuration which load balancer to use.
Configuration
^^^^^^^^^^^^^
The following shows how to set up multiple downstream services for a ReRoute using ocelot.json and then select the LeastConnection load balancer. This is the simplest way to get load balancing set up.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "10.0.1.10",
"Port": 5000,
},
{
"Host": "10.0.1.11",
"Port": 5000,
}
],
"UpstreamPathTemplate": "/posts/{postId}",
"LoadBalancerOptions": {
"Type": "LeastConnection"
},
"UpstreamHttpMethod": [ "Put", "Delete" ]
}
Service Discovery
^^^^^^^^^^^^^^^^^
The following shows how to set up a ReRoute using service discovery then select the LeastConnection load balancer.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"UpstreamPathTemplate": "/posts/{postId}",
"UpstreamHttpMethod": [ "Put" ],
"ServiceName": "product",
"LoadBalancerOptions": {
"Type": "LeastConnection"
},
"UseServiceDiscovery": true
}
When this is set up Ocelot will lookup the downstream host and port from the service discover provider and load balance requests across any available services. If you add and remove services from the
service discovery provider (consul) then Ocelot should respect this and stop calling services that have been removed and start calling services that have been added.
CookieStickySessions
^^^^^^^^^^^^^^^^^^^^
I've implemented a really basic sticky session type of load balancer. The scenario it is meant to support is you have a bunch of downstream
servers that don't share session state so if you get more than one request for one of these servers then it should go to the same box each
time or the session state might be incorrect for the given user. This feature was requested in `Issue #322 <https://github.com/ThreeMammals/Ocelot/issues/322>`_
though what the user wants is more complicated than just sticky sessions :) anyway I thought this would be a nice feature to have!
In order to set up CookieStickySessions load balancer you need to do something like the following.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "10.0.1.10",
"Port": 5000,
},
{
"Host": "10.0.1.11",
"Port": 5000,
}
],
"UpstreamPathTemplate": "/posts/{postId}",
"LoadBalancerOptions": {
"Type": "CookieStickySessions",
"Key": "ASP.NET_SessionId",
"Expiry": 1800000
},
"UpstreamHttpMethod": [ "Put", "Delete" ]
}
The LoadBalancerOptions are Type this needs to be CookieStickySessions, Key this is the key of the cookie you
wish to use for the sticky sessions, Expiry this is how long in milliseconds you want to the session to be stuck for. Remember this
refreshes on every request which is meant to mimick how sessions work usually.
If you have multiple ReRoutes with the same LoadBalancerOptions then all of those ReRoutes will use the same load balancer for there
subsequent requests. This means the sessions will be stuck across ReRoutes.
Please note that if you give more than one DownstreamHostAndPort or you are using a Service Discovery provider such as Consul
and this returns more than one service then CookieStickySessions uses round robin to select the next server. This is hard coded at the
moment but could be changed.
Ocelot can load balance across available downstream services for each ReRoute. This means you can scale your downstream services and Ocelot can use them effectively.
The type of load balancer available are:
LeastConnection - tracks which services are dealing with requests and sends new requests to service with least existing requests. The algorythm state is not distributed across a cluster of Ocelot's.
RoundRobin - loops through available services and sends requests. The algorythm state is not distributed across a cluster of Ocelot's.
NoLoadBalancer - takes the first available service from config or service discovery.
CookieStickySessions - uses a cookie to stick all requests to a specific server. More info below.
You must choose in your configuration which load balancer to use.
Configuration
^^^^^^^^^^^^^
The following shows how to set up multiple downstream services for a ReRoute using ocelot.json and then select the LeadConnection load balancer. This is the simplest way to get load balancing set up.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "10.0.1.10",
"Port": 5000,
},
{
"Host": "10.0.1.11",
"Port": 5000,
}
],
"UpstreamPathTemplate": "/posts/{postId}",
"LoadBalancerOptions": {
"Type": "LeastConnection"
},
"UpstreamHttpMethod": [ "Put", "Delete" ]
}
Service Discovery
^^^^^^^^^^^^^^^^^
The following shows how to set up a ReRoute using service discovery then select the LeadConnection load balancer.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"UpstreamPathTemplate": "/posts/{postId}",
"UpstreamHttpMethod": [ "Put" ],
"ServiceName": "product",
"LoadBalancerOptions": {
"Type": "LeastConnection"
},
}
When this is set up Ocelot will lookup the downstream host and port from the service discover provider and load balance requests across any available services. If you add and remove services from the
service discovery provider (consul) then Ocelot should respect this and stop calling services that have been removed and start calling services that have been added.
CookieStickySessions
^^^^^^^^^^^^^^^^^^^^
I've implemented a really basic sticky session type of load balancer. The scenario it is meant to support is you have a bunch of downstream
servers that don't share session state so if you get more than one request for one of these servers then it should go to the same box each
time or the session state might be incorrect for the given user. This feature was requested in `Issue #322 <https://github.com/ThreeMammals/Ocelot/issues/322>`_
though what the user wants is more complicated than just sticky sessions :) anyway I thought this would be a nice feature to have!
In order to set up CookieStickySessions load balancer you need to do something like the following.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "10.0.1.10",
"Port": 5000,
},
{
"Host": "10.0.1.11",
"Port": 5000,
}
],
"UpstreamPathTemplate": "/posts/{postId}",
"LoadBalancerOptions": {
"Type": "CookieStickySessions",
"Key": "ASP.NET_SessionId",
"Expiry": 1800000
},
"UpstreamHttpMethod": [ "Put", "Delete" ]
}
The LoadBalancerOptions are Type this needs to be CookieStickySessions, Key this is the key of the cookie you
wish to use for the sticky sessions, Expiry this is how long in milliseconds you want to the session to be stuck for. Remember this
refreshes on every request which is meant to mimick how sessions work usually.
If you have multiple ReRoutes with the same LoadBalancerOptions then all of those ReRoutes will use the same load balancer for there
subsequent requests. This means the sessions will be stuck across ReRoutes.
Please note that if you give more than one DownstreamHostAndPort or you are using a Service Discovery provider such as Consul
and this returns more than one service then CookieStickySessions uses round robin to select the next server. This is hard coded at the
moment but could be changed.
||||||| merged common ancestors
Load Balancer
=============
Ocelot can load balance across available downstream services for each ReRoute. This means you can scale your downstream services and Ocelot can use them effectively.
The type of load balancer available are:
LeastConnection - tracks which services are dealing with requests and sends new requests to service with least existing requests. The algorythm state is not distributed across a cluster of Ocelot's.
RoundRobin - loops through available services and sends requests. The algorythm state is not distributed across a cluster of Ocelot's.
NoLoadBalancer - takes the first available service from config or service discovery.
CookieStickySessions - uses a cookie to stick all requests to a specific server. More info below.
You must choose in your configuration which load balancer to use.
Configuration
^^^^^^^^^^^^^
The following shows how to set up multiple downstream services for a ReRoute using ocelot.json and then select the LeadConnection load balancer. This is the simplest way to get load balancing set up.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "10.0.1.10",
"Port": 5000,
},
{
"Host": "10.0.1.11",
"Port": 5000,
}
],
"UpstreamPathTemplate": "/posts/{postId}",
"LoadBalancerOptions": {
"Type": "LeastConnection"
},
"UpstreamHttpMethod": [ "Put", "Delete" ]
}
Service Discovery
^^^^^^^^^^^^^^^^^
The following shows how to set up a ReRoute using service discovery then select the LeadConnection load balancer.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"UpstreamPathTemplate": "/posts/{postId}",
"UpstreamHttpMethod": [ "Put" ],
"ServiceName": "product",
"LoadBalancerOptions": {
"Type": "LeastConnection"
},
}
When this is set up Ocelot will lookup the downstream host and port from the service discover provider and load balance requests across any available services. If you add and remove services from the
service discovery provider (consul) then Ocelot should respect this and stop calling services that have been removed and start calling services that have been added.
CookieStickySessions
^^^^^^^^^^^^^^^^^^^^
I've implemented a really basic sticky session type of load balancer. The scenario it is meant to support is you have a bunch of downstream
servers that don't share session state so if you get more than one request for one of these servers then it should go to the same box each
time or the session state might be incorrect for the given user. This feature was requested in `Issue #322 <https://github.com/ThreeMammals/Ocelot/issues/322>`_
though what the user wants is more complicated than just sticky sessions :) anyway I thought this would be a nice feature to have!
In order to set up CookieStickySessions load balancer you need to do something like the following.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "10.0.1.10",
"Port": 5000,
},
{
"Host": "10.0.1.11",
"Port": 5000,
}
],
"UpstreamPathTemplate": "/posts/{postId}",
"LoadBalancerOptions": {
"Type": "CookieStickySessions",
"Key": "ASP.NET_SessionId",
"Expiry": 1800000
},
"UpstreamHttpMethod": [ "Put", "Delete" ]
}
The LoadBalancerOptions are Type this needs to be CookieStickySessions, Key this is the key of the cookie you
wish to use for the sticky sessions, Expiry this is how long in milliseconds you want to the session to be stuck for. Remember this
refreshes on every request which is meant to mimick how sessions work usually.
If you have multiple ReRoutes with the same LoadBalancerOptions then all of those ReRoutes will use the same load balancer for there
subsequent requests. This means the sessions will be stuck across ReRoutes.
Please note that if you give more than one DownstreamHostAndPort or you are using a Service Discovery provider such as Consul
and this returns more than one service then CookieStickySessions uses round robin to select the next server. This is hard coded at the
moment but could be changed.
=======
Load Balancer
=============
Ocelot can load balance across available downstream services for each ReRoute. This means you can scale your downstream services and Ocelot can use them effectively.
The type of load balancer available are:
LeastConnection - tracks which services are dealing with requests and sends new requests to service with least existing requests. The algorythm state is not distributed across a cluster of Ocelot's.
RoundRobin - loops through available services and sends requests. The algorythm state is not distributed across a cluster of Ocelot's.
NoLoadBalancer - takes the first available service from config or service discovery.
CookieStickySessions - uses a cookie to stick all requests to a specific server. More info below.
You must choose in your configuration which load balancer to use.
Configuration
^^^^^^^^^^^^^
The following shows how to set up multiple downstream services for a ReRoute using ocelot.json and then select the LeastConnection load balancer. This is the simplest way to get load balancing set up.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "10.0.1.10",
"Port": 5000,
},
{
"Host": "10.0.1.11",
"Port": 5000,
}
],
"UpstreamPathTemplate": "/posts/{postId}",
"LoadBalancerOptions": {
"Type": "LeastConnection"
},
"UpstreamHttpMethod": [ "Put", "Delete" ]
}
Service Discovery
^^^^^^^^^^^^^^^^^
The following shows how to set up a ReRoute using service discovery then select the LeastConnection load balancer.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"UpstreamPathTemplate": "/posts/{postId}",
"UpstreamHttpMethod": [ "Put" ],
"ServiceName": "product",
"LoadBalancerOptions": {
"Type": "LeastConnection"
},
}
When this is set up Ocelot will lookup the downstream host and port from the service discover provider and load balance requests across any available services. If you add and remove services from the
service discovery provider (consul) then Ocelot should respect this and stop calling services that have been removed and start calling services that have been added.
CookieStickySessions
^^^^^^^^^^^^^^^^^^^^
I've implemented a really basic sticky session type of load balancer. The scenario it is meant to support is you have a bunch of downstream
servers that don't share session state so if you get more than one request for one of these servers then it should go to the same box each
time or the session state might be incorrect for the given user. This feature was requested in `Issue #322 <https://github.com/ThreeMammals/Ocelot/issues/322>`_
though what the user wants is more complicated than just sticky sessions :) anyway I thought this would be a nice feature to have!
In order to set up CookieStickySessions load balancer you need to do something like the following.
.. code-block:: json
{
"DownstreamPathTemplate": "/api/posts/{postId}",
"DownstreamScheme": "https",
"DownstreamHostAndPorts": [
{
"Host": "10.0.1.10",
"Port": 5000,
},
{
"Host": "10.0.1.11",
"Port": 5000,
}
],
"UpstreamPathTemplate": "/posts/{postId}",
"LoadBalancerOptions": {
"Type": "CookieStickySessions",
"Key": "ASP.NET_SessionId",
"Expiry": 1800000
},
"UpstreamHttpMethod": [ "Put", "Delete" ]
}
The LoadBalancerOptions are Type this needs to be CookieStickySessions, Key this is the key of the cookie you
wish to use for the sticky sessions, Expiry this is how long in milliseconds you want to the session to be stuck for. Remember this
refreshes on every request which is meant to mimick how sessions work usually.
If you have multiple ReRoutes with the same LoadBalancerOptions then all of those ReRoutes will use the same load balancer for there
subsequent requests. This means the sessions will be stuck across ReRoutes.
Please note that if you give more than one DownstreamHostAndPort or you are using a Service Discovery provider such as Consul
and this returns more than one service then CookieStickySessions uses round robin to select the next server. This is hard coded at the
moment but could be changed.

4
docs/features/routing.rst
View File

@ -211,7 +211,6 @@ Ocelot allows you to specify a querystring as part of the DownstreamPathTemplate
}
],
"GlobalConfiguration": {
"UseServiceDiscovery": false
}
}
@ -239,9 +238,8 @@ Ocelot will also allow you to put query string parameters in the UpstreamPathTem
}
],
"GlobalConfiguration": {
"UseServiceDiscovery": false
}
}
In this example Ocelot will only match requests that have a matching url path and the querystring starts with unitId=something. You can have other queries after this
but you must start with the matching parameter. Also Ocelot will swap the {unitId} parameter from the query string and use it in the downstream request path.
but you must start with the matching parameter. Also Ocelot will swap the {unitId} parameter from the query string and use it in the downstream request path.

7
docs/features/servicediscovery.rst
View File

@ -36,7 +36,7 @@ will be used.
In the future we can add a feature that allows ReRoute specfic configuration.
In order to tell Ocelot a ReRoute is to use the service discovery provider for its host and port you must add the
ServiceName, UseServiceDiscovery and load balancer you wish to use when making requests downstream. At the moment Ocelot has a RoundRobin
ServiceName and load balancer you wish to use when making requests downstream. At the moment Ocelot has a RoundRobin
and LeastConnection algorithm you can use. If no load balancer is specified Ocelot will not load balance requests.
.. code-block:: json
@ -50,7 +50,6 @@ and LeastConnection algorithm you can use. If no load balancer is specified Ocel
"LoadBalancerOptions": {
"Type": "LeastConnection"
},
"UseServiceDiscovery": true
}
When this is set up Ocelot will lookup the downstream host and port from the service discover provider and load balance requests across any available services.
@ -105,7 +104,8 @@ If you are using ACL with Consul Ocelot supports adding the X-Consul-Token heade
"ServiceDiscoveryProvider": {
"Host": "localhost",
"Port": 8500,
"Token": "footoken"
"Token": "footoken",
"Type": "Consul"
}
Ocelot will add this token to the consul client that it uses to make requests and that is then used for every request.
@ -232,6 +232,7 @@ Ocelot also allows you to set DynamicReRoutes which lets you set rate limiting r
"ServiceDiscoveryProvider": {
"Host": "localhost",
"Port": 8523,
"Type": "Consul"
},
"RateLimitOptions": {
"ClientIdHeader": "ClientId",

3
docs/features/servicefabric.rst
View File

@ -4,7 +4,7 @@ Service Fabric
If you have services deployed in Service Fabric you will normally use the naming service to access them.
The following example shows how to set up a ReRoute that will work in Service Fabric. The most important thing is the ServiceName which is made up of the
Service Fabric application name then the specific service name. We also need to set UseServiceDiscovery as true and set up the ServiceDiscoveryProvider in
Service Fabric application name then the specific service name. We also need to set up the ServiceDiscoveryProvider in
GlobalConfiguration. The example here shows a typical configuration. It assumes service fabric is running on localhost and that the naming service is on port 19081.
The example below is taken from the samples folder so please check it if this doesnt make sense!
@ -21,7 +21,6 @@ The example below is taken from the samples folder so please check it if this do
],
"DownstreamScheme": "http",
"ServiceName": "OcelotServiceApplication/OcelotApplicationService",
"UseServiceDiscovery" : true
}
],
"GlobalConfiguration": {