Istio的实力非常强,我这里给了很多的赞誉:设计理念非常新颖前卫,有创意,有魄力,有追求,有格局。Istio的团队实力也非常惊人,大家有空可以去看看istio的委员会名单感受一下。Istio也是Google的新的重量级的产品,很有可能成为下一个现象级的产品。Google现在的现象级产品是什么?K8s。而Istio很有可能成为下一个K8S级别的产品。
说到应时而生,什么是势?我们今天所在的是什么时代?是互联网技术大规模普及的时代,是微服务容器如日中天的时代,是Cloud Native大势已成的时代。也是传统企业进行互联网转型的时代,今天的企业用户都想转型,这个大势非常明显,大家都在转或者准备转,但是先天不足。什么叫先天不足?没基因,没能力,没经验,没人才,而且面临我们前面说的所有的痛点。所有说Istio现在出现,时机非常合适。别忘了Istio身后还有CNCF的背景,已经即将一统江湖的k8s。
Istio在发布之后,社区响应积极,所谓应者云集。其中作为市面上仅有的几个Service Mesh之一的Envoy,甘心为Istio做底层,而另外两个实现Linkerd/nginmesh也直接放弃和Istio的对抗,选择合作,积极和Istio做集成。社区中的一众大佬,如这里列出来的,都在第一时间响应,要和istio做集成或者基于Istio做自己的产品。为什么说是第一时间?Istio出0.1版本,他们就直接表明态度开始站队了。
Istio的架构,主要分为两大块。下面的数据面板,是给传统Service Mesh的,目前是Envoy,但是我们前面也提到Linkerd和Nginmesh都在和Istio做集成,指的就是替代Envoy做数据面板。
另外一大块就是上面的控制面板,这是Istio真正带来的内容。主要分成三大块,图中我列出了他们各自的职责和可以实现的功能。
总结一下,Service Mesh这是一步一步过来的: 从原始的代理,到限制很多的Sidecar,再到通用性的Service Mesh,然后到加强管理功能的Istio,在未来成为下一代的微服务。
注意,离Service Mesh这个词汇出现的时间点,也才一年。
为何选择Service Mesh?
前面三个痛点都被解决了,有了Service Mesh之后这些问题都不是问题了。升级的痛点怎么解决?Service Mesh是一个独立进程,可单独升级,而应用程序不用改。
Service Mesh是以远程调用的方式让客户端接入,只要能发出请求,简单发给Service Mesh就可以。客户端极度简化,对于典型的Rest请求,几乎所有的语言都有完善的支持。而服务器端只要做一个事情,服务注册。这样对于多语言的支持,就变得非常舒服了。现在终于可以真正的自由选择编程语言。
这里有一个奇迹,鱼与熊掌兼得:同时实现降低门槛,功能增加。有些信奉质量守恒的同学会感觉不科学,注意能同时实现这两个改进的原因,是把工作量最大最辛苦的事情都交给了Service Mesh。而Service Mesh是通用的,可以反复重用的。
Service Mesh为业务开发团队带来的变革:降低入门门槛,提供稳定基座,帮助团队实现技术转型。最终达到的目的是,让业务开发团队从微服务实现的具体技术细节中解放出来, 回归业务。
第二个变革,是对运维管理团队的强化,这里如果有做运维的同学,你们可以认真思考一下:如果有了Service Mesh,你们对系统的管理和控制力会有多大的?注意很多功能的实现已经不再和应用有关,都在移到Service Mesh中,而Service Mesh通常是在运维的掌控中。
Service Mesh对于新兴小众语言是极大的利好。对于新的语言来说,在和传统的主流编程语言竞争时,最痛苦的事情是什么?是生态,比如各种类库,各种框架。在微服务这个领域,新兴小众语言想和Java等比拼,非常的难:这是用自己的劣势对上别人的优势。而有了Service Mesh之后,小众语言就有机会避开这个弊端,再不用和Java比拼生态,而是充分发挥自己的语言特点,做自己最擅长的领域。
公众号内回复mesh,下载本次分享PPT
作者:敖小剑
来源: https://juejin.im/entry/59fbab2151882576ea350afb