最近看了如今公司的golang代码架构，再结合golang的语言特性和现有包管理的局限性，以为有些不合理。想在接下去技术改造过程当中调整一下。写出来，若是你们有什么好的意见和建议但愿和我探讨一下。golang
- 首先，既然是微服务，应该是尽可能解耦合的。能够容许有工具类，可是不能够有一个巨大的common包，里面不能带有对其余微服务依赖的逻辑，否则这个包一更新会给全部微服务形成测试压力。对于工具类，与其集中在一个包里，不如尽可能将各个工具类拆开来，好比golang的json组装作的比较烂，须要本身补充一些类和方法，能够单独封成一个包专门处理，这样引入的时候结构更清晰。
- api这一层做为客户端的入口不管是用gin,Faygo仍是bee都缺少一个入参check的功能，须要手动去完成繁杂的value check的逻辑，彻底能够用openapi协议来作，goswagger或者swagger自己的code generator均可以生成带有value check的中间层，并且能够自动生成文档，只需定好yml文件，就能够和客户端独立开发，减小联调成本。
- 各个微服务若是须要调用其余服务，独立在本身的包内生成client去调用其余服务并增长打点记录调用成功率，若是成功率低，那比较容易发现下游服务的问题，由于下游服务的打点你不能保证其余同窗有没有加或者有没有加对，因此最好在本身这里也作下打点。而去调用其余服务必然是有一个etcd，consul或者zookeeper之类作的服务发现机制，简单来讲就是一个命名法，这一块实际上是能够生成代码的，好比我要调用文件存储的服务，能够用命令生成client的rpc调用文件，将全部方法生成rpc调用并增长通用的打点和response处理，而后业务层再去调用生成文件里的方法并处理本身的逻辑，这样会减小重复性的工做。