Service Mesh概述

引言

微服务架构会遇见一些挑战：网络不可靠性、服务可用性、复杂难以理解的流量、流量加密、应用程序运行状况和性能等。引入底层框架（实现负载均衡，服务发现，重试）可以一定程度缓解这种情况。额外的框架引入到应用会带来一些问题，如框架升级应用也得一起升级，同时这种模式一般需要指定开发语言，多语言支持欠缺。基于此，引入service mesh可以很好的解决此类问题，sidecar模式与应用伴生，横截拦截应用出入流量，实现引入框架的功能。

一.为什么需要service mesh

当前微服务架构存在两个基本问题：

1》无法支撑多语言战略，公司一般维护当前主流语言框架，例如java，go等

2》框架升级需要推动业务升级，时间久，并且业务配合发布也有稳定性风险

service mesh引入sidecar模式，横切整个流量并进行处理（负载均衡，失败策略，监控指标等）。

1》sidecar伴生应用程序，sidecar的升级对于应用无感

2》sidecar（istio的data plane，实现为envoy）支持http，grpc等协议，支持多语言开发

二.istio介绍

service mesh整体关系图如下：

 部署平台是k8s，以istio实现service mesh为例；主要分为data plane和control plane：

1.其中service proxy是sidecar，istio中的data plane实现为envoy

2.istio中的control plane，支持动态的给envoy配置策略

总结

介绍了当前微服务的一些痛点，引入了service mesh方案。介绍了istio实现的service mesh基础组件。接下来将进行实际的操作。

参考：

《istio in action》

干货 | 携程 SOA 的 Service Mesh 架构落地