A service mesh is an infrastructure layer that separates microservice business logic from standardized integration concerns. Instead of placing encryption, auditing, retries, observability, and related responsibilities inside every service, it handles them through reusable, configurable system components. section 7.1.1
The architecture divides each microservice into two cooperating components:
- A business-logic container implements the service’s actual functionality. section 7.1.1
- A sidecar container acts as a proxy for integration logic and system-level concerns. section 7.1.1
- Network traffic passes through the sidecar before reaching the business-logic container. section 7.1.1
- Configuration determines which reusable concerns the sidecar applies for a particular service. section 7.1.1
This arrangement contrasts with both smart endpoints, where services contain the integration logic, and smart middleware such as an enterprise service bus, which can centralize too much logic. A mesh keeps business behavior with the endpoint while standardizing infrastructure behavior separately. section 7.1.1
Figure 7.3 An example of a service mesh architecture. Business logic and integration logic are separated into different containers. All network traffic flows through the sidecar component, which acts as a proxy to the component’s pure business logic.
The architecture diagram shows business and integration logic in separate containers, with all network traffic flowing through the sidecar proxy. section 7.1.1
