CloudWeGo Study Group 是由 CloudWeGo 社区发起的学习小组，开展以 30 天为一期的源码解读和学习活动，帮助新成员融入社区圈子，和社区 Committer 互动交流，并学习上手 CloudWeGo 几大框架项目。目前 CSG 第四期—— CloudWeGo 业务实践案例解读已经圆满结束！

本期活动期间安排了 4 期直播分享，主题分别为：

Bookinfo——基于 CloudWeGo 重写 Istio 经典 demo

EasyNote——CloudWeGo 生态入门

Open Payment Platform——基于 CloudWeGo 实现 API Gateway

BookShop——从上手电商到上手CloudWeGo

本文为 CSG 第四期第二场直播中CloudWeGo Reviewer 王伟超分享内容。

回放链接：https://meetings.feishu.cn/s/1iraydxgioe81?src_type=2

一、嘉宾介绍

利用 Kitex 和 Hertz 进行支付开放平台的开发演示，使用 CloudWeGo 实现 API Gateway ，参考最佳实践，力求简洁、清晰得展示效果。

本期分享的内容主要分为以下三个部分：

背景介绍
架构设计
工程实践
总结

二、背景介绍

这期主题是关于 Open Payment Platform，即支付开放平台业务，基于 CloudWeGo 来实现 API Gateway。

今天的分享会分 4 个部分，

第一部分是编写 biz-demo 的背景；
第二部分从整体架构上来讲是如何设计的；
第三部分分享具体的实践步骤；
第四部分对本次分享做的小结。

项目背景

首先，在做这个 biz-demo 之前我一直有个疑问。这个疑问是从去年 3 月份开始，当时刚接触到 Kitex 不久，了解到 Kitex 有泛化调用的特性，但是并不是很清楚这个特性有什么用、用在什么场景。另外，我们都知道微服务一般不直接在公网暴露，那么公网或者用户普通的 HTTP 请求是怎么到 RPC 请求的呢？这个处理链路当时不是很清晰。

扫描二维码关注公众号，回复： 16329172 查看本文章

于是，我在 Github 提了一个讨论：“关于泛化调用及如何从集群外访问具体的某服务”，后来也是很快得到社区小伙伴的反馈和解答。不过当时对此认识不是特别深，后续也是带着这个问题一直在了解这方面的知识。

直到去年的 9 月份，我们社区的广明提到想基于泛化调用做一个 biz-demo，我觉得这是一个很好的尝试，想借助这次机会很好的了解该特性。一边学习一边做输出，这是很好的学习方式，所以就有了后续的这个 demo。

支付开放平台

支付开放平台通常是开放给服务商或商户提供收款记账等能力的服务入口，常见于支付宝、微信、银联等第三方或第四方支付渠道商，特别是前几年发展起来的聚合支付方向。

我做这个 demo 也是因为曾经做过第四方的支付，有接过很多的支付 SDK，所以稍会稍微熟悉它的业务场景特点，详细分析如下。

第一，它对外暴露的是 HTTP 接口，结合我们社区已有的项目，可以用 Hertz 来做另外一个开放平台。
第二，需要有加签、验签的功能，正好可以用 Hertz 的 Middleware 去自定义它的加签验签逻辑。
第三，也是特别重要的一点，即业务场景、业务模块很清晰，比如商户、支付、对账相关的安全边界很详细，也非常适合我们做业务、做微服务的拆分。
最后，关注工程化，比如 ORM、分包、代码分层、错误统一定义及优雅处理。比如分包在之前可能会比较简单、随意，这次也想能更多借鉴社区或者业内稍微能达成共识的设计。

三、架构设计

整体架构

首先从整体的角度去看这个项目，如图所示：

1、左边用户发起了 HTTP 请求，POST 方法，指定特定的服务路径参数，传了某些业务参数到了网关；

2、网关会判断它是要去到哪一个 RPC 微服务，然后用传递过来的参数，由泛化调用客户端，向 RPC 服务发起请求。

在此之前，启动 hert-gateway 时，还有一个前置处理：解析了所有的 IDL 文件，生成了 RPC 服务 -> 泛化调用客户端 的映射关系，后续每个 RPC 服务都使用各自的一个客户端发起泛化调用。

综上，hert-gateway 接收的是 HTTP 请求，该请求的 handler 是解析参数发起了一个 RPC 请求到后端服务。从整体代码结构上，整个项目如下

首先是 cmd，它是所有的 RPC 服务的入口。多个应用也可以加不同的目录做区分，这里的代码很少，主要做应用启动、配置初始化、命令参数解析、依赖管理、底层框架强相关的初始化工作等等。
configs 该 demo 初始化环境时的一些配置，目前这里其实很简单，它创建了一个数据库，方便启动 demo 插入数据，直接去演示。
hertz-gateway，所有的网关逻辑放在了这里。
idl 则是将所有的文件都放在此处。IDL 文件要强调的是，目前 Kitex 支持的泛化调用只支持 thrift 协议，之前也有小伙伴提出疑问能不能支持 gRPC，在我们社区内也接到了反馈，后续会进行考虑或者做相关规划。
internal 是所有 RPC 微服务的业务逻辑。
kitex_gen 是根据 IDL 生成的 Kitex 客户端代码。
pkg 是一些公共代码。