ServiceMesh(2)
一个进程实现业务逻辑,biz,即上图白色方块
一个进程实现底层技术体系,proxy,即上图蓝色方块,负载均衡、监控告警、服务发现与治理、调用链…等诸多基础设施,都放到这一层实现
如此解耦之后:
biz不管是调用服务,还是提供服务,都只与本地的proxy进行本地通信
所有跨网的通信,都通过proxy之间进行
要聊ServiceMesh,就不得不提Istio,它是ServiceMesh目前最流行的实践,今天说说Istio是干啥的。
什么是Istio?
Istio是ServiceMesh的产品化落地,它的一些关键性描述是:
帮助微服务之间建立连接,帮助研发团队更好的管理与监控微服务,并使得系统架构更加安全
帮助微服务分层解耦,解耦后的proxy层能够更加专注于提供基础架构能力,例如:
(1)服务发现(discovery);
(2)负载均衡(load balancing);
(3)故障恢复(failure recovery);
(4)服务度量(metrics);
(5)服务监控(monitoring);
(6)A/B测试(A/B testing);
(7)灰度发布(canary rollouts);
(8)限流限速(rate limiting);
(9)访问控制(access control);
(10)身份认证(end-to-end authentication);
使得业务工程团队与基础架构团队都更加高效的工作,各自专注于自己的工作,更好的彼此赋能
Istio官网是怎么吹嘘自己的?
Istio非常牛逼,如果要实施ServiceMesh,必须用Istio,因为:
可以通过,在现有服务器新增部署边车代理(sidecar proxy),应用程序不用改代码,或者只需要改很少的代码,就能实现上述N项基础功能
可以通过,控制后台,简单改改配置,点点按钮,就能管理和查看上述N项基础功能
以下特性,Istio在这个环节里进行了附加说明:
(1)负载均衡支持多协议,HTTP, gRPC, WebSocket, TCP;
(2)通过路由、重试、故障转移对流量进行细粒度流控;
(3)通过可插拔策略层以及可配置API,能够支持流量访问控制、限速、配额管理;
(4)自动度量、日志收集、调用跟踪;
(5)服务到服务的身份认证;
Istio的核心特性是什么?
Istio强调了它提供的五项关键特性:
流控(traffic management)
安全(security)
可观察(observability)
平台无关系(platform support)
集成与定制(integration and customization)
Istio的吹嘘与特性,对于国外很多通过RESTful提供内网服务的公司,很有吸引力,但相对于国内微服务架构,未必达到了很好的拉拢效果:
(1)国内基本都是TCP的RPC框架,多协议支持未必是必须的;
(2)RPC框架里,路由、重试、故障转移、负载均衡、高可用都是最基础的;
(3)流控、限速、配额管理,是服务治理的内容,在微服务架构初期是锦上添花;
(4)自动度量,系统入口出口数据收集,调用跟踪,可观察和可操控的后台确实是最吸引人的;
(5)服务到服务的身份认证,微服务基本是内网访问,在架构初期也只是锦上添花;
另外一个花边,为什么代理会叫sidecar proxy?
看了上图就容易懂了,biz和proxy相生相伴,就像摩托车(motor)与旁边的车厢(sidecar)。未来,sidecar和proxy就指微服务进程解耦成两个进程之后,提供基础能力的那个代理进程。
Istio这么牛逼,它的核心架构如何呢?
且听下回分解。