Skip to content

imyuliz/api-scheduler

Repository files navigation

GoReleaser Logo

API-Scheduler

Codecov Codecov GitHub marketplace GitHub release


Proposal

Ø Introduction

伴随着业务的发展和低代码的迅速推进,可见的问题随之暴露出来。

从业务发展的角度来看,由于业务的复杂度越来越高,导致API的调用链越来越长,依赖的上下游越来越复杂,以下问题逐步升级成为难点:

  • API调度维护困难: 一个完整的功能依赖多个接口的数据支撑,存在多个项目互相依赖的情况,项目关系混乱,部署复杂;
  • 调用链复杂,且涉及广泛,全链路日志查询困难;
  • 依赖的上下游较多,Tracing 推进困难,全链路耗时和细节耗时难以排查,可观测性差;
  • 业务持续发展,依赖的链路越来越多,流程可读性,维护性变差,最终可能可能变得无人可改;
  • 业务链路太长,同一接口存在不必要的重复调用,导致数据混乱,流程混乱。

从低代码的发展角度来看,低代码的目标是少/不写代码,通过拖拽的方式把功能进行实现,前端趋近成熟,但是后端承载业务逻辑,后端 API 可能成为混乱的源头。

  • 后端API模块化不足,维护性低:前端快速拖拽完成,后端一个接口包含了接口依赖调用,数据库调用、缓存调用,后端成为性能瓶颈且维护性极低,最坏的情况可能导致项目不可控。

从Devops 的角度出发:

  • 在做自动化,标准化和安全规范时,敏感数据可能在文件中或者代码中写死不利于变更;
  • 在异步回调场景中,代码重复度较高;
  • 需要对数据进行准入判断时,通常写在代码里面。

Ø Proposal

API-Scheduler 从 API 流程调度出发,用户通过声明式的方式, 通过可视化,YAML,JSON 等方式编写流程调度文件(就像 Deployment 一样), 声明接口依赖的服务和接口,最终输出什么数据,完成API 流程的串联,并将此接口统一向外暴露。并可以提供以下解决方案:

  • 声明式API设计, 用户声明资源对象,表达所需要的期望状态;
  • 原生支持 OpenTelemetry Tracing 规范;
  • 原生支持日志 TracingID, 让日志上下游清晰可见;
  • Prometheus Metrics 规范原生支持;
  • 数据池支持, 避免从日志中清洗数据, 可直接进行数据分析;
  • 依赖请求统一由API-Scheduler 统一编排, 解决依赖混乱;
  • 统一调度规范和校验, 形成标准化, 避免降低可读性和维护性;
  • 支持准入控制、并发控制、重试机制,幂等请求、异步请求等逻辑处理;

Ø Plan of Action

Ø Will it work?

Ø Desired outcomes

Ø Necessary Resources

Ø Preparations Made

Ø Conclusion

Created in ChengDU rainy night

常见命令

  1. 手动测试镜像构建 docker build -t template-go -f build/docker/Dockerfile .
  2. 发布新版本 git tag v1.0.0 && git push --tags

Git 提交规范

  1. 在提交 Commit message 信息时, 应该保证 message 能够简要说明此次变更的性质和作用域。 比如:
fix #issue: math/big: fix typo in documentation for Int.Exp
  1. 当代码变更需要引入第三方包时, 单独单独提交一个commit, 来说明对第三方包的变更, 通常, 会使用: vendor: add package name 的方式来提交 commit 信息。 这样有利于 code review。
  2. 提交代码时, 一个功能特性或者bug fix 应该独占一个 commit, 而不能把多个特性揉合成一个 commit 提交代码, 因为这要非常不利于 code review 和 代码追溯。

常用的一些提交术语:

feat:       新特性
fix:        bug 被完全修复
update:     issue/bug 只有部分被修复, 还需要提高和改善
docs:       文档变更
vendor:     代码的依赖包整理
style:      改变代码的风格但是未影响代码的功能和意义(比如对 空格, 格式化等的修改)
refactor:   既不修正错误也不添加功能的代码更改
perf:       提高代码的性能.
test:       对单元测试进行添加/删除/修改
build:      构建工具更新
conf:       运行时的配置变更(注: 通常应该配置分离)
cve:        对安全漏洞的修复
chore:      更改构建过程或辅助工具和库,例如生成文档

代码编写规范

  1. 使用 goreporter 或者相关系统做代码审查和质量评估
  2. 编程风格遵守vscode代码提示规范,尽可能的避免避免绿色波浪线
  3. 非内部方法一定有func注释
  4. 代码质量按照Goreport质量等级规范
  5. 使用sonar深度分析代码质量
  6. 使用火焰图性能调优
  7. 熟悉常见的代码性能分析知识
  8. 编译时, 把编译环境和commitid写入程序中, 并通过日志打印出来,有利于问题排查

代码优化习惯

  1. 尽可能少的在循环体内部创建切片或者map,或者复杂对象,因为这样会造成性能不必要的损失。
  2. 当既可以使用slice又可以使用map的时候,如果不是非要使用map,那么我们可以多使用slice,因为map在在赋值的时候会信息hash判重,这是因为golang的map是又hashmap实现决定的,slice相当于map来说写入块,但是也比map更占用内存,所以,通常两者都可以的时候,取决于是时间换空间,还是空间换时间.

相关推荐

  1. Go 官方 CodeReview 规范标准 英文版, 中文版
  2. Go 语言源码贡献官方指导文档 英文版, 中文版
  3. Uber Go 编码规范 ( 多厂借鉴 ) 英文版, 中文版

About

Human friendly API scheduler

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages