You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -36,105 +36,140 @@ Here's the list of technologies used in this solution and its examples:
36
36
[#in_depth]
37
37
== An in-depth look at the solution's architecture
38
38
39
-
////
40
-
Technical description including all or some of the following: architecture ired diagrams. In-depth details of the decisions made and solutions used. Description of each service and what it is used for. Description of any integration.
41
-
////
39
+
Building applications around the Event Mesh is a solution that can be applied
40
+
either to existing applications or to greenfield projects. The existing
41
+
applications can be divided by their domain boundaries. The divided parts might
42
+
become modules, or even external services. Those modules will issue commands,
43
+
directed towards the Event Mesh, which will be routed towards the configured
44
+
endpoints.
42
45
43
46
=== Problem Analysis
44
47
45
-
Traditional transactional systems enforce strict consistency, which slows
46
-
applications and distorts business logic. In our example, Cabs app, must
47
-
account for a real-life events like exiting a cab, even if dependent systems
48
-
(e.g. invoicing) experience downtime. Throwing errors, while keeps the
49
-
consistency in already stored data, loses the new data from real life events.
50
-
This leads to a bad impression by the end-users, and distorts the actual
51
-
business process.
48
+
Traditional transactional systems enforce strict consistency, which slows
49
+
applications and distorts business logic. In our illustrative Cabs app example,
50
+
we must accommodate real-world scenarios, such as exiting a cab, even when
51
+
dependent systems (e.g., invoicing) encounter disruptions. Disregarding errors,
52
+
which preserve the integrity of existing data, discards the newly generated data
53
+
from genuine events. This results in a negative user experience and distorts
54
+
the actual business process, leading to potential customer dissatisfaction.
52
55
53
56
=== Solution Breakdown
54
57
55
-
Split services into independently operating microservices with distinct responsibilities.
56
-
57
-
Utilize CQRS to separate commands (asynchronous state changes) from queries (synchronous, retry-safe reads).
58
+
The concept of employing the Event Mesh as a central, reliable hub for dispatching
59
+
commands, as events, lies at the heart of this solution. This approach aligns
60
+
closely with the Command Query Responsibility Segregation (CQRS) pattern, which
61
+
distinctly categorizes commands and queries. Commands, in this context, are
62
+
modeled as asynchronous events, designed to undergo processing by the event mesh.
63
+
On the other hand, queries are synchronous operations, safe to retry, ensuring
64
+
no loss of data integrity due to transient errors.
65
+
66
+
The primary responsibility of the Event Mesh is twofold: firstly, it persists
67
+
the incoming events, thereby maintaining a record of changes in the system's
68
+
state. Secondly, it routes these events to their respective endpoints, ensuring
69
+
that the appropriate microservices are notified and can subsequently update
70
+
their internal states based on the event data.
71
+
72
+
The mesh's inherent resilience is further bolstered by its exponential backoff
73
+
strategy, which it employs when encountering operational failures. This mechanism
74
+
ensures that the system retries the operation until it succeeds, thus mitigating
75
+
the risk of data loss or system disruption due to transient issues.
76
+
77
+
By integrating the Event Mesh into the system architecture, several architectural
78
+
benefits are achieved:
79
+
80
+
* **Decomposition of the application into independently functioning services**:
81
+
This approach facilitates a division of labor, with each service handling
82
+
specific responsibilities. This not only enhances maintainability but also
83
+
fosters scalability, as services can be independently scaled based on their
84
+
demands.
85
+
86
+
* **Correction of systemic issues**:
87
+
The Event Mesh's error-handling mechanism, through retries and event
88
+
persistence, aids in minimizing the impact of failures on the end user.
89
+
This is crucial as it prevents bugs and outages from becoming visible to
90
+
the user, thereby preserving the system's perceived responsiveness.
91
+
92
+
* **Enhanced system performance**:
93
+
The system becomes more responsive, as the end user no longer needs to
94
+
wait for multiple, often independent, operations to complete successfully.
95
+
The Event Mesh's event-driven model, coupled with the retries and event
96
+
persistence, ensures that critical state changes are propagated swiftly and
97
+
reliably, thereby improving the overall user experience.
58
98
59
99
=== Event Mesh Flow
60
100
61
-
Events like CompleteTransit are published as CloudEvents to a Knative broker.
62
-
63
-
Triggers route events dynamically to the appropriate microservices.
64
-
65
-
Services process events, update state, and emit new events for downstream consumers.
66
-
67
-
=== Using images
68
-
69
-
image::red_hat_open-hybrid-cloud.png[width=30%]
70
-
71
-
{empty}
72
-
73
-
=== Embedding HTML
101
+
* Events are published as CloudEvents to a Knative's Event Mesh.
102
+
* Triggers route events dynamically to the appropriate endpoints.
103
+
* Services process events, update state, and emit new events for downstream
104
+
consumers.
74
105
75
-
++++
76
-
<br>
77
-
<h3> Embed HTML by surrounding it with with four +s before and after. </h3>
The diagram illustrates the flow of events between the legacy application, the Knative Event Mesh, the fee calculator service, and the datastore.
105
137
106
-
=== Creating tables
107
-
108
-
[cols="1a,1a,1a"]
109
-
|===
110
-
| *Column A* | Column *A* | _Column C_
111
-
|
112
-
* Lorem Ipsum
113
-
* Lorem Ipsum
138
+
=== Supporting Legacy Systems
114
139
115
-
|
116
-
* Lorem Ipsum
117
-
* Lorem Ipsum
140
+
One of the strengths of an event mesh architecture is its ability to integrate seamlessly with legacy systems, making them more resilient and adaptable. Legacy applications can be retrofitted to produce and consume events through lightweight adapters. For instance:
118
141
119
-
|
120
-
* Lorem Ipsum
121
-
* Lorem Ipsum
122
-
|===
142
+
* A monolithic Java application can send events for specific operations, like CompleteTransit, instead of handling all logic internally.
143
+
* Event listeners can be introduced incrementally, enabling the legacy app to subscribe to events like DriverFeeCalculated without refactoring its core logic.
123
144
145
+
* This approach decouples old systems from rigid workflows, allowing for gradual modernization while ensuring operational continuity.
124
146
147
+
=== Improving Resilience in Traditional Applications
125
148
126
-
=== Content that can be copied
149
+
Traditional systems often rely on synchronous calls and transactions, which can cascade failures across components. Replacing these with asynchronous event-driven communication reduces dependencies.
127
150
128
-
Click below to copy the content
129
-
[.console-input]
130
-
[source,shell script]
131
-
----
132
-
oc version #openshift cli client
133
-
oc login --token=<token> --server=<server>
134
-
----
151
+
For example, invoicing and notification services in an e-commerce platform can process OrderPlaced events independently, ensuring that downtime in one service does not block the entire order workflow.
135
152
153
+
Retry mechanisms provided by the event mesh guarantee that transient failures are handled gracefully without data loss.
136
154
137
155
[#more_tech]
138
-
== About the Technology Stack
139
-
140
-
If you want to include more details about the tech stack you used, this is the place.
156
+
== More about the Technology Stack
157
+
158
+
It's worth noting that _Knative's Event Mesh_ is completely transparent to the
159
+
applications. The applications publish and consume events, usually via
160
+
_HTTP REST_, and the only thing that is required is the _CloudEvents_ format.
161
+
162
+
The _CloudEvents_ format provides a common envelope for events with metadata
163
+
that every event needs, such as identifier, type, timestamps, or source
164
+
information. The format is a CNCF standard supported by a number of projects and
165
+
doesn't enforce the use of any library.
166
+
167
+
This makes the investment in _Knative's Event Mesh_ safe in terms of vendor
168
+
lock-in. Architects can be assured that their options remain open and that
169
+
solutions can be easily reconfigured down the road.
170
+
171
+
What's more, relying on well-known and easy-to-deploy _CloudEvents_, typically
172
+
over _HTTP_, makes testing simple and straightforward. Developers don't need
173
+
complex development environments because the _Event Mesh_ integration can be
174
+
easily tested with regular _REST_ send or receive tests that most developers
0 commit comments