Protocol context manager
In big microservice based systems or systems with lots of protocols, you often need to make a change that ripples out through the entire system. If you have X services you send a message between them you have X message schemas. Let's manage the schemas centrally
Adding a field to a message should be a simple change in a central system. The rest of the system should just adapt to the new field.
In traditional microservice architectures there's either a monorepo or a repository per microservice and each service has to be changed to add the new field.
In this design each service retrieves its schema from a central source and every area where messages are constructed there is a context area. This context area contains all known state at that point in time.
Someone can move a piece of context to the protocol schema centrally. So adding a new column to a database or to a protocol message is as simple as changing it in one place.
Man tai atrodė kaip „dokų registras“ (~ „schemos registras“). Taigi, aš paprašiau draugo, specializuoto devops, pakomentuoti tai. Jo mintys buvo tokios:
"Tikslinga, nors db ar failai, kita būsenos funkcija turėtų turėti tik savininką, jei įvairios paslaugos naudoja 1 db, tai reiškia, kad prarasite nuoseklumą. Kalbant apie schemą, taip, tai prasminga. Tačiau paslaugos savininkas naudoja skirtingai API versijos. Kai išleisite keletą naujų API pakeitimų, turite padidinti API versiją, pvz., /api/v2/blabla. Manau, Protobuf arba graphql gali iš dalies išspręsti šią problemą “.
Aš: "Taigi, jūs turite omenyje, kad galima būtų pasakyti, kad protokolų buferiai ir API versijos neleidžia centralizuotai valdyti pranešimų schemų?"
Jis: „Visi šiuolaikiniai API teikėjai naudoja versijas ... Gerai, laukas rodomas automatiškai, bet jei programa nežino, kas tai yra, laukas nenaudingas“.
// Kažkas gali centralizuotai perkelti kontekstą į protokolo schemą. Taigi pridėti naują stulpelį prie duomenų bazės ar protokolo pranešimo yra taip paprasta, kaip pakeisti jį vienoje vietoje.
Man asmeniškai patinka idėja kurti duomenų schemas nepriklausomai nuo mikroservisų, nes tada kiekvienas gali būti įtrauktas į ontologinio sistemos modelio kūrimą, kuris niekada nesibaigia tik viena mikro paslauga.
For me, it looked like some "docker registry" (~"schema registry"). So, I asked a friend specialized in devops to comment on this. His thoughts were:
"Makes sense, however a db or files, another state feature are supposed to have only owner, if various services use 1 db, it means you will loose consistency. In terms of schema yes, it makes sense. However owner of service use different versions for API. Once you release some new changes on API, you have to increase API version, like /api/v2/blabla.I think Protobuf or graphql can solve this problem partly."
Me: "So, you mean, a point could be made, that protocol buffers, and API versioning make the central management of messaging schemas not necessary?"
Him: "All modern API providers use versioning... Ok, field appears automatically, but if application is not aware what it is, the field is unuseful."
// Someone can move a piece of context to the protocol schema centrally. So adding a new column to a database or to a protocol message is as simple as changing it in one place.
Personally, I like the idea of developing schemas of data independently of microservices, because then everyone can be part of the development of ontological model of the system, which never ends with just one microservice.
Daugelis paslaugų perduoda pranešimus arba saugo kitų paslaugų duomenis naudingojoje apkrovoje. Kartais aptariama paslauga ypač nesirūpina tam tikromis sritimis, tačiau kita paslauga gali būti toliau grandinėje.
Pavyzdžiui, naudodamas įvykiais pagrįstą mikroservisų architektūrą, turėjome „MongoDB“ saugoti talpykloje saugomą ankstesnės paslaugos duomenų apkrovą, kad vėliau negalėtume gauti kiekvienos paslaugos. Taip pat jis sinchronizuoja duomenis.
Schemos naudojamos „RabbitMQ“ sistemose, tačiau dažnai yra valdomos ad hoc būdu. Tai yra, jūs turite „Java“ klasę kiekvienoje mikroservisų tinklo mikroservisoje, kurią turite sinchronizuoti. Tai košmaras.
Versija rankiniu būdu yra sprendimas, tik manau, kad tai būtų galima padaryti automatiškai. Paspauskite naujos versijos mygtuką schemos valdymo vartotojo sąsajoje ir pridėkite naujų laukų. Pažymėkite žymimuosius laukelius, kuriuose laukas taikomas kiekvienos rūšies pranešimams.
Jei norime savarankiškų savarankiškai valdomų organizacijų, tokių kaip DAO, reikės susitarti dėl protokolo formato.
Many services pass on messages or store data from other services within the payload. Sometimes the service in question doesn't care about particular fields particularly but another service might further down the chain.
For example in event driven microservice architecture I have used we had MongoDB store cached payload of data from a previous service to preclude having every service thereafter fetching it. Also it keeps data in sync.
Schemas are used in RabbitMQ systems but are often managed in an ad hoc way. That is you have a Java class in each microservice of the network of microservices that you have to keep in sync. It's a nightmare.
Versioning manually is a solution I just think it could be done automatically. Press a new version button in a schema management UI and add the new fields. And tick check boxes where the field applies for each message kind.
If we want autonomous self managed organisations like DAOs there will need to be some agreement on the protocol format.
Schemos registras gali būti paleistas didelio prieinamumo režimu.
orderData = db.get_order (order_id)
context.put („užsakymas“, užsakymo_datai)
context.put ("vartotojo ID", vartotojo ID)
message = context.render ("new-order-message")
Kur schemos registre ieškoma naujo užsakymo pranešimo, kad pamatytumėte, kokie duomenys jame yra
Registras nusprendžia, kokie duomenys, esantys kontekste ar vidiniame kontekste, rodomi pranešimų naudingojoje apkrovoje, kai jie pateikiami.
The schema registry could be ran in high availability mode.
orderData = db.get_order(order_id)
context.put("order", order_data)
context.put("user_id", user_id)
message = context.render("new-order-message")
Where new-order-message is looked up in the schema registry to see what data it contains
The registry decides what data in context or inside context subobjects appears in the message payload when rendered.
El. Pašto socialiniame tinkle iš anksto apibrėžiau daugybę schemų. Tvarkyti įvairių dalykų akcijas.
Aš parašiau kiekvienos žinutės XML pavyzdį. Bet nenaudojo pavyzdžių, kai juos parašė.
In my email based social network I defined lots of schemas upfront. To handle shares of various things.
I wrote example XMLs of each message. But didn't use the examples after writing them.