API 网关选型及包含 BFF 的架构设计( 二 ) 一背景介绍下图是我从网络上找到的一个

比较了一下，目前最火的应用是Kong ，另一个国产的 APISIX 趋势也是很猛，且他们的技术栈雷同，所以我在选型上找到了APISIX的作者做的对比：
从 API 网关核心功能点来看，两者均已覆盖：
文章插图
更详细的比较：
文章插图
通过性能测试可以看到，在不开启插件的情况下， Apache APISIX 的性能（QPS 和延迟）是 Kong 的2倍，但开启了两个常用插件后，性能就是 Kong 的十倍了。
无论从性能、可用性、可编程代码量等各个维度APISIX都是非常优秀的，目前唯一担心的就是这种早期项目没有太多大规模应用实践，如果上生产还是有风险，可在测试环境调研，并等待有更多生产实践作为依据。当然如果架构师认为风险并不大，且经过了测试调研也是可以上的。
五 BFF 层建设迭代
文章插图
前面我们将 API Gateway 的网关选型介绍了一下，请求通过网关后一般不会直接打到具体微服务上的，而是会通过BFF层，所谓的BFF ，即 backend for frontend 面向前端的后端。具体来说它的职能包括：

api数据裁剪
接口编排
接口调用

这层有的公司会按业务进行多个BFF的建设，在BFF中又有可能拆成多个服务，比如支撑首页的，支持列表页的，或者只有一个服务，支撑某个应用的所有请求的。
有了BFF层，前后端就会更好的解耦，前端不用再调用多个接口，然后再组织数据，微服务后端也只需要关心自己服务边界内的事情。
然而在实践的过程中会出现一些问题：

大量业务逻辑从前后端集中在了BFF层
BFF层逻辑复杂，代码量越来越大，难以维护
BFF API版本维护复杂
前端端接口职责不清，扯皮的结果就是放在BFF层

以上是我真实遇到过的场景。所以在后面的架构设计和实施中，这些情况会尽量避免，但没有从技术上解决根本问题。直到 GraphQL 的出现，让我眼前一亮，给了我一个很好的解决方案。关于GraphQL的搭建，数据交换等细节这里就不展开说了，感兴趣的可以从网上找到很多资料。
下图是我从网络上找的一个符合我心目中的理想架构。