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

Nächste Überarbeitung 		Vorhergehende Überarbeitung
wiki:software:beuthbot:registry:cache [04.06.2020 17:53]
Lukas Danckwerth angelegt 		wiki:software:beuthbot:registry:cache [22.07.2020 18:39] (aktuell)
Jan Fromme
Zeile 3: Zeile 3:
 ====Motivation==== ====Motivation====
  
-// # Warum erstellen wir den Cache?//+Der Cache soll vorrangig die Microservices entlasten, indem er die Response zwischenspeichert und der Registry für eine gewisse Zeit zur Verfügung stellt.  
 +Insbesondere der Service Weather ist davon betroffen, da dieser eine API von [[https://openweathermap.org/price | OpenWeatherMap ]] nutzt, welches pro Tag 4000 Wettervorhersagen treffen kann, sonst wird dieser Kostenpflichtig bzw. kann dann keine Requests mehr entgegen nehmen.
  
-====Requirements==== 
  
-// # Was soll der Cache können?//+| <WRAP color red> Free</WRAP> | Startup \\ **40 USD** / month | Developer \\ **180 USD** / month | Professional \\ **470 USD** / month | Enterprise \\ **2.000 USD** / month | 
 +| **60 calls**/minute \\ **1,000,000 calls**/month  | **600 calls**/minute \\ **10,000,000 calls**/month| **3,000 calls**/minute \\ **100,000,000 calls**/month | **30,000 calls**/minute \\ **1,000,000,000 calls**/month | **200,000 calls**/minute \\ **5,000,000,000 calls**/month | 
 +| [[ https://openweathermap.org/api/weather-map-2 | Current Weather ]] \\ [[ https://openweathermap.org/api/one-call-api | Minute Forecast 1 hour∗ ]] \\ [[ https://openweathermap.org/api/one-call-api | Hourly Forecast 2 days∗ ]] \\ [[ https://openweathermap.org/api/one-call-api | Daily Forecast 7 days∗ ]] \\ [[ https://openweathermap.org/api/one-call-api#history | Historical weather 5 days∗ ]] \\ <wrap lo>Climatic Forecast 30 days</wrap> \\ <wrap lo>Bulk Download</wrap> | Current Weather \\ Minute Forecast 1 hour∗∗ \\ Hourly Forecast 2 days∗∗ \\ Daily Forecast 16 days \\ Historical weather 5 days∗∗ \\ <wrap lo>Climatic Forecast 30 days</wrap> \\ <wrap lo>Bulk Download</wrap> | Current Weather \\ Minute Forecast 1 hour \\ Hourly Forecast 4 days \\ Daily Forecast 16 days \\ Historical weather 5 days \\  [[ https://openweathermap.org/api/forecast30 | Climatic Forecast 30 days ]] \\ <wrap lo>Bulk Download</wrap> | Current Weather \\ Minute Forecast 1 hour \\ Hourly Forecast 4 days \\ Daily Forecast 16 days \\ Historical weather 5 days \\ Climatic Forecast 30 days \\ [[ https://openweathermap.org/bulk | Bulk Download ]] | Current Weather \\ Minute forecast 1 hour \\ Hourly Forecast 4 days \\ Daily Forecast 16 days \\ Historical weather 5 days \\ Climatic Forecast 30 days \\ Bulk Download | 
 +| [[https://openweathermap.org/api/weathermaps | Basic weather maps ]] \\ Historical maps | Basic weather maps \\ Historical maps | [[https://openweathermap.org/api/weather-map-2 | Advanced weather maps ]] \\ [[https://openweathermap.org/api/weather-map-2 | Historical maps ]] | Advanced weather maps \\ Historical maps | Advanced weather maps \\ Historical maps | 
 +| [[https://openweathermap.org/triggers | Weather triggers ]] | Weather triggers | Weather triggers | Weather triggers | Weather triggers | 
 +| [[ https://openweathermap.org/widgets-constructor | Weather widgets ]] |Weather widgets |Weather widgets |Weather widgets |Weather widgets | 
 +| Uptime 95% | Uptime 95% | Uptime 99.5% | Uptime 99.5% | Uptime 99.9% | 
 + 
 +∗ - 1,000 API calls per day by using One Call API \\ ∗∗ - 2,000 API calls per day by using One Call API 
 + 
 +====Requirements====
  
-// # Muss hier nicht viel sein denke ich...//+Die Registry soll Requests von dem Deconcentrator entgegennehmen und überprüfen, ob diese Request innerhalb einer fest definierten Zeit bereits eine Response erhalten hat. Ist dies der Fall guckt die Registry in den Cache, um sich die dort Zwischengespeicherte Response zu holen und diese an den Sender der Request zu leiten. Dabei “ersetzt” der Cache den angesprochenen Microservice. Ist dies allerdings nicht der Fall wendet sich die Registry weiter an den angesprochenen Microservice und speichert dessen Response in den Cache.
  
 ===Functional=== ===Functional===
  
-  * ''/DBF100/'' The system must ... +  * ''/CAF100/'' The system must check if the requested resource is available in the cache before relaying the request to a microservice. 
-  * ''/DBF100/'' The system must ... +  * ''/CAF100/'' The system must place the response of a microservice in the cache. 
-  * ''/DBF100/'' The system must ... + 
-  * ''/DBF200/'' The cache must ... +  * ''/CAF200/'' The cache must offer an option to save a response of a microservice. 
-  * ''/DBF200/'' The cache must ... +  * ''/CAF201/'' The cache must offer an option to retrieve a saved response. 
-  * ''/DBF200/'' The cache must ...+  * ''/CAF202/'' The cache must automatically delete a saved response if the given timeout has been exceeded.
  
 ===Non Functional=== ===Non Functional===
  
-  * ''/DBNF100/'' The system must ... +  * ''/CANF100/'' The system must answer faster with a cached response than if a request is relayed to a microservice.
-  * ''/DBNF100/'' The system must ... +
-  * ''/DBNF100/'' The system must ...+
  
-  * ''/DBNF200/'' The cache must ... +  * ''/CANF200/'' The cache must save at least 1000 Responses. 
-  * ''/DBNF200/'' The cache must ... +  * ''/CANF201/'' The cache must answer in at least 5ms.
-  * ''/DBNF200/'' The cache must ...+
  
 ====User Stories==== ====User Stories====
  
-// # Brauchen wir hier glaube ich garnicht, bzw. sollte das mit den User Stories für den BeuthBot oder die Registry definiert werden...//+  * ''/CAUS100/'' Als Betreiber möchte ich Anfragen die das selbe Ergebnis erzeugen abfangen und damit die Microservices entlasten. 
 +  * ''/CAUS101/'' Als Betreiber möchte ich die Anfragen an die verschiedenen APIs reduzieren um nicht in ein teureres Preispaket zu fallen.
  
-<code> +====Use Cases====
-"Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>" +
-</code>+
  
-  * ''/DBUS100/'' Als Student möchte ich ... +====Technologies====
-  * ''/DBUS101/'' Als Student möchte ich ... +
-  * ''/DBUS102/'' Als Student möchte ich ...+
  
-====Use Cases (?)====+Für Node.js existieren mehrere Caching Lösungen. Bei den ersten recherchen fielen die npm packages “memory-cache” und “node-cache” auf. Da “memory-cache” seit drei Jahren kein Update bekommen hat, haben wir uns letzten endes für “node-cache” entschieden.
  
-====Technologies==== +“node-cache” ist eine simple Caching Lösung, die nach dem Key-Value prinzip funktioniert. Der Funktionsumfang besteht dabei aus den Methoden “set”, “get” und “delete”, wobei die Methode “set” einem zusätzlich erlaubt noch einen Timeout (“ttl” bzw. “time to live” genannt) zu übergeben. Ist der Timeout überschritten, wird der Eintrag automatisch aus dem Cache gelöscht. Der Nachteil dieser Lösung ist, dass nur eine Millionen einträge pro Cache Instanz eingetragen werden können. Da aber gleich viel in den Cache eingetragen wird, wie die Anzahl angebotener Funktionen aller Microservices, wird dieser Nachteil nicht eintreffen.
- +
-// # Mit welcher Technologie / Umgebung / Framework / Programmiersprache werden wir den Cache implementieren?//+
  
-  * Node.js Cache (?) 
  
 ====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 86: 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.1591286036.txt.gz · Zuletzt geändert: 04.06.2020 17:53 von Lukas Danckwerth

Seiten-Werkzeuge