公众号文章同步: istio 的目标是去掉中心化网关吗？
本篇目录
首发于微信公众号「我的网课」：istio 的目标是取代中心式网关？。
最近集中精力学习 istio，把 istio 能做的事情梳理了出来，每个功能试验了一下。istio 创造的新名词不少，有些复杂，上手需要一定时间。
盘点了 istio 能做的事情后，略感尴尬，大部分功能，我们已经实现了，监控和日志是最基本的，金丝雀发布、请求头改写、限速、黑白名单、调用链跟踪等等，也七拼八凑地做到了。
那么 istio 还能给我们带来什么？为什么要往这个方向走？操作 istio 的过程中，不停地思考。
从做事习惯来说，程序员不可能消停下来，做好一套系统之后，每天安枕无忧地睡大觉，或者逛街遛狗，是不可能的。总要折腾些事情，尝试新东西、试验新思路。但是这个理由，只能让掏钱的老板带着板砖杀过来。
从技术角度来说，istio 和广泛应用的服务框架相比，最大的特点就是无侵入，不需要在应用程序中植入代码。所以接下来的技术发展方向，是用无侵入的方式实现已有的服务框架的各种功能吗？带来的收益就是无需植入代码？
在无侵入的方向上深耕是正确的，让事情越来越简单，就是技术的目标。不过，再次审视 istio 的功能时，突然发现：服务框架能做的很多事情，istio 做不到啊？旁路代理有天生的局限，和植入代码相比，能做的事情少太多了。
或许 istio 的意义就是整合 kiali、jaeger 等各种工具，形成一个用起来比较流畅的套装，让更少的人能做更多的事？好像有这个好处，但是说服力依旧不够强。
疑惑堵在心口，继续扒拉 istio 的文档，一篇 17 年的博客，让我豁然开朗，原来 istio 的目的是替代中心式网关！
大概意思是说，Google 很早就开始用内部网关管理大量的 API，支撑了 Gmail、YouTube、Google Maps 等全球性服务，峰值 QPS 是 hundreds of millions。内部网关工作的挺好，但是随着 Google 快速增长，需要重新设计一下，抑制像热气球一样膨胀的运营成本！
不太理解 Operational costs 指的是服务器成本还是人力成本，拍脑袋推测，Google 的内部网关是一个硕大无比的中心系统，聚合了内部所有服务的接口，所有的流量都先汇聚到网关，再由网关向外分发。
大概是这样一种情景，千军万马来相会：
2014 年，Google 的工程师想改变这种情况，寻找一种更好的方式。最终他们决定改变中心式设计，弃用 heavy proxy，改用伴随在每个服务单元身边的 thin proxy，也就是 sidecar：
最终实现这样的效果：
将 heavy proxy 拆分成无数个 thin proxy 的好处是显而易见的，流量无需汇聚，可以走小路到达目标地址，网络的利用率大大提高。挑战也是显而易见的，分散在各处的 thin proxy 要如何管理？怎样防止核心组件故障瘫痪整个网络？怎样避免级联故障摧毁整个网络？
博客中介绍了整体的设计思路，其实也就是那么几种做法，thin proxy 独立工作，在没有大脑的情况维持现状，控制信息处处缓存，减轻控制节点压力。最终效果主要取决于工程实践能力，isito 的 mixer 号称 99.999% 可用。
目标是取代中心式网关，这样一来，堵在心口的疑惑也解开了。istio 的很多功能我们的确实现了，而且恰好采用了中心式设计，所有的请求都通过同一组 proxy 转发，相比之下，istio 的分布式设计是更先进的方案。Google 的行为告诉我们，达到一定量级以后，分布式方案在成本方面更有优势。
另外，istio 是 api 网关，不是服务框架，它和服务框架的关系是互补而非替换，不能强求现阶段的 istio 完成服务框架的任务。如果说以后的 istio 能够彻底顶替服务框架，那么 istio 的功能也可以下沉到 kubernetes，下沉到网络组件。50 年太久，只争朝夕。
现阶段理解就是这样的，继续学习。阅读原文是学习过程中记录的笔记，能为后来人节省非常多的时间。网页托管在境外，第一次打开可能慢，甚至打不开，第二次可以。
参考
