web端实现
1、web端使用了gin框架，这个框架，自己看过一次源码，相对熟悉一点点。回头再看看grpc-gateway 2、接口测试直接使用了IDEA 提供的 http 测试文件，感觉挺好用，值得推荐 3、通过实现 MarshalJson()
这个方式，实现对时间的指定格式化，这里学到了，涨姿势了
1、配置文件读取，使用viper 框架，这个框架有点秀，功能很多。而且还能读取本地机器的环境变量，这就可以做配置文件的环境切换，通过控制本地环境变量来实现 2、使用zap日志模块，话说从测试结果上看，性能杠杠的，吊打同类。使用起来也简单，而且其实现有锁控制，不需要担心并发写问题
拜托，周末就休一天。躺尸..... 是不可能的，但确实因为前一天写的代码，没有提交，所以家里这台电脑无法更新到最新代码，so， 鸽了...
添加自定义验证器和对应的防疫处理 添加jwt和一些中间件处理，这里学习了一下go的中间件基本处理，之前也看过Gin 中的中间件，学习了
添加验证码的处理啰，使用第三方库，因为本地的go版本为1.15,最新版本的开源库依赖一个go1.16才有的包，so，强制在mod中指定了旧版本。
- 心血来潮，升级了go1.17,没啥毛病。
- 随手配置了vscode环境，两个一起用。 goland环境的工作目录指定为单个服务的目录，这样配置文件的读取就
- 兼容vscode中工作目录，使用根目录做工作环境，vscode 没发拿到config文件的路径。
- 本来使用阿里云的验证码做注册使用，设计个人隐私，测试验证码功能就直接返回在接口里了，这个不能放在线上使用，是个超级安全大漏洞，任意密码重置。
- 服务注册和发现处理，使用consul，用起来还是挺方便，直接使用docker 进行部署
- 在注册和发现这个处理中，踩了好几个坑，都在代码里注释了，写明了
踩坑 +1，主要原因还是之前没接触过，第一次来，不过跟着学，一边也在补其中的盲点，感觉很踏实
- 主要是实现了负载均衡，这个grpc本身也提供了这个功能，主要是通过第三方把事情高的更简单了
- 顺便注意到了那些 import 了库，但是代码中没有体现的秘密，原来是在库文件的init() 方法了做了一些处理，
学习了 - 负载均衡的知识，以前就了解一些，所以这里听课程讲解，没啥难度
- 使用命令的方式，可以同时启动两个服务，但这里有个依赖前提，对外提供的端口，可以自动生成，通过
net.ListenTCP()方法，传入的地址端口如果是0，则自动生成一个，注释里有说明，学习了
- 看课程视频，了解了nacos的使用，没有写代码，
so sad!，周六上班果然是划水的一天 - 使用docker 搭建了nacos，把家里局域网的IP地址改成了 1.175，路由器坑爹，折腾好久，浪费我大好时光
- 接着前一天的工作，完成了nacos配置文件的读取，原来的配置文件转换成了json全部都写入了nacos 配置中心里，所以本地的配置文件，就只有nacos的配置信息了
- 因为goland编译工作目录设置为了user_web,所以我将日志文件设置为了工作环境目录的上一层，也就是根目录，但是这可能在正式环境打包时候有坑，所以之后会考虑使用配置文件来区分开发和正式环境，方便统一管理配置文件的缓存
- 刚更新配置文件处理，配置信息使用nacos获取，项目中，不再提供配置文件，可以自己在对应工作目录创建名为 config-debug.yaml 和config-pro.yaml 文件配置内容为nacos的信息。 格式：
host: '192.168.1.75' // nacos 服务地址
port: 8848
Namespace: 'x x x x' // 配置文件的命名
user: 'nacos' // nacos 登陆用户名
password: 'nacos' // nacos 登陆用户密码
dataid: 'user-web.json' // 配置文件名
Group: 'dev' // 配置文件所在分组
完成商品的web层接口服务
- 总体来说，web层的服务，主要就是调用grpc服务，获取信息，然后在web端来进行组装。之前已经有用户层的结构，所以基础结构是可以复用的。
- 昨天稍微看了kratos 框架一些源码，收获很多，学到了不少新姿势。所以觉得更加有必要一步步跟着完成现在这个项目。从我们目前的项目来说，开发工作看似很简单，难点感觉不在开发上，而在服务的划分和后期的运维上。一个东西，拆的越细，分工也就越细，同时管理上的成本就上升了。就比如多线程，并非线程越多越好，而是依赖具体情况分析来控制。
- 下一步，需要测试走一遍接口，依然准备使用gland自带的http请求文件来统一处理