本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（3）——TCP协议扩展 前言 在2018年上半年，蚂蚁金服决定

本文由作者授权，转载自赵化冰的博客。 Istio作为一个service mesh开源项目，其中最重要的功能就是对网格中微服务之间的流量进行管理，包括服务发现，请求路由和服务间的可靠通信。Istio实现了service mesh的控制面，并整合Envoy开源项目作为数据面的sidecar，一起对流量进行控制。 Istio体系中流量管理配置下发以及流量规则如何在数据面生效的机制相对比较复杂，通过官方文

首先声明，我在RedHat工作，确切得说，是在3scale团队开发3scale API管理解决方案。最近，在跟我们的客户讨论时有个问题被越来越多的提及：使用了Istio之后，为什么还需要API管理？ 为了回答这个问题，我们首先要搞明白服务网格和API管理究竟是什么，剧透一下：3scale API Management和Istio可以共存。 让我们聚焦于3scale API Management和I

本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（3）——TCP协议扩展 前言 在Istio和Envoy中，对通

本文为翻译文章，点击查看原文。 最近的几次关于容器使用情况的调研都得到了相似的结果，开发团队不仅采用而且开始拥抱容器技术。大多数人并没有像超大型组织那样大规模的使用容器。在一项思科赞助的调研中发现有超过8000家企业在生产环境中使用容器。这听起来令人印象深刻，但他们使用容器的规模有限。在戴尔EMC，英特尔和红帽委托的Forrester报告中，63％使用容器的企业运行的实例超过100个，82％预计到

本文是SOFAMesh中的多协议通用解决方案x-protocol介绍系列文章之一。 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（1）——DNS通用寻址方案 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发 SOFAMesh中的多协议通用解决方案x-protocol介绍系列（3）——TCP协议扩展 背景 在Istio和Envoy中，对通

本文为翻译文章，点击查看原文。 在本文中，我将演示如何使用Golang来操作Kubernetes Custom Resources，以Istio为例。 不需要您了解Istio，我只是用它来展示概念！ Istio是一个非常受欢迎的服务网格平台，它允许工程师快速地为基于服务的应用程序添加遥测技术、先进的流量管理等功能。 Istio工作原理的一个有趣的地方是，当部署到Kubernetes集群中时，许多关

本文为翻译文章，点击查看原文。 你已经浏览了Istio Mixer Adapter的指南 ，现在想要发布自己的Adapter？这篇文章将教你创建自己的Adapter，在生产环境的海洋中扬帆起航。 Istio 介绍 根据你对Go、Protobufs、gRPC、Istio、Docker和Kubernetes知识有所了解，你可能会发现发布Istio Mixer Adapter的过程很容易。本文假设你对这

Istio 中有个 issue #9066 要求将 Istio 中默认使用的 Service Graph 替换成 Kiali。Kiali 最初是由 Red Hat 开源的，用于解决 Service Mesh 中可观察性即微服务的可视性问题。目前已获得 Istio 社区的官方支持。 关于 Kiali 单体应用使用微服务架构拆分成了许多微服务的组合。服务的数量显著增加，就对需要了解服务之间的通信模式，

由来 ​ 开发istio-ui是由于运维：到时候线上几百个istio配置文件管理会很麻烦。其实在开始接触istio的时候，我们其他同学就有这样的想法，当时大家都认为不久官方或社区就会有相应的产品出来。但等了几个月还是没音讯，所以我们就按照我们自己的需求开发了istio-ui，并且开源。当然现在还是一块滑板。离奔驰还需要慢慢雕琢。 在这个基础上，结合我们当前服务环境，增加了：校验，注入，模板等功能。

本文为翻译文章，点击查看原文。 在Istio和相关技术持续获得增势之时，中间件在Service Mesh中的地位正在逐渐减弱。尽管它们都可以用来监管不同应用和服务之间的通信，但是在运维和范式方面却大不相同。在今天以容器为中心的世界里，面向服务的架构体系盛行，中间件会变得无关紧要吗？ 中间件 中间件将应用和它底层的数据库连接起来，因此常被称作“软件胶水”。它将客户端的网络请求连接到后端数据，通过将所

本文为翻译文章，点击查看原文。 Istio通过虚拟服务, 目标规则, Gateway等概念提供了复杂的路由机制。Istio 1.0通过加权路由定义启用了HTTP流量转移。我提交的Envoy 和Istio的pull request为TCP/TLS服务提供了类似的特性。这一特性已经在Envoy 1.8.0中发布了。Istio中的这一特性也会在即将发布的1.1.0版本中提供使用。 Istio 在本文中，

用Istio治理服务时须通过istioctl或kubectl，这种方式可能存在一些问题。因此小米武汉研发中心推出Naftis，帮助用户更轻松地管理Istio。 近年来服务网格（Service Mesh）已成为各大公司关注重点，各大公司纷纷开始调研Service Mesh相关架构。作为Service Mesh中的佼佼者，Istio诞生之初就已吸引众多目光。 作为基础设施层，Istio有优秀的服务治理

介绍 自从istio-1.0.0在今年发布了正式版以后，Coohom项目在生产环境中也开启了使用istio来作为服务网格。 本文将会介绍与分享在Coohom项目在使用istio中的一些实践与经验。 Coohom项目 杭州群核信息技术有限公司成立于2011年，公司总部位于浙江杭州，占地面积超过5000平方米。酷家乐是公司以分布式并行计算和多媒体数据挖掘为技术核心，推出的家居云设计平台，致力于云渲染、

当Istio 1.0在几个月前发布时，TechCrunch称它为“可能是目前最重要的开源项目之一”。它并不是完美的(在本系列的第2部分会有详细介绍)，但是这个版本标志着服务网格架构开发的一个重要里程碑。 尽管对Istio的发布给予了关注，但是，在开源社区服务网格还是不为人知。在这两篇文章中，我们首先提供一个窗口让读者了解服务网格的功能，然后在第二部分，展望在不久的会有何收获。 关于服务网格，有一件

本文为翻译文章，点击查看原文。 本文最初发表于2017年5月24日。 随着大量新平台和支持工具的出现，云原生势头正在增长。 这些新平台为开发人员提供了越来越多的功能 ，可以以自动化的方式快速开发，部署和管理大量微服务。 但这种云原生的势头的增长同样会伴随着成本的增加，最好做好为此付出代价的准备。 最近我写了一篇由Kubernetes等云原生平台提供的“为开发者准备的新的分布式原语”，以及这些原语如

本文为翻译文章，点击查看原文。 Kubernetes 不仅仅是一个容器管理工具。它是一个平台，旨在处理包装在任意数量的容器和组合中的各种工作负载。Kubernetes内置了多个控制器，可映射到云原生架构的各个层。 DevOps工程师可以将Kubernetes控制器视为指示团队运行的各种工作负载的基础架构需求的手段。他们可以通过声明方法定义所需的配置状态。例如，容器/pod作为Replication

本文为翻译文章，点击查看原文。 在服务网格系列的第一部分中，我们认为服务网格是微服务体系架构发展的必然和有益的结果。随着 Istio 1.0 的发布，我们在服务网格领域已经经过了一个重要的里程碑，在这个重要的的时间节点上，我们需要思考服务网格的未来将如何发展。 在 VMware 我们非常愿意花时间和精力支持开源的服务网格架构。我们已经成为 Istio 和 Envoy（Istio 用来动态控制微服务

本文为翻译文章，点击查看原文。 速率限制是缓解级联故障和防止耗尽共享资源的一种简单有效的方法。Envoy 是一个功能丰富的代理，可以为任何服务轻松添加速率限制的功能。本文将介绍在不更改应用程序本身配置的前提下如何配置 Envoy 来强制对应用进行速率限制。 问题 你是否遇到过资源被大量的请求淹没或耗尽的情况？你的客户端是否具有回退重试或速率限制的逻辑？在微服务架构中，不对其使用量进行限制的资源很容

gateway定义用于配置在mesh边缘，到mesh的tcp和http的负载均衡。 非TLS单主机环境 相关拓扑 使用azure aks环境。 ingress gateway的service类型为loadbalancer。 ingress gateway的service enternal ip为104.211.54.62。 通过该external ip对应的域名，访问ingress gateway