翻译|宋松
原文| https://medium.com/solo-io/linkerd-or-istio-6fcd2aad6e42
本周我开始写一篇比较Istio和相关的帖子,并且告诉我自己:我将用一个表格来比较两者的特性,这将会很棒,人们会爱上它,这个世界将会幸福几秒钟。我向自己承诺这将是一个公平的比较,没有任何偏见。虽然比较的表格仍然存在,但我转移了文章的终点:目标不再是哪个更好,而是哪个更适合你,你的应用程序和你的组织。
在职业生涯的一段时间中,我曾担任某公司的售前架构师,记得有很多次我们被要求填写产品比较表。我经常需要运用创造力来确保产品看起来很好,几乎不惜一切代价避免表格中令人不愉快的“不支持”的框。考虑到诚信工作,但是有时候不得不这样做。
站在评价者的角度来看,我理解他们(希望)的目的是进行公平的比较,在这种程度上,对比的表格似乎是一种可靠的方式。我们知道一个项目的成功可以预测职业的发展,我们都喜欢这一点。但问题是:如果评估的最终目标是产品对比表格,而不是能让企业更有竞争力的高质量软件,那么这个评估的最后将只是一些“表格”的工作。
产品比较并不是最终目的,通过比较知道哪些对你的用例最好才是最终目的。因此让我们通过七个方面来深入研究服务网格,主要是以下几个方面:
-
<李>
流量管理
李 <李>安全 李 <李>
安装/配置
李 <李>支持的环境
李 <李>监测 李 <李>
策略管理
李 <李>性能李对于上述七个方面中的每一个,我都将发表个人观点,希望我的观点能够帮你做出更接近于简洁的决策。
流量管理
需要强调的是,Istio和Linkerd的区别在于数据平面使用了两种不同的代理技术。
Istio使用特使作为其代理.Envoy是c++编写的,最初是由Lyft构建,以便以非Kubernetes方式促进微服务的流量管理。许多公司已经将特使扩展为Kubernetes的入口技术。
Linkerd (v2)使用的是一种名为Linkerd-proxy的专用服务网格代理。这个代理是使用锈编写的,与该代理一起,许多低级代理(网络客户机与服务器)功能在另一个也是由铁锈编写名为塔的项目中实现.Tower依赖于东京,东京是一个由铁锈编写的事件驱动非阻塞I/O库。如果你和我一样欣赏统计学,那么生锈已经连续四年(2016、2017、2018、2019)一直是堆栈溢出最受欢迎的语言。
