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.
Для меня это выглядело как некий "реестр докеров" (~ "реестр схем"). Итак, я попросил друга, специализирующегося на DevOps, прокомментировать это. Его мысли были:
"Имеет смысл, однако база данных или файлы, другая функция состояния должны иметь только владельца, если различные службы используют 1 дБ, это означает, что вы потеряете согласованность. С точки зрения схемы, да, это имеет смысл. Однако владелец службы использует разные версий для API. После выпуска некоторых новых изменений в API вам необходимо увеличить версию API, например /api/v2/blabla. Я думаю, Protobuf или graphql может частично решить эту проблему ».
Я: «То есть, вы имеете в виду, можно сказать, что буферы протоколов и управление версиями API делают ненужным централизованное управление схемами обмена сообщениями?»
Он: «Все современные поставщики API используют управление версиями ... Хорошо, поле появляется автоматически, но если приложение не знает, что это такое, поле бесполезно».
// Кто-то может централизованно переместить часть контекста в схему протокола. Таким образом, добавить новый столбец в базу данных или в сообщение протокола так же просто, как изменить его в одном месте.
Лично мне нравится идея разработки схем данных независимо от микросервисов, потому что тогда каждый может участвовать в разработке онтологической модели системы, которая никогда не заканчивается одним микросервисом.
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.
Многие службы передают сообщения или хранят данные из других служб в составе полезной нагрузки. Иногда рассматриваемая служба не заботится о конкретных полях, но другая служба может идти дальше по цепочке.
Например, в управляемой событиями архитектуре микросервисов, которую я использовал, у нас была MongoDB для хранения кэшированных полезных данных из предыдущей службы, чтобы каждая служба после этого не извлекала их. Также он синхронизирует данные.
Схемы используются в системах RabbitMQ, но часто управляются специальным образом. То есть у вас есть класс Java в каждом микросервисе сети микросервисов, который вы должны синхронизировать. Это кошмар.
Управление версиями вручную - это решение, я просто думаю, что это можно сделать автоматически. Нажмите кнопку новой версии в пользовательском интерфейсе управления схемой и добавьте новые поля. И установите флажки, в которых поле применяется для каждого типа сообщения.
Если нам нужны автономные самоуправляемые организации, такие как DAO, необходимо какое-то соглашение по формату протокола.
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.
Реестр схемы может работать в режиме высокой доступности.
orderData = db.get_order (order_id)
context.put ("заказ", order_data)
context.put ("user_id", user_id)
message = context.render ("сообщение-нового-заказа")
Где новое-сообщение-заказ ищется в реестре схемы, чтобы увидеть, какие данные оно содержит
Реестр решает, какие данные в контексте или внутри подобъектов контекста будут отображаться в полезных данных сообщения при визуализации.
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.
В своей социальной сети, основанной на электронной почте, я заранее определил множество схем. Для обработки акций различных вещей.
Я написал пример XML каждого сообщения. Но не использовал примеры после их написания.
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.