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.
对我来说，它看起来像一些“docker registry”（~“schema registry”）。所以，我请一位专门从事 DevOps 的朋友对此发表评论。他的想法是：
“有道理，但是数据库或文件，另一个状态功能应该只有所有者，如果各种服务使用 1 db，则意味着您将失去一致性。就架构而言，是的，这是有道理的。但是服务的所有者使用不同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 类。这是一场噩梦。
手动版本控制是一种解决方案，我只是认为它可以自动完成。在架构管理 UI 中按下新版本按钮并添加新字段。并勾选该字段适用于每种消息类型的复选框。
如果我们想要像 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", order_data)
context.put("user_id", user_id)
message = context.render("new-order-message")
在模式注册表中查找 new-order-message 以查看它包含哪些数据
注册表决定在呈现时出现在消息有效负载中的上下文或上下文子对象中的哪些数据。
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.