openapi - swagger - java工程迁移至go -gin工程

背景介绍

18年开始自己尝试改造swagger codegen maven 插件用于自身的工程管理，经过简单改造后的插件能能够胜任日常的代码开发，期间两次换公司很幸运被两家单位认可了这种模式，期间也做了几次增强以及附带改动了一些插件为了满足一键生成接口文档，且用过的都还觉得不错被几家合作单位拿出使用，感觉还是挺高兴的自己的代码得到了大多数人认可。近一年参与了一个很不错的工程，在里面体现了作用，翻来覆去的重构了工程多个模组，让原本不可用的工程逐渐被市场认可，虽然自己只是其中一个钉子，依然觉得自己的团队贡献挺大的。

 

近期又重构了一个很复杂的逻辑模块，领导开始让我把这部分代码交给新人，并叫停了核心模块的重构，导致自己工作很是轻松于是决定捡起来自己的工程，希望实现自己的代码能够无缝的将接口逻辑全部迁移至golang，以应对未来的云原生大潮，并未用过我工程的同志们提供一个后续解决方案。（免费的......）

--- 预期解决的问题，  （swaggercodegen 不能多文件生成，不能控制翻转。我自己的修改解决了这个问题，但是swagger 的校验传递依然在生成代码过程中依然未见修复。）

1， linke 多swagger文件------》 已解决。后续的工程即使生成依然可以采用这个模式。

2， 控制反翻转 go语言并不是解释型语言，所以我只能通过硬设计实现控制翻转，---》 模式已设计

3， 功能隔离，得益于go语言的func的灵活性---》 已解决

--- 到底是否使用swagger go ，经过一段时间的使用发现go-swagger生成的代码过于复杂，且不能做到功能单元的隔离，代码结构并不清晰，决定使用gin 框架。（先用这个练手，以后再生成其他的框架）

卫生选择 gin 校验灵活可控 对 tag 很有用。  后续我会尝试要不要改造部分gin 的validate的部分加入新的tag 以应对，我把所有来源参数归集到一个地方的目的。但是这个参数绑定校验过程会锁内存

目前先不定，等验证了性能之后再再决定要不要写。

因为基础的结构构型设计已经做完，且源数据yaml已经完成了所有的连接组装渲染，所以现在开始实现细节。

在这里当日记记录自己的整个工作过程，下一遍博文需要做的事情。

查找资料或者源代码寻找binding tag中的所有关键字以及自定义等等，完成整理为模块生成铺平道路。

希望今天晚上能完成------------------------------------------------毫无灵魂的分割线。