最近潭主复盘了一遍Linkerd，算是为Service Mesh的学习开了个头。
上期文章发布的前一天晚上，在朋友圈看到友商的聚会邀请，因为跟Service Mesh有关，就去凑了个热闹，没成想围观了Flomesh社区大咖们的酒会。
当然，也听到不少Service Mesh的新资讯。
今天就跟大家分享一下Service Mesh的另一个技术实现，Istio。
“脱钩”的Ambient Mesh
原本想先通过Linkerd做个技术铺垫，再过渡到Istio，保持一定的先进性。
没想到蹦出来一个Solo，让潭主有点措手不及。
Solo和Google为Istio项目贡献一个重要的新架构，称为Istio Ambient Mesh。
在Istio中，Sidecar是Per-Pod模式，但是Istio Ambient Mesh却跟通过DaemonSet部署的Linkerd一样，采用了Per-Node模式。
为此，有社区大咖说Ambient Mesh开倒车，又回到了Linkerd的老路上。
模式归模式，最终还是要综合评估技术和商业可行性，毕竟不是每个“领导”都需要配机要秘书，因地制宜，解决主要矛盾。
言归正传，还是回到Istio身上。
Istio的架构和核心功能
有了Linkerd的基础，再看Istio就觉得简单多了。
虽说Istio也是经典的控制平面和数据平面架构，但真做到生产可用，除了自身版本迭代外，也少不了架构重构。
在最新的架构中，原来分散、独立部署的控制组件被整合成了一个多模块的Istiod进程：
Pilot：负责处理流程规则，提供超时、重试和熔断等功能。
Citadel：负责身份认证和证书管理，结合SDS（Secret Discovery Service）可实现无需挂载Secret卷、动态更新证书，还能侦听多个证书的密钥对。
Galley：负责配置验证，通过网格配置协议完成组件交互，实现配置管理和分发。
K8S的本质是通过声明配置对应用进行生命周期管理，而Service Mesh的本质则是实现应用间的流量和安全管控，同时提供可观察性。
从流量上看，K8S的Kube-Proxy通过iptables实现了Node的流程管控，而附着在K8S之上的Istio，则通过Sidecar实现了进出Pod的流量管控。
Envoy和它的xDS
Istio的数据平面用的是Envoy，一款由Lyft开源，用C++编写的高性能服务代理软件。
如果说linker是Linkerd中的Sidecar，那么Envoy就是Istio的Sidecar。
每次学习新产品和技术，都难免遇到一些名词和术语，算是入门的黑话。
DownStream（下游）：请求发送方
UpStream（上游）：接收请求方
可以从Sidecar所处的位置来理解上下游关系，最终Envoy使用Filter（过滤）和Router（路由）将上下游串联起来。
Filter像是Envoy的可插拔组件，提供流量编排，目前Istio社区提供了现成的Filter供用户直接使用。
流量从Ingress进来，在Istio的Envoy上打转，最后再从Egress出去，实现南北进出，东西互访。
而Envoy的服务发现功能对应的API被称为xDS，是整个Istio的基石。
重点是理解Listener、Router、Cluster和Endpoint四个核心的服务发现功能，新版本里还有VHDS（VirtualHost）和SDS（Secret）等新的发现服务。
Istio与它的CRD
在核心的流量管理上，Istio则是通过一组CRD（Custom Resource Definition）来具体实现的。
Gateway：网格边缘的负载控制器，控制进出网格的流量（Ingress & Egress）
VirtualService：定义路由的目标服务和流量策略
DestinationRule：设定路由规则和访问策略。
EnvoyFilter：描述针对代理服务的过滤器
ServiceEntry：在Istio内部注册添加外部服务条目，实现对网格外部的服务访问
WorkloadEntry：将虚拟机接入服务网格
这部分内容过于概念化，有机会动手实践一下相信会更有收获。
从Mixer到WASM
WASM是WebAssembly的简称，也是一个挺火的新东西。
之前的Istio版本中，Mixer作为中介，通过服务抽象层实现Envoy与Prometheus等平台进行交互，通过Adapter适配完成对接。
在新版本中，WebAssembly作为一种沙盒技术内嵌在Envoy中，用Proxy-WASM沙箱 API取代Mixer实现Istio的扩展。
背靠大树好乘凉
自打Google把Istio贡献给了开源社区，Service Mesh好像又出现了一边倒的情况。
跟当初容器编排领域的Swarm、Mesos和Kubernetes之争很像，还没等用户缓过神儿来，K8S就一统江湖了。
在国内企业技术转型的过程中，以SpringCloud和Dubbo为代表的微服务开发框架更受开发者欢迎。
潭主之前在跟和同事做调研交流时发现有个别项目团队已经进行了VM版的微服务改造。
这种微服务技术框架虽有优势之处，但带来的问题也不少，比如代码的侵入性强，升级成本高，也容易引发版本碎片化。
其实，即使没有微服务，在应用系统规模较大时本身就很容易出现版本基线的管理问题。说实话，很难治理。
而Service Mesh将应用的业务逻辑和微服务治理进行了解耦，貌似可以解决些问题。
把方便留给用户
目前，Istio已经成了主流PaaS平台的标配，像时速云这样厂商也做了相应的产品化，最后就看用户需求。
开源软件跟产品是两个概念，但有个好的用户操作界面，体验会好很多。
比如原本繁琐难记的yaml被页面封装了，再集成一个DevOps，CI/CD这种事也能变得轻松。当然，如果有追求也可以实践GitOps。
反正对潭主这种空有思想，不求甚解的用户来说，有个界面更容易上手。
补充点细节，Service Mesh的核心功能是流量管理：
流量管控：Istio引入了Version概念，可以对不同版本，用不同的权重进行流量调度，轻松实现灰度发布，同时也能通过Gateway实现边界流量控制。
弹性功能：熔断、超时和重试，通过添加timeout和retry关键字实现，而熔断需要在DestinationRule的Traffic Policy进行设置。
调试能力：故障注入和流量镜像，Istio支持延迟和中断两种故障类型，这部分跟混沌工程有些相似，通过配置fault和mirror关键字实现
Istio看上去复杂，用起来其实并不难。
做产品，把方便留给用户很关键。
Service Mesh，未来已来？
潭主早期玩OpenShift时，那会儿还没有Istio，但现在服务网格也不新鲜了。
最近跟时速云的人交流PaaS，听说大家保险已经部署了Service Mesh，不由想起了中国人寿和Rancher，潭主颇为感慨。
客观讲，保险行业的一些用户在新技术的应用上其实已经走在了前面，而且有了一定的规模，反观自身和OCP那点量，感觉只能用“可圈可点“来评价，没有规模，何来治理。
回首过去几年，从Dokcer到Kubernetes，再到Service Mesh，微服务和云原生演绎了波澜壮阔的三部曲。
未来已来，从去IOE到云原生，潭主“凿墙”的终极目标就是实现这种端到端的服务。
新技术应用需要信仰和情怀，重要的在于参与！
- END -
感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
