今天，我们很高兴地公布Kong 1.0[1]的通用版本——这是一款可扩展、快速且开源的微服务API网关，可用于对混合及云原生架构进行管理、保护与连接。Kong运行有全部服务之前，并可以通过多种插件实现扩展，例如身份验证、流量控制以及可观察性等等。
在此次1.0版本发布当中，我们继续承诺提供良好的向下兼容性。经过多年的发展以及成千上万生产级用户的支持，我们在本次版本中增加了多项重要功能以及大量修复工具，这使得Kong的速度、灵活性以及弹性表现得以全面提升。下面具体来看：
Service Mesh
在1.0版本当中，用户现在不仅能够以API网关的形式部署Kong，同时也可以将其作为独立的service-mesh代理。Kong插件能够为Service Mesh提供开箱即用的关键功能，亦能够与其它多种云原生技术相集成，具体包括Prometheus、Zipkin、健康状态检查、金丝雀测试以及蓝绿测试等等。
相互TLS（简称mTLS）与TCP
在1.0版本当中，Kong集群能够创建一个Certificate Authority，可供各Kong节点用于彼此之间建立起相互TLS。除此之外，Kong现在还能够对原始TCP流量进行路由，这意味着Kong如今可以对来自邮件服务器以及其它基于TCP类应用程序（从L7到L4）的流量进行负载均衡。
gRPC
除了REST之外，Kong 1.0版本现在还支持gRPC协议。立足于HTTP/2之上实现的gRPC支持能够为希望更低成本与更低延迟实现东西流量连接的Kong用户带来新的选项。值得一提的是，这个新选项特别适合用户在混合环境下开启更多网格部署这类场景。
新的迁移框架
Kong 1.0引入了一个新的数据库抽象对象（简称DAO），其能够显著简化由一种数据库模式向另一种数据库模式的迁移流程，且停机时间几乎为零。新的DAO允许用户一次性完成自有Kong集群的升级，且无需手动干预各个节点的具体升级操作。
插件开发套件（简称PDK）
PDK包含一组Lua函数与变量，可由定制插件用于在Kong上实现自己的逻辑。尽管PDK早在0.14.0版本当中就已经出现，但此次1.0版本中的变更承诺由该PDK构建的插件将完全与Kong 1.0以及其它后续版本相兼容。
100多项功能与修复
感兴趣的朋友可以点击此处[2]在变更日志当中查看各Kong发布版本中的全部变更。此外，本次1.0版本中亦出现了许多重大变更，因此请务必点击此处[3]阅读1.0版本的建议升级路径。
虽然我们今天承诺Kong项目将运行稳定且向后兼容，但Kong距离其发展的终极目标还有很长的道路要走。我们很高兴能够与大家共同建设该项目以及技术社区！我们感谢社区为实现1.0版本这一里程碑所提供的全部支持，也期待着未来能够继续携手、共同发展。
请随意体验Kong 1.0，并与我们沟通您的想法与感受。
自从我们四年之前对Kong项目进行开源以来，全世界数百名Kong贡献者对Kong代码库做出了无数次改进。如果没有这些改进，如今的Kong 1.0版本根本不可能成为现实。在我们详尽介绍1.0中的各项新功能与修复之前，首先要感谢那些帮助我们一步步走到今天的Kong用户、贡献者以及项目背后无比强大的社区。当初我们刚刚决定开源Kong时，完全无法想象以其为中心能够建立起如此惊人的社区环境，而且我们的社区目前仍在不断增长！Kong项目的构建充分考虑到混合世界的发展愿景，而Kong 1.0版本的发布则代表着实现这一愿景的关键性一步。与我们的社区一道，我们对平台架构做出了重大调整，包括支持Service Mesh的能力——这将使得我们的用户能够处理跨供应商、跨环境以及跨生态系统的任何部署任务。展望未来，请大家放心，我们正在努力践行进一步支持更多新兴生态系统的承诺。
——Kong CTO Marco Palladino。
现在，我们将深入了解1.0版本当中的一些新功能，以及它们将给整个社区带来的影响。
在1.0版本当中，用户们现在可以将Kong以独立Service Mesh的形式进行部署。凭借挎斗代理（sidecar proxy）带来的更佳可见性、安全性与弹性，Service Mesh将有能力协助解决微服务所面临的一系列挑战。除了这些优势之外，与其它供应程序相比，Kong的Service Mesh还拥有另一些关键性特征——而这一切，都源自我们在其中引入了与边缘位置挎斗代理相同的运行时。
立即开始
利用Kong，您可以立即将边缘使用的相同功能扩展至网格当中。通过将Kong部署在与运行服务的容器相同的主机之上，用户将能够按照自己的进展轻松将服务不断移动到网格内。
无缝连接
您可以将网格当中的服务，接入来自各类环境、平台以及供应商的其它服务。利用Kong，用户能够桥接云原生设计以及传统架构模式之间的鸿沟，且完全无需变更服务代码。
强大的插件库
我们的插件架构为用户提供了无与伦比的灵活性。Kong插件提供关键功能的开箱即用能力，同时亦支持同其它云原生技术的无缝集成，具体包括Prometheus以及Zipkin等等。插件在各服务中以本地方式运行，不需要中转至另一组件或者由此带来的复杂额外网络请求。
低延迟
Kong项目及其插件也针对性能做出了优化。其它平台可能会在容器网络网格中的各服务之间带来额外延迟，但我们带来的额外延迟将低于1毫秒。
相互TLS与TCP支持能力
Kong对于Service Mesh的支持，是建立在各Kong实例之间相互传输层安全性（简称TLS）以及对插件运行循环的修改基础之上的。正是这些调整，使得Kong项目能够对服务中的每个实例进行逐一部署、在服务之间进行信息代理，同时随着这些服务的扩展而自动扩展。Kong集群会建立一个证书颁发机构，Kong节点将利用它来彼此建立相互TLS身份验证机制。
凭借着新的mTLS支持能力，Kong的核心路由程序现在已经能够对原始TCP流量进行路由。这意味着，用户现在可以利用Kong对来自邮件服务器以及其它基于TCP类应用程序的流量进行负载均衡。
数据平面与控制平面相互分离
Kong 1.0版本允许用户在其Kong配置当中指定彼此独立的控制与数据平面。在以往的版本当中，大家需要单独配置各个集群的数据与控制平面，但现在用户已经可以立足单一中心位置进行变更，且该位置将能够反映在多个Kong集群当中。这种数据与控制平面彼此独立的配置方式，允许Kong用户更好地控制大型部署体系。此外，由于允许用户在防火墙之后保护Kong配置且仅公开数据平面，这种分离机制还将显著提高部署成果的安全性水平。
插件开发套件
我们之所以有信心将此次版本定性为1.0，一大原因就在于其中的插件开发套件（简称PDK）。如今，插件的可扩展性在设计之初就将被纳入Kong的设计标准当中，PDK的存在使得插件构建工作变得更为轻松且安全。尽管PDK早在0.14.0版本当中就已经出现，但此次1.0版本中的变更承诺由该PDK构建的插件将完全与Kong 1.0以及其它后续版本相兼容。
PDK包含一组Lua函数与变量，可由定制插件用于在Kong上实现自己的逻辑。与从零开始编写插件相比，现在的新方案拥有多项优势，其中包括：
标准化
全部Kong插件都必须满足一套标准功能，即PDK提供的开箱即用功能。这既节省了开发人员的时间，又保证在PDK之上编写的插件拥有相似的执行方式（包括相同的解析规则以及相同的错误等等），从而降低使用难度。
易用性
PDK的接口相较于裸机ngx_lua API更为易用。此外，PDK还允许用户将自己的插件操作（例如日志记录或缓存）与其它插件隔离开来。
兼容性
本次发布的PDK实现了语义版本化，旨在实现向上兼容性。着眼于未来，这些插件将能够锁定至其所需要的PDK版本。
这里建议大家参阅插件开发套件指南，或者查看我们发布的PDK深度说明以了解更多信息！
为了确保数据平面的性能水平高于Service Mesh以及其它分散化架构的要求，我们对插件的运行循环做出了一系列改进。下面，我们将具体介绍其中一些改进及其对性能产生的影响。
预读执行
各插件现在可以在新的预读阶段当中执行代码。这意味着Kong用户可以在TCP连接初始建立时对各插件进行初始化，从而提高性能表现。
网关与网格配置
所有插件都将获得一个新的字段，即run_on，其负责控制各插件在Service Mesh以及“常规API网关”模式下的激活行为。这一机制能够更精细地控制插件活动，从而避免冗余并进一步提高性能水平。
AWS Lambda与Azure FaaS
Kong 1.0版本还对面向AWS Lambda以及Azure FaaS的交互机制做出了重大改进，其中包括Lambda代理集成以及面向Azure Functions插件的改进（此项改进用于在将HTTP/1.1响应代理至HTTP/2客户端时，对HTTP/2所禁用的各报头进行过滤）。
相关链接：
https://github.com/Kong/kong/releases/tag/1.0.0
https://github.com/Kong/kong/blob/master/CHANGELOG.md#100
https://github.com/Kong/kong/blob/master/UPGRADE.md#upgrade-to-100
原文链接：https://konghq.com/blog/kong-1-0-ga/
467
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
