我们项目使用的是Gogs进行代码托管,Jenkins进行项目自动运维发布。
在我们的项目中,我们使用Gogs进行代码托管和版本控制,以确保团队成员可以协同开发和管理代码。
Gogs是一个轻量级的、开源的自托管Git服务,它提供了类似于GitHub的功能,包括代码仓库、分支管理、问题跟踪等。
通过Gogs,我们能够创建项目仓库,并将代码推送到其中。团队成员可以克隆仓库、创建新分支、提交代码,并通过Pull Resquest的方式进行代码审查和合并。这样我们可以实现代码的版本控制、团队协作和代码质量管理。
为了实现项目的自动构建和发布,我们使用Jenkins进行持续集成和自动化运维。Jenkins是一个开源的、可扩展的自动化服务器,它能够与各种工具和技术集成,用于构建、测试和部署软件。
我们在Jenkins中设置了针对项目的构建任务。当有代码提交到Gogs仓库时,Jenkins将触发自动构建流程。这个构建流程可能包括编译代码、运行单元测试、生成文档等操作。
如果构建成功,Jenkins将执行部署任务,将应用程序部署到目标环境中。
通过Jenkins,我们可以在每次代码提交后自动构建和部署项目,从而确保代码的质量和可靠性。
此外,Jenkins还提供了一套丰富的插件和扩展,使我们能够灵活地定制自动化流程,满足项目的特定需求。
综上,我们项目使用Gogs进行代码托管和版本控制,通过Jenkins实现项目的持续集成和自动化运维发布,以提高开发效率和项目质量。
第一种是投机的手段,直接复制报错信息,在idea中双击shift,点击Files,点击Find in Files,之后就定位到了代码。与订单中的下单id不一致就报这个错误信息。
但如果错误信息不是后端报出来的,是后端报了一个状态码300,前端报的错误信息,此时就不能用投机的方法,所以我们要学习最传统的方法。
1.首先要通过前端看一看,请求发送给谁了。
F12打开开发者工具,点击删除订单,点击删除,点开network,请求发送出去了,分析请求发送给谁了,示例中是发送给了api.tianji.com/ts/orders/订单号,先根据域名找到它对应的服务器,在Windows/System32/drivers/etc/hosts中找是否有api.tianji.com,查看转发给了谁,此示例中转发到了192.168.150.101,此处没有指定端口,所以转到了nginx默认端口80,所以可以得知这个请求最终是转发到了远端服务器上的nginx。
2.下一步找nginx的配置,在/usr/local/src/nginx/conf/nginx.conf中找api.tianji.com,找到了nginx反向代理转发给了192.168.150.1:10010,之后在MobaXterm中用docker ps -a查找10010端口,发现请求转发给了网关(tj-gateway)。
3.接下来去网关中找,网关中实现了请求的转发,查看网关的配置文件,在bootstrap.yml中查找ts开头的,发现网关中把请求转发到了trade微服务(trade-service)。
4.接下来在nacos中查找trade-service,发现trade-service把请求交给了192.168.150.1:8088,就是本地正在运行的TradeApplication。
5.接下来在tj-trade的Controller层中找orders路径,然后定位到了OrderController,根据请求路径和请求方式DeleteMapping然后有个参数,定位到deleteOrder方法,之后定位到orderService的deleteOrder方法,在OrderServieImpl的deleteOrder方法中敲上断点,然后阅读代码分析问题。
6.此时,遵循有注释不看代码的原则,最终定位到代码的问题在于Long类型数据进行比较时,由于Long类型是包装类型,进行数字比较时本质上是对象比较,对象比较本质上是比较内存地址,Long底层有一个数据缓存池,缓存的是-128-127,如果缓存的数据是126都是从缓存池中拿,但如果是129,不在缓存池中,就会new对象,用!=就会进入不相等的逻辑。解决方案是用Objects工具类的equals()方法来比较,就解决了bug。
以后做Integer、Long类型数据比较时,不要用==和!=,要用Objects工具类中的equals()方法。
7.综上,找bug的流程线:前端-nginx-网关-微服务。
在我的项目中,用户的登录和校验是在用户的微服务上,通过feign调用校验微服务暴露出来的API来完成用户身份核验的。
首先,当用户输入账号和密码,点击登录时,用户微服务就会接收到登录请求和相应用户的凭据信息。
然后,调用校验微服务对用户凭据信息进行校验。首先拿用户账号在存储用户信息的数据库中进行查询。
如果查询不到,就抛出一个自定义异常返回给前端,表明账户不存在。
若在数据库中查到了对应的账户,再进行密码的验证,为保证其安全性,前端传入的用户凭据信息中的密码会先加密,再和数据库中存储的已加密的密码进行比对。
若对比失败也会抛出一个自定义异常给前端,表明密码错误。
当都验证正确之后,会生成一个访问令牌token返回给客户端程序。然后客户端应用程序会存储该令牌以便后续的API调用。
当用户访问其它功能,调用其它微服务时,会使用token在其请求中进行身份验证每个需要token校验的微服务都会验证该令牌。
通常使用类似JWT的机制来验证令牌的合法性和有效期,微服务根据验证的访问令牌对用户进行授权,以确定用户是否有权执行请求的操作。
上述就是我的项目中用户登录和校验的详细流程。
在我的项目中,文章发布是在文章内容审核微服务上,通过Feign调用文章管理微服务暴露的API来完成,当用户发起文章发布请求时。
此时文章内容审核微服务会对文章内容进行审核,在我的项目中,集成了阿里云的内容安全审核服务来进行文章的内容安全审核,使用阿里云提供的接口审核文章内容,图片存储到minIO中,通过审核以确保文章没有色情暴力等不良内容。
此时,若没有通过阿里云的内容安全审核,文章审核失败,设置文章状态为待审核,转由人工审核。
若人工审核失败就将文章设置为审核失败状态,文章发布失败。
若通过了阿里云的内容安全审核,会调用文章管理微服务来新增已经发布的文章进入数据库。
在加入数据库的同时,也会加入到RabbitMQ的消息队列,然后在搜索微服务中设置监听器,以实现当有新增的已发布文章时,将其同步存入ElasticSearch中方便后续进行分词查找文章。