本文为翻译文章，点击查看原文。 现代服务网格架构提供了很多的新功能，基础设施相关的依赖部分被逐步从代码中移除，极大的降低了编码工作量。除此之外，这一架构的智能路由功能还把金丝雀发布以及类似功能大大的简化了。 接下来的内容会探讨一下，Istio 路由规则是如何使用 OpenTracing Baggage 的。 Isto路由规则 想像一个场景，这个场景中我们需要通过 User-Agent Header

Istio 为网格中的微服务提供了较为完善的安全加固功能，在不影响代码的前提下，可以从多个角度提供安全支撑，官方文档做了较为详细的介绍，但是也比较破碎，这里尝试做个简介兼索引，实现过程还是要根据官方文档进行。 Istio 的安全功能主要分为三个部分的实现： 双向 TLS 支持。 基于黑白名单的访问控制。 基于角色的访问控制。 JWT 认证支持。 首先回顾一下 Istio 网格中的服务通信过程： 利

本文转载自敖小剑的博客 经过前面基本概念和实现原理的介绍，大家对mixer check cache应该有了基本的了解，下面我们开始展开源代码来细细研读。 Check Cache的主要流程 Check Cache的调用入口 对mixer cache的调用在代码 proxy/src/istio/mixerclient/client_impl.cc中的方法Check()中，此处跳过quota cache

本文转载自敖小剑的博客 接前文，继续分析Mixer Check Cache的源码，这次的重点是签名算法，也就是Referenced::Signature()方法。 前情回顾： Referenced保存的是mixer adapter使用的引用属性的一个组合，也就是前面例子中的 “a,b,c”或者“a,b,c不存在” Referenced中有两个数据结构： std::vector<Attribu

本文为翻译文章，点击查看原文。 Istio已经成为一种流行且可靠的服务网格管理平台，使用它可以更轻松地部署、操作和扩展跨云部署的微服务。作为保证这些服务网格的一种方式，Twistlock已经与Istio集成，以丰富平台的连接机器学习功能。 Twistlock通过使用Twistlock数据来隔离受损服务并提供合规策略来执行安全配置，以及Istio运行的其他堆栈。 随着云原生成为构建和运行现代的基于W

本文为翻译文章，点击查看原文。 如何确保微服务之间网络通信的可靠性、安全性和可管理性？ 使用服务网格吧！ 在过去一年中，Istio服务网格技术引发关注度和吸引力的持续提升，这是一件非常有趣的事情。 事实上，在我写这篇文章时，Istio仅为0.8版本，但对于最近两届KubeCon/CloudNativeCon活动而言，它一直是热门话题，仅在丹麦的活动中就有超过十几个不同的活动议题。 那么它为什么会这

黄挺在GIAC演讲 蚂蚁金服在服务化上面已经经过多年的沉淀，支撑了每年双十一的高峰峰值。Service Mesh 作为微服务的一个新方向，在最近两年成为领域的一个大热点，但是如何从经典服务化架构往 Service Mesh 的方向上演进，中间可能会遇到什么样的问题，几乎没有可以借鉴的经验。 本文会给大家分享 Service Mesh 在蚂蚁金服的演进历程和在2018年6月举办的 GIAC 全球互联

UCloud 作为一家To B的公有云服务商，我们的CTO莫显峰经常说：“研发团队最首要的任务是提供稳定的服务，然后才是提供符合客户需求的、易用和低成本的产品”。但事实是，在提供稳定云服务的同时，面对快速发展的客户业务场景，我们还需要不断 “拥抱变化”。 Max Kanat-Alexander 在《简约之美：软件设计之道》（Code Simplicity）中提出的软件设计的 6 条法则恰到好处的描

本文为翻译文章，点击查看原文。 在接下来的几个月中，我们将撰写一系列文章来记录从传统负载均衡器到谷歌Kubernetes引擎（GKE）之上服务网格的WePay工程化之路。 在本系列的第一部分中，我们将看看曾使用过的一些路由和负载均衡选项并将它们与服务网格代理进行比较，以及它们是如何改变我们基础设施的运行方式的。 数据面板使用sidecar代理模式 图1.数据面板使用sidecar代理模式 图1显示

这个原文是 5 月初发表的日文原文的翻译。补充一下这篇文章的背景，Cookpad 是一家拥有 200 多种产品开发的中型科技公司，拥有 10 多支团队，每月平均用户数量达到 9000 万。https://www.cookpadteam.com/ 你好，我是来自生产团队的开发人员Taiki。目前，我想介绍一下在 Cookpad 上构建和使用服务网格所获得的知识。 对于服务网格本身，我认为您将对以下文

本文为翻译文章，点击查看原文。 Aspen Mesh的Andrew Jenkins说，转向微服务本身并不能消除复杂性。 在本文中，我们与Aspen Mesh的首席架构师Andrew Jenkins谈论了如何从单一应用程序转向微服务，并通过一些关于服务网格的宣传来管理微服务架构。有关服务网格的更多信息，请考虑参加于2018年5月2日至4日在丹麦哥本哈根举行的KubeCon + CloudNative

vistio全局级别可视化视图 本文为翻译文章，点击查看原文。 Vistio GitHub地址：https://github.com/nmnellis/vistio Vizceral是Netflix发布的一个开源项目，用于近乎实时地监控应用程序和集群之间的网络流量。Vistio是使用Vizceral对Istio和网格监控的改进。它利用Istio Mixer生成的指标，然后将其输入Prometheu

正如我之前所说的，在如此短的时间内，Envoy 带来的兴奋既神奇又震撼人心。我经常问自己：envoy 的哪些方面导致了我们所看到的异常的社区增长？虽然 Envoy 具有很多引人注目的特征，但最终我认为有三个主要特征在共同推动： 性能：在具备大量特性的同时，Envoy 提供极高的吞吐量和低尾部延迟差异，而 CPU 和 RAM 消耗却相对较少。 可扩展性：Envoy 在 L4 和 L7 都提供了丰富的

本文转载自nino’s blog。 本篇总结pilot的xDS常用接口，顺便浏览了部分pilot实现，下篇总结下istio的流量管理和服务发现的实现。简单来说istio做为管理面，集合了配置中心和服务中心两个功能，并把配置发现和服务发现以一组统一的xDS接口提供出来，数据面的envoy通过xDS获取需要的信息来做服务间通信和服务治理。 api v1 reference Istio中部署pilot的

本文为翻译文章，点击查看原文。 Docker 和 Kubernetes 为代表的容器技术炙手可热，熟知这一技术领域的用户，一定都知道下一个热点：Service Mesh，它承诺将微服务之间的内部网络通信均一化，并解决一系列监控、故障隔离等通用非功能性需求。底层的代理服务器技术是 Service Mesh 的立身之本，这种技术在 Service Mesh 之外，还能以 API 网关的形式在边缘为业务

多租户是一个在各种环境和各种应用中都得到了广泛应用的概念，但是不同环境中，为每租户提供的具体实现和功能性都是有差异的。Kubernetes 多租户工作组致力于在 Kubernetes 中定义多租户用例和功能。然而根据他们的工作进展来看，恶意容器和负载对于其他租户的 Pod 和内核资源的访问无法做到完全控制，因此只有“软性多租户”支持是可行的。 软性多租户 文中提到的“软性多租户”的定义指的是单一

本文为翻译文章，点击查看原文。 关键点 服务网格框架用于处理服务间的通信，并提供连接、管理和保护微服务的平台。 服务网格通过处理需要复杂编码的功能来帮助应用程序开发人员，例如路由决策，这些决策在网格层级完成，而不是在应用程序中完成。 它还提供了可以编入网格的安全策略。例如，您可以设置一个策略，以限制网格中某些服务的入站网络流量。 像Istio这样的服务网格可以在Kubernetes平台上无缝工作，

本文为翻译文章，点击查看原文。 更新 感谢 Laurent Demailly 的评论，这里有一些更新。这篇文章已经得到了更新： 现在有一个 Cert-Manager 官方 Helm chart Istio Ingress 也支持基于 HTTP/2 的 GRPC Istio Istio 是管理微服务世界中数据流的一种新方式。事实上，这对我来说更是如此。人们不停的谈论微服务与单体应用，说微服务更好开发

本文为翻译文章，点击查看原文。 通过使用 Istio Service Mesh 来保障 Kubernetes 平台服务。通常可以运行示例代码有助于用户更清晰的理解并将概念应用到实际的案例中。该项目围绕一个简单的 Node.js 应用程序演示了以 Istio Service Mesh 为 ETCD 的持久化数据服务的能力。 Istio 背景 Istio 是一个 连接、管理以及保障微服务的开放平台。如

在计算领域，速率限制通常用于控制服务发起或消耗的操作速率，或者是请求发送或接收的流量。如果你有一年以上的软件开发经验，那么你应该会遇到这个概念。但是，和很多软件架构所面临的挑战一样，比起实际出现的问题，需要思考的问题会更多。本文概述了现代分布式应用程序中的一些关于速率限制的实现方案、优势和挑战。 为什么需要速率限制？ 实现速率限制主要是由于以下三个原因：通过资源节制防止（有意无意的）拒绝服务，限制