Meine Systemarchitektur wie sieht wie folgt aus: -AWS Lambda - Wo die Konfiguration halten
SNS -> AWS Lambda -> Dynamo Db
So wird SNS-Meldungen veröffentlichen, auf die AWS Lambda-Funktion ist die Teilnehmer und dann AWS Lambda schiebt die Daten in Dynamo Db. In diesem Fall mache ich eine Transformation von Nachrichten in AWS Lambda. Für die Transformation muss ich einige Regeln von einem Ort holen. Diese Regeln sind im Grunde die Zuordnung zwischen Feldern der ursprünglichen Nachrichten zu Feldern zu transformierten Nachrichten.
Eg.
Say, Original Message looks like below:-
{"id": 1,
"name":"dsadas",
"house":"dsads dsadsa",
"speciality":"asjdsa"
}
and my mapping is something like:-
{"id":"id",
"house":"home",
"speciality":"area"
}
Also, im Grunde sage ich, dass ID ID, Haus zu Haus und so weiter zugeordnet werden sollte.
Also, ich möchte diese Zuordnung an einigen Orten wie Dynamo Db oder einige Config-Service beibehalten. Ich möchte es nicht direkt in aws Lambda Code behalten, da es eine Chance gibt, dass ich mich ändern muss. Aber es in Dynamo Db zu behalten ist sehr teuer in Bezug auf die Latenz, denke ich, weil ich bei jeder Nachrichtenanforderung einen Anruf machen werde. Also, kann jemand vorschlagen, jede aws-Ressource, die verwendet werden kann, um diese Konfigurationen zu halten, die sehr schnell ist und normalerweise für die Konfiguration verwendet wird.
Eine Überlegung: Es klingt, als ob Sie eine Implikation von Lambdas häufiger Wiederverwendung von Containern nicht vollständig verstehen. Deklarieren Sie eine globale Variable (vor dem Handler hängt der spezifische Mechanismus natürlich von der Sprache ab) und bei jedem Aufruf müssen Sie die Konfiguration nur dann in diese Variable laden, wenn die Variable nicht definiert ist. Wenn die Variable bereits einen Wert hat, müssen Sie sie nicht erneut laden, und Sie werden feststellen, dass sie bereits gefüllt ist, da der Container wiederverwendet wird. –