Services/F1/Server/Architecture: Difference between revisions

Services/F1/Server/Architecture (view source)

Revision as of 07:50, 22 March 2011

620 bytes added , 22 March 2011

no edit summary

Tarek.ziade

Confirmed users

927

edits

@@ Line 23: / Line 23: @@
 = Synchronous Architecture =
-XXX Diagram
+[[File:Sync-effe-ouane.png]]
-The synchronous architecture is composed of two servers:
+The synchronous architecture is composed of two layers:
-* '''server-shared-auth''': creates and returns tokens for each service
+* The front layer, which proxies calls to the back layer. Every request is routed to a back server.
-* '''server-shared-send''': calls the service and returns the response synchronously
+* The back layer, which calls the third-party service and return the response synchronously.
-The Services Status DB is a key/value storage global to the cluster and replicated in several places. It can be eventually consistent.
+Both front and back layer interacts with the '''Services Status DB''', a key/value storage global to the cluster that indicates the status of each service.
 Detailed transaction:
-. The server checks for the service status to return a 503/Retry after in case the service is down. . Each service has a (GR / BR) ratio stored in that DB. GR = Number of good responses. BR = Number of bad responses. What are "Good" and "Bad" responses is to the workers discretion.
+. Zeus uses a X-Target-Service header that indicates which service is going to be called. For each service there's at least two servers that can be load balanced to receive requests.
-. the server calls the service
+. The server checks in the Service Status DB if the service is up or down. If it's down, it returns immediately a 503 + Retry-after. The Retry-After value is provided by the Service Status DB.
-. the server upgrades the status of the service, by incrementing the number of good or bad responses.
+. If the service is up, it proxies the request to one back-end server that is in charge of the service. There can be several back-end server and the front server uses a round-robin strategy.
-== Load Balancing ==
+. The back-end server proxies to the Gunicorn server, which picks a worker.
-A simple way to balance the load is to have servers dedicated to a specific service.
+. The worker does the job and returns it.
-A X-Target-Service header set by the client can define which service is going to be called and a Zeus load balancer can dispatch the request to a specific subset of servers. This will allow a fine-tuning of the pooling capacity of the web server and also will let us specifically add more servers per service.
+. The worker pings the Service Status DB In order to indicate whether the request was a success or a failure.
+. An admin application let Ops view the current status of the Services, but also shut down a specific service if needed.
+== Services Status DB ==
+Each service has a '''(GR / BR)''' ratio stored in that DB.
+* GR = Number of good responses.
+* BR = Number of bad responses.
+What are "Good" and "Bad" responses is to the workers discretion.
+The DB also store a "disable" flag for each service, that can be toggled manually to shut down a service if needed.
+The DB is replicated in several places and is eventually consistent.
+== Failures ==
+XXX describe the scenarios.
 = Asynchronous Architecture =