Confirmed users
927
edits
Services/F1/Server/Architecture: Difference between revisions
→Synchronous Architecture
Tarek.ziade (talk | contribs) No edit summary |
Tarek.ziade (talk | contribs) |
||
| Line 32: | Line 32: | ||
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. | 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 | == Detailed transaction == | ||
1. 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. | 1. 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. | ||
| Line 64: | Line 64: | ||
XXX describe the scenarios. | XXX describe the scenarios. | ||
== Security == | |||
The API keys for each services are stored in the back-end layer only. The front end layer, accessible from outside, does not have the keys and just pass the requests. | |||
= Asynchronous Architecture = | = Asynchronous Architecture = | ||