ServiceMesh入门的起点：构建一个微服务网关
本文是在看了国外 Solo 公司 CTO 的博客之后整理的，本来也是想按原文翻译，但是考虑到我自己在公司实践的思路，还是想把他的思路和我自己的思路做一些结合。
【译】发布可扩展和改进的 webassembly hub，帮助 envoy 和 Istio 使用 webassembly 的能力
就像用户们都想采用基于 Envoy 的基础设施来解决微服务通信带来的挑战，他们都不可避免的呃发现他们必须开发一些定制的技术功能来适配解决内部的限制性问题。
【译】重新定义代理的扩展性：介绍 Envoy 和 Istio 中的 WebAssembly 应用
翻译 Istio 官网 blog 文章，原文：https://istio.io/blog/2020/wasm-announce/。 翻译几天了，不过官网git提交有
【译】2020 年的 Istio - 顺风而行
在 2020 年 Istio 有更雄伟的目标，并且很多重大工作已经在进行了，但是同时我们也坚信好的基础设施应该是“无知”的。在生产中使用 Istio 应该是一种无缝的体验。
API 网关和服务网格功能定位比较
上一篇文章介绍了服务网格和 API 网关的使用场景和如何配合使用，这篇文章继续介绍，再把服务网格和 API 网关的区别和应用场景进行挖掘。
【译】以 Istio 为例来看什么时候不要拆分微服务
作者过去5年来都在投入和帮助团队组织进行云原生开发。优化提升团队（甚至是公司）加速软件交付的技术是严重首人员，过程甚至是技术决策的影响。在应用程序架构成为软件交付瓶颈的时候（由于人员/流程/技术等因素影响），微服务算是一种合适的解决方案，它可以快速的做出修改。但是这也不是唯一的途径。
【译】Kubernetes 服务网格: Istio, Linkerd 和 Consul 大比较
云原生应用通常是由一组运行在容器中的分布式微服务架构起来的。目前越来越多的容器应用都是基于 Kubernetes 的，Kubernetes 已经成为了容器编排的事实标准。
什么是ServiceMesh
说到istio就要先说什么是ServiceMesh，从英文直译过来就就叫做“服务网格”，这个技术大概是在10多年前就被提出来的，但是最近2年被炒的异常火热。那什么叫做ServiceMesh呢？