标签：今天 身份认证 系统架构 能力 说明 哪些 加密 服务 tin
ServiceMesh(2)
上一篇介绍了《ServiceMesh究竟解决什么问题？》，当微服务架构体系越来越复杂的时候，需要将“业务服务”和“基础设施”解耦，将一个微服务进程一分为二：
如此解耦之后：
要聊ServiceMesh，就不得不提Istio，它是ServiceMesh目前最流行的实践，今天说说Istio是干啥的。
画外音：不能落伍。
Istio是ServiceMesh的产品化落地，它的一些关键性描述是：
帮助微服务之间建立连接，帮助研发团队更好的管理与监控微服务，并使得系统架构更加安全
画外音：Istio helps you to connect, secure, control, and observe microservices.
帮助微服务分层解耦，解耦后的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);
画外音：佩服，硬是凑齐了十条，其实SM还能提供更多基础服务功能。
画外音：这个问题的另一个问法是“为什么大家要来用Istio”。
Istio非常牛逼，如果要实施ServiceMesh，必须用Istio，因为：
可以通过，在现有服务器新增部署边车代理(sidecar proxy)，应用程序不用改代码，或者只需要改很少的代码，就能实现上述N项基础功能
画外音：你信了么？
可以通过，控制后台，简单改改配置，点点按钮，就能管理和查看上述N项基础功能
Istio强调了它提供的五项关键特性：
流控(traffic management)
画外音：断路器(circuit breakers)、超时、重试、高可用、多路由规则、AB测试、灰度发布、按照百分比分配流量等。
安全(security)
画外音：加密、身份认证、服务到服务的权限控制、K8S里容器到容器的权限控制等。
可观察(observability)
画外音：追踪、监控、数据收集，通过控制后台全面了解上行下行流量，服务链路情况，服务运行情况，系统性能情况，国内微服务架构体系，这一块做得比较缺乏。
平台无关系(platform support)
画外音：K8s，物理机，自己的虚机都没问题。
Istio的吹嘘与特性，对于国外很多通过RESTful提供内网服务的公司，很有吸引力，但相对于国内微服务架构，未必达到了很好的拉拢效果：
（1）国内基本都是TCP的RPC框架，多协议支持未必是必须的；
（2）RPC框架里，路由、重试、故障转移、负载均衡、高可用都是最基础的；
（3）流控、限速、配额管理，是服务治理的内容，在微服务架构初期是锦上添花；
（4）自动度量，系统入口出口数据收集，调用跟踪，可观察和可操控的后台确实是最吸引人的；
（5）服务到服务的身份认证，微服务基本是内网访问，在架构初期也只是锦上添花；
看了上图就容易懂了，biz和proxy相生相伴，就像摩托车(motor)与旁边的车厢(sidecar)。未来，sidecar和proxy就指微服务进程解耦成两个进程之后，提供基础能力的那个代理进程。
Istio这么牛逼，它的核心架构如何呢？
且听下回分解。
画外音：实在太晚了，今天要睡觉了。
架构师之路-分享技术思路
相关文章：
《ServiceMesh究竟解决什么问题？》
是不是觉得SM有点意思，也想调研下Istio了？
对于ServiceMesh，想了解哪些？
标签：今天 身份认证 系统架构 能力 说明 哪些 加密 服务 tin
原文地址：https://blog.51cto.com/jyjstack/2548772
