为什么开发人员要构建基于代理的微服务

基于代理的微服务的兴起：揭开架构的面纱

基于代理的微服务的本质

基于代理的微服务架构在服务实例和外部世界（无论是其他服务还是客户端）之间插入了一个轻量级的网络代理。这个代理通常被称为“sidecar”，它不仅仅是一个交通警察：它就像一个静默的哨兵，在微服务组成的短暂网格中拦截、检查和转换请求。

为什么要采用这种方法？

• 关注点分离：从业务逻辑中卸载横切关注点（安全性、可观察性、可靠性）
• 统一政策执行：集中访问控制、速率限制和断路
• 弹性模式：透明地注入重试、回退和超时
• 可观察性：无需修改代码即可捕获跟踪和指标
• 零信任安全：加密所有流量并自动验证身份

架构解剖：代理如何体现微服务精神

边车模式

每个服务 Pod 都附带一个代理进程——Envoy、Linkerd 或 HAProxy 是常见的选择。发往服务的流量通过 Sidecar 进行路由，Sidecar 负责应用网络策略、收集遥测数据并管理 mTLS 加密。

清单示例（Kubernetes + Istio）：

apiVersion：v1 种类：Pod 元数据：名称：poets-service 规范：容器： - 名称：poets-app 镜像：registry.example.com/poets:latest - 名称：istio-proxy 镜像：docker.io/istio/proxyv2:1.18.0 args：[“proxy”，“sidecar”]

Istio 自动注入 istio-proxy 边车，在您的服务周围编织出一幅无形的控制挂毯。

服务网格：网络如同一个生命体

服务网格，例如 Istio, Linkerd， 或者 Consul 连接，协调这些代理的配置和生命周期，使服务到服务网络可编程且可观察。

资源：
– Envoy Proxy 官方文档
– Linkerd 架构

实际优势：权衡表

特征	基于代理的微服务	传统微服务
分布式追踪	原生、透明	手动仪表
无处不在的 mTLS	自动化	应用程序责任
熔断	声明式、基于策略	代码中明确
速率限制	集中式、动态	去中心化、静态
金丝雀发布	代理处流量分割	由负载均衡器处理
服务发现	内置、动态	需要外部注册表
故障隔离	每个请求，代理级别	代码或底层

这张桌子低声诉说着这样一个世界：网络不再是一种负担，而是一种创新的画布。

可操作模式：实现基于代理的微服务

1. 部署 Sidecar 代理

在 Kubernetes 中，可以使用 Istio 或 Linkerd 等工具自动执行 Sidecar 注入。

一步一步：Istio 示例

1. 安装 Istio：
   狂欢
curl -L https://istio.io/downloadIstio | sh -
cd istio-*
导出 PATH=$PWD/bin:$PATH
istioctl 安装--设置配置文件=演示-y
kubectl 标签命名空间默认 istio-injection=enabled
2. 部署您的服务：
   “`yaml
   api版本：v1
   种类：服务
   元数据：
   名称：poets-app
   规格：
   端口：
   • 端口：80
     名称：http
     选择器：
     应用程序：诗人

---

api版本：apps/v1
种类：部署
元数据：
名称：诗人部署
规格：
副本：1
选择器：
匹配标签：
应用程序：诗人
模板：
元数据：
标签：
应用程序：诗人
规格：
容器：
– 名称：poets-app
图片：registry.example.com/poets:latest
“`
Sidecar 注入将自动添加 Envoy 代理；不再需要繁琐的样板。

1. 应用流量策略：
   yaml
api版本：networking.istio.io/v1alpha3
种类：DestinationRule
元数据：
名称：诗人目的地
规格：
主持人：poets-app
流量策略：
连接池：
TCP：
最大连接数：1

2. 零代码更改的可观察性

一旦代理到位，遥测数据就像法国晚宴上的葡萄酒一样流动。Istio 和 Linkerd 通过 Prometheus 端点公开指标，为 格拉法纳 仪表板。

获取指标：

kubectl -n istio-system port-forward svc/prometheus 9090 # 打开 http://localhost:9090 查询指标

3. 无需开发人员干预即可强制执行 mTLS

配置对等身份验证和目标规则，网格加密所有服务到服务的通信。

Istio PeerAuthentication 示例：

apiVersion：security.istio.io/v1beta1 种类：PeerAuthentication 元数据：名称：默认 命名空间：默认 规范：mtls：模式：STRICT

不再需要在每项服务中手工制作 TLS 隧道。

代码级示例：无需代码的熔断

用于熔断的 DestinationRule（Istio）：

apiVersion：networking.istio.io/v1alpha3 种类：DestinationRule 元数据：名称：断路器 规格：主机：poets-app trafficPolicy：outlierDetection：consequence5xxErrors：1 间隔：1s baseEjectionTime：30s maxEjectionPercent：100

此 YML 咒语为您的服务注入了弹性，无需更改代码。

何时不使用基于代理的微服务

设想	基于代理的网格	更简单的替代方案
< 5 个服务，复杂度低	开销	直接沟通
边缘服务，仅面向公众	不必要	API网关
资源高度受限的环境	可能很重	轻量级代理

进一步阅读和资源

• Istio 安全概念
• Envoy 代理过滤器链
• Linkerd 与 Istio 的比较
• Consul Connect 服务网格

现代云的脉搏

基于代理的微服务架构，以其错综复杂的代理和策略编排，体现了数字时代对秩序和创造力的追求。网络曾经是一个阴暗的地下世界，如今却变成了一个舞台——每个代理，一个参与者，每个请求，都是分布式系统诗歌中转瞬即逝的诗句。