Service Mesh架构其实就是云原生时代的微服务架构，平台中间件。
技术选型
- serivce mesh架构图
服务网格工作流程
- 控制平面将整个网格中的服务配置推送到所有节点的 sidecar 代理中。
- Sidecar 代理将服务请求路由到目的地址，根据中的参数判断是到生产环境、测试环境还是 staging 环境中的服务（服务可能同时部署在这三个环境中），是路由到本地环境还是公有云环境？所有的这些路由信息可以动态配置，可以是全局配置也可以为某些服务单独配置。
- 当 sidecar 确认了目的地址后，将流量发送到相应服务发现端点，在 Kubernetes 中是 service，然后 service 会将服务转发给后端的实例。
- Sidecar 根据它观测到最近请求的延迟时间，选择出所有应用程序的实例中响应最快的实例。
- Sidecar 将请求发送给该实例，同时记录响应类型和延迟数据。
- 如果该实例挂了、不响应了或者进程不工作了，sidecar 将把请求发送到其他实例上重试。
- 如果该实例持续返回 error，sidecar 会将该实例从负载均衡池中移除，稍后再周期性得重试。
- 如果请求的截止时间已过，sidecar 主动失败该请求，而不是再次尝试添加负载。
- Sidecar 以 metric 和分布式追踪的形式捕获上述行为的各个方面，这些追踪信息将发送到集中 metric 系统。
nginx service-mesh提供
- 流量控制（路由规则，负载均衡）
- 鉴权
ingress-nginx基础的负载均衡和服务发现功能。
可以在原有的基础上开发更丰富的负载均衡和服务发现功能，例如可以根据HTTP头部信息进行路由匹配、可以动态更新路由规则等。
未来五到十年，基于云原生模式架构下的服务网格架构开始崭露头角。APISIX 也提前开始锁定赛道，通过调研和技术分析后，APISIX 已经支持了 xDS 协议，APISIX Mesh 就此诞生，在服务网格领域 APISIX 也拥有了一席之地。
- sidecar边车模式
只包含控制面和数据面的 Service Mesh 服务网格全局结构图 如下：
-
evnoy c++需要开发自己的私有协议转发功能； -- 难度较高，开发效率低。
-
自研ingress-controller和agent服务更好的融入自己的生态。(运维系统，metrics统计上报，告警系统，日志系统等)
- agent数据面采用golang开发，开发效率更高。 -- 不过性能会比C++稍差。
service-mesh提供基础服务： 可靠的消息传递，流量控制，权限管理，可视化等基础通用服务；
- 不需要业务端 基础 微服务的sdk或框架。 -- 业务开发更加方便灵活。
自研service-mesh打造自己的生态，同时作为基础服务，对功能，性能等要求更高。 -- 代码质量很水平提出了更高要求。