关于Apinto可以改进的几个建议

dinstone

各位开发者，大家好。

Apinto是一个非常有趣、功能全面、性能强大的产品。它的开源相信不久的将来将会影响更多的开发者以及企业客户。这里，我毫不掩饰对它的喜爱，它真的是太棒了！

同时，我在使用中也发现了一些还需进一步打磨的地方。这里列举出来，希望大家一起关注、讨论并改进它。

1.产品介绍、帮助文档、教程文档中对产品核心概念介绍的不是很清晰，有的还很隐晦。比如最关键的几个概念，应用、API、服务。

”应用“ 在上面3个文档中有介绍，也说明了其作用，但是没有说明为什么这么抽象，这个抽象是必须得吗？它跟其它2个概念是什么关系。这里我的理解是，应用是对前端应用的抽象，即一切访问API Gateway的消费端应用。在这里可以做相应的边缘功能（认证、授权）实现，而应用是最佳的的业务隔离概念。可以统一为”前端应用“。
”API“ 3个地方表述不一致，教程是API，帮助文档是路由，UI上是API。我的理解是API更偏向说明对外暴露的Rest接口，至于绑定到那个后端的服务实现，是路由干的事，什么时机绑定是由产品的实现理念来决定的。我感觉Apinto不想严格区分他们，背后可能有其实现考虑。根据当前实现，可以统一为”API路由“。
”服务“ 3个地方中表述不一致，UI、教程是上游、帮助文档是服务。我的理解这个概念代表了应用的后端服务，可以统一为”后端服务“。
整个文档中没有看到对这三个概念的关系描述，建议整一个概念架构图，一目了然，而且可以解答很多读者和使用者的疑问。
UI指https://demo-dashboard.apinto.com/，教程指：https://help.eolink.com/tutorial，帮助指：https://help.apinto.com/docs/

2.UI中快速入门中产品图，有点别扭。

图最好准寻从左往右、从上往下看的原则，降低认知负担。
图上标的数字没有跟下面的操作步骤对应，而是通过概念对应的，但是概念又不那么一致。建议上下通过数字映射对应起来，同时统一整个文档的核心概念。

3.策略中的能力放在一起归类管理，看起来很好，但是从BFF模式视角看，业务隔离不清晰，有混乱之嫌，会让使用者害怕，担心是不是设置错误了。之前公司的设计思路是，将策略中的能力就近设置在”应用“、”API路由“、”服务“中，全局的可以设置在Gateway实例中。

以上，欢迎批评指正！

Dot

很抱歉，现在才看到您关于Apinto改进的建议。

非常感谢您对Apinto开源网关的支持，针对您上述问题，我在此做个简单解答：

问题1：

应用包含了一切访问API Gateway的消费端应用，但不能简单定义为 前端应用，前端应用 在理解上会有一定的歧义。应用的指代范围很广，比如，API交易相关的平台接入网关，应用可以指代一个企业，每个企业针对不同的使用者分配带有过期时间的Token，即应用的认证、授权功能，针对应用场景的不同，应用可能被赋予不一样的概念。

对于使用者来说，API 是更加简单明了的概念。API 包含了请求协议（HTTP/HTTPS、Websocket、gRPC、Dubbo等）、请求路径、请求参数、响应参数等等概念，路由定义比较狭隘，未来我们计划接入更详细的API文档时，API路由 的概念则有所限制，对于企业来说，都是以API为单位进行维护，API不只是接口，不只是路由，现在更是一种数字资产，因此 API 会更加适合。

业内一般对后端服务有个官方的定义：Upstream，翻译过来就是上游，因此在新版本控制台，我们沿用了上游这个概念。关于帮助文档不一致的问题，我们稍后做个修改，原意是上游服务。

概念架构图我们看看怎么表达合适，尽可能降低学习和使用成本。

问题2和问题3我将交给我们产品进行判断，看看是否进行进一步优化～

针对您的宝贵意见，我们将会优化我们的教程，让更多使用者快速上手，降低学习成本。

非常非常感谢！

dinstone

Dot 非常感谢你的回复。你的解答很大一部分消除了我的疑问，同时也使我更加谨慎的审视了自己的观点和表达。

首先，我的观点是基于微服架构的 API Gateway 模式来提出的。当然，主要理论和概念模型还是来自Chris Richardson大佬的理念：https://microservices.io/patterns/index.html。 API Gateway 是一个服务，它是外部API客户端进入基于微服务应用程序的入口点。也就是说，它封装了微服务应用程序的内部架构，为外部客户端提供API，对于内部客户端不提供API，如果提供服务，那么API Gateway就退化成了ESB了。

其次，我看Apinto的定位（Apinto是基于Golang开发的开源网关，实现了高性能 HTTP API 转发、API 访问权限控制等功能，能够快速帮助企业进行 API 服务治理、提高 API 服务的稳定性和安全性。）是API网关，应该是符合API Gateway模式的，也就是说，主要是为外部客户端提供API服务和相关治理的。

再次，基于以上的认识，我们讨论的一些概念都是架构相关的抽象，我们都知道架构是一门艺术。Apinto已经实现了很好的功能和性能，但在“艺术”层面上还是可以继续探讨和提升的。所以，这也是建议咱们这个阶段要重点考虑概念模型的原因。

最后，既然是概念模型的交流，基于你的答复提出一些新的看法，仅供参考：

你的答复，“应用” 是包含了一切访问API Gateway的消费端应用。这里的消费端应用我理解应该是指外部API客户端。这样的话，我之前提出的统一到“前端应用”的表达确实肤浅了。但是如果“应用” 如文档中的描述“应用是对请求来源的抽象概念，其可以是一个客户端App，也可以是一个后端服务，还可以是Web App……”（https://help.apinto.com/docs/apinto/app/），我觉得不应该包含“后端服务”，如果企业内部服务也直接通过API Gateway来访问的话，API Gateway就退化为中心化的ESB服务了，这个应该是违反微服务架构去中心化理念的。
关于API的答复，我能看出来，咱们之后还是想区分API和路由概念的。我看到和使用过的很多API Gateway，它们对API和路由抽象为n:1的关系，也就是说，对于一组API，可以通过统一的前缀路径定义一个代理路由，使得这一组API路由到一个后端服务。这样的话就能实现你说的，API是面向使用者的，是企业的资产，而是路由是面向实现者的，是Gateway的逻辑。
对于“upstream”的概念，更多的见于协议代理服务的业内叫法，如Nginx、HA等协议代理服务器。在微服API Gateway的实现中应该是借鉴过，但更多的是“后端服务”，因为API Gateway的主要职责不仅有API代理，还有API组合，所以在微服务架构模式下，“后端服务”比较贴合。当然，这是个艺术问题。😜

期待咱们能够做出强大的开源产品！谢谢！

Dot

感谢您的回复，您的见解非常值得我们进行探讨，能够从中吸纳许多想法。

是的，正如您所说，Api Gateway更多是外部API客户端进入微服务应用程序的入口点，主要是承载南北方向的流量。

而承载东西向流量（内部服务通信）主要是使用服务网格（Service Mesh）来实现，其界限应该是彼此分明的。

但随着发展，这两者的界限好像逐渐有点模糊，Api网关在一定的程度上也可以充当Service Mesh的功能，如代理转发、负载均衡、路由等。

在我们接触的一些企业中，也希望在内部部署API网关（实际应该是Service Mesh的工作），代理内部服务的转发等工作。

当然，我们在程序实现时，以API网关的方向进行实现，只是不排除像上述的应用场景。

关于APi的答复，正如您所说，API Gateway在设计时就定义路由的概念，支持前缀匹配、正则匹配等多种路由匹配方式，但这个多数是面向开发/实现者的，对于使用者来说，更多关心单一接口的调用情况，比如哪个API请求时间过长，哪个API不健康等等，使用者不界定于具有开发经验的人员，也可以是管理者等，咱们的控制台界面的初衷注重体验，也让更多人能够快速上手。

再一次感谢您的意见，也希望后续咱们能有合作，可以是功能需求上的协作，也可以对某些概念的思想上的交流与碰撞。

您也可以加入到咱们的用户交流群，咱们可以更加实时地进行交流。