ServiceMesh入门的起点：构建一个微服务网关

本文是在看了国外 Solo 公司 CTO 的博客之后整理的，本来是想按原文翻译，但是考虑到我自己在公司实践的思路，还是想把他的思路和我自己的思路做一些结合。所以本文中有部分内容是来自这位高手的思考，也有有我在公司实践中的思考。

作者是从 Red Hat 跳到 Solo 公司的，这家公司现在主要产品就是基于 Envoy 和 Istio 的网络治理工具的研发，包括了微服务网关和服务网格上的产品。

他也是很早之前就在思考服务网格虽然很好（至少是思路和理念非常好），而且现在结合 K8S 也有了很好的实现和落地方式。但是人们对这个东西的认知和信心还是不足的，我看到的主要表现在这样一些方面：

1. Istio 等相关服务网格的产品还不够成熟，目前我重点关注 Istio 社区，也是社区 Member。目前看来 Istio 的代码都还在大幅度的变化，很多设计在不同的大版本中是不断调整的，这一点就不多说了。刚好这几天也发布了 1.6，不过我感觉 1.6 应该会好很多。

2. 大家直观的感觉是加了 sidecar 之后，网络调用多了一跳，性能会变差，甚至变得很差。

3. 大家对把服务网格作为基础设施这种想法还是比较抗拒，认为妨碍了他定位问题和提升应用性能。

4. 大家对于微服务框架开发的热情超过服务网格，很多人认为服务网格是一种微服务架构实现，所以自然的把微服务框架作为了服务网格的竞争对手。对于开发同学来说开发微服务框架的成就感要不直接使用服务网格这样的基础设施强很多。

以上这几个点就不展开讲了，大家应该能理解我的意思。这也是我这几年研究和落地服务网格中的一些难点，我认为这些难点随着时间的发展将不会成为问题，尤其我认为