# 后端篇

# 当与线上服务对接时,需要线上 callback 的时候, 可以拥有一个公网可见的回调地址

接到调试微信公众号根据关键字自动回复的开发任务微信公众号需要一个公网可见的地址进行 callback, 而此时由于项目还处在开发阶段, 或者因为运维原因, 暂时无法提供回调地址。

此时你可以使用 NUAPI 的 端口转发功能, 在 NUAPI 的端口转发中输入开发机程序使用的端口号, NUAPI会返回一个域名, 以及一串 ssh 指令。 当在开发机输入此处的 ssh 指令建立连接后, 您就可以使用域名来访问您本机的端口了。

20220328012452

执行完指令后, 访问返回域名, 就可以看到访问公网地址, 也会有响应, 并且本机的端口也收到了访问。

20220328012555

20220328012706

# 集群内网私有服务的临时访问(SSH 端口转发,无需额外工具,随时/自动关闭无安全隐患)

企业内部有很多服务,正常情况下并没有分配公网地址访问,这些服务只是提供给内部调用的,但是有些情况下为了方便排错,可能需要临时让这些服务公网可见,以方便调试,当调试完毕后, 需要关闭公网可见。 ​ ​在传统的方式中,我们一般使用 内网穿透工具来实现, 然而这些实现都有一个共同的问题: “需要在服务器上安装编译好的软件”。 ​ ​在服务器上安装不常见的内网穿透软件,主要有以下劣势 ​ ​1. 麻烦, 如果是境外的地址, 很可能因为互联互通问题无法下载 ​2. 安装新的软件,需要找运维报备等,流程较多 ​3. 安装的软件有可能存在一定的风险 ​4. 使用完毕后,还需要删除该软件避免用户滥用 ​ 使用NUAPI 提供的 ssh 端口转发, 则不需要面对这类问题:

  1. NUAPI 的端口转发只依赖服务器都会部署的 ssh 服务, 不依赖其他任何软件
  2. 由于只依赖常见服务器默认安装完毕的 ssh, 所以不存在风险代码的引入问题
  3. 操作简单, 仅需临时的授权码即可连接
  4. ssh 退出后,即关闭了内网穿透, 就算忘记关闭,默认情况下 20 分钟后也会自动关闭

# api 文档不用从 0 开始, 对应 uri 的示例直接生成好

项目开发太着急,项目不停的催,后端很多接口都是现写好,之后跟前端通过现场或 IM 沟通,根本没有时间去写文档。此时如果有新员工加入项目,面对没有任何文档的项目,他肯定是崩溃的。 ​ ​幸好NUAPI 提供了自动生成 API 文档功能。NUAPI 会根据收集到的访问记录自动整理出一份简单的 API 文档,包含path, method , 传输的参数, 返回的 status code 以及 body 任何一个文档记录都可以查找出最近的访问记录。 ​ ​新同事可以根据这个文档快速的对项目有个简单的了解,

20220328013044

点击 最新示例, 即可查看对应 API 最新请求案例:

20220328013216 ​ ​同时 api 文档还支持标记以及导出 OPENAPI (swagger ) 等操作。用户可以导出后再使用其他工具进行进一步加工。

20220328013331

# 使用对比功能解决 “在我这里没问题啊,你是不是参数传错了”的问题

在调试最基础案例 登录的时候, 后端和前端打起来了, 这是一个特别基础的功能“登录”, 后端对此早已驾轻就熟。 在本地测试 ok 之后, 后端将代码部署到了测试环境, 让前端进行测试。

前端正好写完界面, 后端口述了下登录接口,前端编辑完毕后, 试着做登录, 发现服务器返回 403. 遂质问后端

后端不服, 说“没问题啊, 你看 我 postman” 提交: 账号 admin@example.com 密码 123456 结果 200, token 在 headers 里

前端也抑郁了, 你看我 chrome 的network 的 json 信息: admin@example.com 是账号, 密码 123456, 结果返回 403, 后端你专业点行不行, 这么基础的接口都出问题, 行不行啊?是不是去翻一下日志看下?

“去翻日志,说的轻巧”, 后端说, “这个日志是k8s 收集的, 接的 elk 的日志, 但是刷的太快了, 压根就找不到, 而这个又没有 500 报错, 错误收集功能也查不到信息”

只不过后端还是有压箱底的秘密武器的: 是时候让 NUAPI 的对比功能解决战斗了, 后端忽悠前端将请求的域名换为 NUAPI 分配好的域名后, 前端发起了一次请求, 同时后端也用 postman 向该域名发起了一次请求

NUAPI 出现了两条请求记录, 接着 将两条进行对比, 即可对两次请求做完全的对比:

通过对比可以看到: 前端与后端传输的 body 完全一致, 都是 {"name": "admin@example.com", "password": "123456" } , 但是 headers 确略有不同: 后端由于使用了 postman, 传输json, postman 会自动将 headers 里添加: content-type application/json 而前端由于使用了原生组件,并未对 headers 做特殊的设置, 所以此时的 conent-type 为 ''application/x-www-form-urlencoded“

"哦哦哦我忘记改 headers了,哎呀我的锅我的锅, 下午的茶歇我请你喝咖啡嘛",前端实在是过意不去

‘哎呀, 下次专业点嘛, 锅不要甩太高哟”, 后端贱贱地说。

请求对比

# 可以针对部分 path 直接路由到开发机进行调试

ios 开发正在调试着评论区代码逻辑, 突然发现查看评论的请求代码挂掉了。质问后端, 后端莫名其妙: 我今天都没参与评论comments相关的代码开发。 不应该出现这个问题呀

ios 表示, 之前这个功能他也没调整过, 是不是你重构引起了一些小 bug?

后端查看了下服务器的日志, 发现这是个查询ip 报的错误, 但是比较尴尬的一点是: 这个接口是在服务器报的错, 但是服务器在查询 ip之前也生成了一些前置变量, 这些前值变量并没有打上日志, 而后端感觉是 前置变量的计算有些问题,解决这类问题最好的方法就是“调试一下”。但是问题就处在这里, 这是在服务器上出现的 bug,而服务器上, 是没有办法轻松的调试的。

有了 NUAPI ,则可以巧妙的解决问题: NUAPI 具有针对单个 path,穿透到开发机, 其他接口依旧走线上的功能。

此时后端只需要在 NUAPI中评论相关的 comments 进行 ssh 穿透到他本地,NUAPI 会生成一句 ssh 指令, 此时 后端需要在命令行中运行其指令以建立本地与 NUAPI 的连接;同时 ios 端照例将请求的域名更换为 NUAPI 生成的域名,其他地方则不用做任何改动。

​之后 ios 访问其他接口时, NUAPI 会将请求正确的转发至目标服务器, 而当访问到comments 接口时, NUAPI 会 将其转发到 后端自己的开发机上, 此时后端就可以方便的在自己的开发环境中增加各种断点来进行对程序的监控了

经过在本地的断点调试, 后端发现原来是自己的某处时间戳转化当中出现了问题, 前端是以毫秒为单位而自己使用的是秒, 最终影响了 comments 的结果。修改之后, 故障排除。

# 可以使用调试模式: 在服务器返回NUAPI,NUAPI 返回client 前, 可对收到的信息进行更改

后端刚部署完毕了一套查天气的接口, 随口对 Android 端说:这个是返回天气的接口, 我们是调用了第三方, 你只需要传城市名称给我就好了, 我回返回你这个城市的 当天天气。

Android 端测了一下, 嗯, 北京, 晴天, ok, 问题不大, “等等, 后端大哥,你能让接口返回下 其他不同的天气情况, 比如大雪 阴天么?我看看android 端显示的样式”

后端表示, 接口已经对接好了三方 API, 这种修改又得重新部署, 好麻烦, 这是最起码得 3 顿烧烤才能解决的问题

突然, android 端想起来, NUAPI 具有对某个接口的调试功能: 即 NUAPI 收到目的接口的返回后, 返回给用户之前, 是可以进行内容修改的。

于是, android 果断打开调试模式 做了以下操作

  1. 将api 域名改为 NUAPI 分配的域名, 并映射到目标域名
  2. android 调用对应的 path
  3. 在 NUAPI 的 web 界面上即可看到目标域名对应的返回, 但此时 android 端本身还没收到内容, 内容被 NUAPI 端拦截住了, 同时 内容在 NUAPI 中弹出
  4. 在 NUAPI 的界面中修改 返回, 将接口内容调整为 “大雪”
  5. 点击确定修改, 此时 android 就收到了修改后的接口 返回天气的内容为“大雪”