多服务下，需要提供服务发现机制，才能让调用方找到服务。
历史上有三种服务发现机制：
1、传统集中式代理：ng负载均衡，通过upstream配置提供服务发现能力
image.png
2、客户端嵌入式代理：Eureka，提供自动注册自动发现的能力
image.png
3、主机独立进程代理：linkerd或istio，每台机器上都启动代理服务
image.png
三个各有所长，罗列优缺点：
| 服务发现机制 | 优 | 缺 |
|---|---|---|
| 传统集中式代理 | 运维简单 | 配置后期复杂到爆炸，单点挂了就真的挂了 |
| 客户端嵌入式代理 | 无配置，自动注册发现 | 无法快速隔离单节点流量，治理松散，客户端需要开发难以支持多语言 |
| 主机独立进程代理 | 上述的折中方案，配合Eureka做到自动注册发现，同时可以统一管理所有机器的代理，随意分配节点流量 | 运维保障，烧单机的CPU资源 |
各界推崇mesh的原因：
1、上述模式一和二有缺陷，模式一重，有单点和性能问题；模式二则有客户端复杂，支持多语言困难，无法集中治理的问题。模式三是模式一和二的折中，弥补了两者的不足，它是纯分布式的，没有单点问题，性能也OK，应用语言栈无关，可以集中治理。
2、迁移客户端与服务端中的服务治理相关的功能到中间件（Local Proxy or Sidecar），降低升级服务治理功能带来的成本，让服务发现功能升级变得透明，不需要天天催着业务方升级sdk包（沟通成本很高）。
mesh实现上也有2种：
1、sidecar，微服务的请求和被请求流量都经过这个代理，比如spring-sidecar
2、localproxy，微服务的请求流量经过这个代理，但是被请求流量直接到微服务，比如linkerd
image.png
mesh的技术选型：
image.png
网友评论