wiki.ziemers.de

ziemer's informatik Wiki

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Zuletzt angesehen:
wiki:software:beuthbot:registry:cache

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung 		Vorhergehende Überarbeitung
wiki:software:beuthbot:registry:cache [09.06.2020 17:50]
Denny Schumann 		wiki:software:beuthbot:registry:cache [22.07.2020 18:39] (aktuell)
Jan Fromme
Zeile 23: Zeile 23:
 ===Functional=== ===Functional===
  
-  * ''/CAF100/'' The system must ... +  * ''/CAF100/'' The system must check if the requested resource is available in the cache before relaying the request to a microservice. 
-  * ''/CAF100/'' The system must ... +  * ''/CAF100/'' The system must place the response of a microservice in the cache. 
-  * ''/CAF100/'' The system must ... + 
-  *  +  * ''/CAF200/'' The cache must offer an option to save a response of a microservice. 
-  * ''/CAF200/'' The cache must ... +  * ''/CAF201/'' The cache must offer an option to retrieve a saved response. 
-  * ''/CAF200/'' The cache must ... +  * ''/CAF202/'' The cache must automatically delete a saved response if the given timeout has been exceeded.
-  * ''/CAF200/'' The cache must ...+
  
 ===Non Functional=== ===Non Functional===
  
-  * ''/CANF100/'' The system must ... +  * ''/CANF100/'' The system must answer faster with a cached response than if a request is relayed to a microservice.
-  * ''/CANF100/'' The system must ... +
-  * ''/CANF100/'' The system must ...+
  
-  * ''/CANF200/'' The cache must ... +  * ''/CANF200/'' The cache must save at least 1000 Responses. 
-  * ''/CANF200/'' The cache must ... +  * ''/CANF201/'' The cache must answer in at least 5ms.
-  * ''/CANF200/'' The cache must ...+
  
 ====User Stories==== ====User Stories====
Zeile 46: Zeile 42:
   * ''/CAUS101/'' Als Betreiber möchte ich die Anfragen an die verschiedenen APIs reduzieren um nicht in ein teureres Preispaket zu fallen.   * ''/CAUS101/'' Als Betreiber möchte ich die Anfragen an die verschiedenen APIs reduzieren um nicht in ein teureres Preispaket zu fallen.
  
-====Use Cases (?)====+====Use Cases====
  
 ====Technologies==== ====Technologies====
Zeile 57: Zeile 53:
 ====Integration==== ====Integration====
  
-// # An welcher Stelle wird der Cache in das System eingebaut? (Registry)//+Der Cache wird wie schon in Technologies beschrieben in Node.js verwendet. Spezifisch wird der Cache dem "registry" Server hinzugefügt.
  
-// # Wie wird sie eingebaut?// +Das Resultat (veranschaulicht im folgenden UML diagram) besteht darin, dass registry versucht die angefragte Ressource aus dem Cache zu holen und gegebenfalls eine Anfrage an den entsprechenden Microservice zu stellen, falls die Ressource nicht im Cache vorhanden ist.
- +
-// # Wie sieht das Endprodukt aus?//+
  
 <uml> <uml>
Zeile 91: Zeile 85:
 </uml> </uml>
  
-====Abnahmekriterien==== 
- 
-// # Was musst der Cache / die Registry können, damit wir das Projekt als erfolgreich definieren können?// 
- 
-====Resultierende Aufgaben==== 
- 
-// # Was müssen wir also tun?// 
  
-// # Auflistung der Tickets die entstehen...//+==== Resultate ====
  
-// # Vielleicht lieber direkt bei GitHub//+Die momentane Implementierung ist wie zuvor beschrieben umgesetzt. Der einzige Unterschied besteht darin, dass die Microservices die Möglichkeit besitzen, einen ttl mitzuschicken. Wird kein ttl vom Microservice mitgeschickt, so wird ein Standard ttl (momentan 30 Minuten) verwendet.
  
 +Wenn ein Microservice einen ttl mitschicken möchte, so muss dem "answer" Object lediglich ein integer namens "ttl" hinzugefügt werden. Dieser repräsentiert die Anzahl an Sekunden, wie lang zwischengespeichert werden soll.
wiki/software/beuthbot/registry/cache.1591717810.txt.gz · Zuletzt geändert: 09.06.2020 17:50 von Denny Schumann

Seiten-Werkzeuge