tyk评价

简介

tyk是一个开源的api gateway，分为两个部分，一个是tyk gateway，一个是tyk dashboard。
相比于其他同类产品，其包含的功能最全面，开源程度最高。

需求

api gateway的好处是，作为一个统一的网关，其用来管理所有api，可以使得这些api共用同样的鉴权系统，限流方式，统计方式等。而不需要每个api单独开发这些必备的功能。另外统一管理还可以为服务注册、服务订阅提供方便。比如某人想要申请访问其他api，可以主动提供申请，然后api创建者通过邮件来审批，审批通过api gateway自动允许这个人访问。

api gateway通常还和其他api design和api management工具结合使用，比如swagger, api blueprint。如果第三方工具本身很好用的话，确实结合使用能提高很多效率。

坑

在安装和尝试tyk之后，最终还是决定放弃改用其他，主要遇到的问题在这里简单介绍。

安装

tyk的安装有很多种方式，它有ubuntu的apt-get repository，但是用来一个国外的源，导致apt-get update一直失败，安装不成功。最后用docker的方式安装成功。最后安装了4个docker容器，redis，mongo，tyk-gateway，tyk-dashboard，并且还通过tyk-quickstart项目才完成了安装和初始化，外加各种域名的设定，使得其安装过程很繁琐。

uptime

tyk可以监控api的存活时间，但是测试后发现并没有实际监控到。

分析

dashboard的统计报表功能十分鸡肋，并且不能自定义，导致想按照ip地址统计，都无法进行操作。这个相比es来说弱了太多。但是又没法选择展示统计的方式，只能使用默认提供的。

key管理

key的申请和管理十分反人类。首先不能看到所有的key的列表，需要知道key，然后去查询和修改这个key。并且key可以通过用户名密码方式生成，也可以通过随机生成，jwt等，这些方式生成后又可以修改，比如用户名密码生成的，修改成token方式，发现用户名密码方式还是生效。按理说key管理应该有简单统一的方式，就像网站的用户注册一样。

portal

portal是用来展示和分享和申请api的地方。但是portal首先通过域名和api代理的方式到一个随机串的地址。并且这个跳转还经常失效，导致一直没有怎么成功架起来过portal。

总结

我个人的评价可能并不公正，tyk的很多功能并没有试用，而且研究也不深。但是从设计思想上来说，感觉tyk并不适合我们试用。它虽然功能很全，但是每个功能并没有做到很好，而且这些不好的功能并不能替换。而很多时候，我们都是通过组合不同领域最好的工具，来完成一个项目。比如负载均衡用xxxx，收集日志用xxxx，展示分析用xxxx。tyk给我们的限制太多，我们宁愿使用一个简单的api-gateway，然后结合各种不同的工具来完成tyk提供给我们的功能，也好于直接使用tyk。