最近看了现在公司的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处理，然后业务层再去调用生成文件里的方法并处理自己的逻辑，这样会减少重复性的工作。