如何区别请求中的零值与零 2024-03-09 在go语言中，对于没有赋值的信息，会默认给予一个零值。而int型零值正好等于0，因此在处理一些http请求时，容易产生无法区分读到的字段信息为0是零值还是传参为零。 这里提供两种简单的思路： 1、修改规定接收类型为string型。当前端如果没有传值进来，那么后端将解析得到 "" 。因为string型的零值为 "" ，所以我们只需要判断接收到的string型是否为空即可。若不为空，则将字符串转换为数字，即可得到传参为0或其他数字的情况。 2、仍保持接收类型为int型，修改使用指针去接收这个字段。通常情况下，我们往往直接在controller层将映射结构体解析后直接传递至service层进行业务处理。为了区分零值和0，我们可以在controller层先用指针去解析该字段。若解析后为nil，则表示请求中未传值，那么我们可以给这个字段赋予一个特殊的值，例如-1。如果本身该字段有值，那么将该指针解引用。经过这一层处理后，再将该字段传递至service层进行相关业务处理。
基于Kafka监听DB数据变更并同步副表与ES的办法 有更新！ 2024-03-09 今天分享一个最近在业务开发中涉及使用到的很巧妙的小tip。 业务背景是有一张记录后台的DB主表，数据量达到百万级别。后台会涉及到一些字段筛选等，所以如果每次查询直接走DB的话会效率较慢。于是该业务采用的是当有用户或者后台运营进行数据变更时通过消息队列及时将DB变化及时同步至ES。此刻有一个新的业务后台开发，数据是从该百万级别数据量的DB中获取，某个字段符合一定条件时同步至该表，且主表信息变更需要同步至副表。 对于这样的需求，最简单暴力的解决方式就是可以通过定时脚本去进行数据同步，但是这样的方法有点太low啦。因为需要脚本启动之后才会进行数据更新，实时性很差。而且数据库数据量较大，每次全量查询影响性能。 那如果在所有涉及主表记录变更业务触发时，进行副表数据同步呢？当然，这也不是最优解。首先，对于这样庞大数据量的表，其字段和涉及业务也是众多的，你需要去穷尽所有对该表有影响的业务，并且去在每个业务中，增加同步新后台，很容易遗漏；其次，如果过了一段时间，又有新的业务后台也需要同步这张主表数据呢？并且随着后续该表相关业务的累加，很难保证后续的业务开发人员，在触及到主表字段修改的相关业务，或者同步....
ChatGPT后端开发tips 有更新！ 2024-03-09 什么！2024年了，还没开始用GPT？？？ 哈喽，新年快乐！ 好久没有更新了，之前暑期实习结束后呢就一直在忙学校里的事情，最近一个月呢，又回到了暑期实习的公司，继续实习，一月初到现在也快两个月啦。 今天想跟大家分享一些我在日常工作中使用ChatGPT的小tips。 第一个使用场景呢就是把gpt当一个搜索引擎去使用。刚刚进入职场，在开发工作中肯定会遇到一些自己并不熟悉的领域或者意料之外的error。通常遇到这种情况我就会去寻求GPT的帮助，你可以把你想知道的技术问题告诉他，他会以对话的形式去进行回答，并且如果他的回答中你有不理解的地方，还可以继续追问，不断追问的过程其实也是你对整个技术逐步深入了解的过程。我的mentor经常跟我说的一句话就是“拿到一个需求，不要急着去开发写代码，先去了解熟悉”。后来发现确实是这样的，不管是技术还是业务，梳理清楚了再去动手写代码，简直就是行云流水。所以有不熟悉或者有点模糊的问题都可以先去找GPT帮你解答！ 第二点呢就是在写业务开发的时候，难免会遇到要自己去写一些通用的函数工具，或者是一些洗数据的脚本。比如要对一些时间日期格式处理成统一格式，涉及到一些字段类....
追溯Context进行Bug定位 2023-09-09 Context概述 Context也叫“上下文”，对我而言一直是一个相对抽象的概念，可以理解为程序单元的一个运行状态。它扮演了一个信息传递的角色，将上层内容传递给下层内容。此外，当有Goroutine要执行前，都要知道当前程序的运行状态，通常将这些执行状态封装在一个 Context 变量中，传递给要执行的 Goroutine 中。 在web开发过程中，Context也可以存储整个请求链路的公参信息，例如后台登陆时用户的uid，name等。在后续处理相关业务逻辑时，随时可以获取到用户的公参信息。 定位过程 本周的一个需求中，涉及到通过Context来获取相关公参信息。需求背景是一个后台接口，在业务处理过程中，需要拿到用户的account字段信息。 account := ctx.GetString("account") 但是当我发到测试环境后，postman请求时却日志记录无法获取“account”字段信息，也就是说Context中并没有account字段信息。 于是开始对ctx信息进行追溯排查，首先分析可能出现的情况：GetString方法不对；Context被初始化过；ctx没有在用....
Solo搭建过程 有更新！ 2023-08-27 搭建起因 一直想拥有一个属于自己的网站，机缘巧合下接触到了Solo这样一个小众的平台。正好最近也一直在实习，下定决心搭建一个博客记录下工作学习中遇到的各种问题，也可以通过博客进行分享。 搭建过程 Solo 博客有两种搭建方式，静态搭建与动态搭建，本文在服务器上通过docker搭建的方式。 动态搭建：在服务器上部署，后台进程运行，如果有域名相当于拥有了一个属于你的博客网站。动态搭建也有两种方式，一种是下载源码编译运行，另一种是 docker 拉取镜像部署。 下载源码编译运行的方式适合自定义你的博客系统，可以试着修改源码来完成一些只属于你的功能 拥有一台服务器 阿里云、腾讯云、华为云、七牛云等都有自己的云服务器。阿里的稳定价格高，腾讯的价格低，华为介于两者之间。搭建自己的博客我想整一个属于自己的域名，考虑到域名备案时需要阿里的云服务器，所以本人使用的是阿里云的轻量应用服务器，镜像的系统是 CentOS 8.2。 ⭐ 注：记得在服务器上的安全组开放应该开放的端口 注册一个域名 有了域名再稍加配置，就可以用域名来访问服务器了。 域名在哪里注册以及如何备案可以去b站和网上了解一下。备案真的要好久....
技术评审方案编写流程及感悟 2023-08-27 本周接手一个开发查询记录后台的需求，为了更全面地熟悉整个业务需求的流转流程，mentor让我独立完成需求文档的编写。经过自己对整个业务流程的梳理和技术评审方案的编写后，对整个流程和技术文档的重要性有了更为深刻的理解。 技术文档的梳理步骤主要从如下几个方面进行： 1、接口设计 首先要确定查询记录接口，以及接口相应的Req和Resp。 Req中需要包括所有查DB时所需要的字段名，例如筛选项字段名，页码等（根据需求文档梳理）。梳理完毕后，去相关的数据库中去手写SQL查询。需要考虑查询速度、查询准确性、可行性等方面，对联合查询条件字段新建索引优化，确保查询数据准确。 Resp返回的字段必须覆盖后台所需要展现的所有字段。 同时编写Req、Resp的json示例，明确每个字段的数据类型。 2、数据源确认 对每个返回字段数据需要明确数据来源，并且在技术文档中梳理，后期介入实际开发时，将根据技术文档对每个字段取值。 数据来源一般有如下几个方面： DB查询 DB查询的数据需要确定数据来源库，是否需要联表查询。并提前编写SQL查询相关表，确保数据查询可行性，同时考虑数据库优化。 缓存查询 部分数据源从re....
Kafka 消费者使用 有更新！ 2023-08-12 consumer 消息消费者，从kafka broker中取消息的客户端。 最近手上的项目需要通过新建kafka订阅，来对消息进行处理，这是我第一次实战使用kafka，以前都只是纸上谈兵。经过本次需求的摸索，在一个服务中，开启多个kafka消费者来提高消费速度，对kafka consumer的使用也有了一定的理解，故记录下。 在实际项目中，主要流程分如下几个步骤，对kafka进行消费。 在业务代码中，定期创建任务并携带需要的参数去订阅kafka消息。 创建kafka消费组，实时监听kafka订阅主题中的消息，由于kafka接收到的消息数据结构是一致的，所以定义一个统一的结构体kafkaMessage去解析接收到的kafka消息，而消息中需要的具体参数，则会存放在kafkaMessage中的Data字段内。不过，要注意的是，由于同一topic的kafka中的消息可能是来自多方的，所以在消息调度前，要对解析后的kafka消息进行筛选，在本项目中，通过的是kafkaMessage中的ProjectName字段进行初步筛选，命中目标参数后再进行消息的调度。 项目背景： 在笔记后台管理平台中，原....
About me 有更新！ 2023-07-30 哈喽哈喽，欢迎来到我的博客！终于！我的域名备案审核通过了，赶紧来更新！这里作为我自己个人的小空间，以后会不定期更新一些技术分享和我的碎碎念～ 简单介绍一下我自己，24届魔都硕士毕业生，目前正在互联网电商公司实习，从事Golang后端开发，之前有过一段某二次元公司的测试开发实习经历。 到现在新公司已经入职正好两周啦，不得不说，电商公司的工作强度还是蛮大的哈哈哈，比上一家公司强度大太多了，可能也是和岗位有一定的关系。但是新公司的业务方向和企业文化我还是非常中意的！mentor和同事真的太和蔼了！ 原以为第一周进入就是看看文档、代码规范，没想到第二天下午就开始给我分需求啦。我对接的第一个需求是三方平台的api数据抓取，需求不是很难，对照着不同平台的开发文档进行业务开发。首先做的是微博平台对接，刚开始看文档的时候也是有点心慌，但是后面熟悉后也比较顺利啦，以至于后面再写其他几个平台对接业务的时候顺利很多。在日常工作时，mentor也会带着我梳理梳理整个公司业务流程、部门合作，了整个需求开发的流程，从产品对接到业务开发、建表入库，再到预发测试、日志抓取、需求移交。每个流程mentor都鼓励我独立去....
gRPC在项目中的运用 2023-07-30 本周接手了一个商品返回字段调整的一个小需求，需要调用其他项目中的RPC接口，而对于这一块知识点，之前一直都是一知半解，所以利用双休日对这方面的知识点进行即时补充学习。 在多团队合作的项目中，RPC接口的调用给整个团队开发提供了很大的便捷性。只需要调用别的部门写好的接口，就可以得到那边能提供的所有字段，再跟自己的项目需求字段进行比照，对结构体赋值并返回结构体即可。不过需求较为简单，只是拿前人搭好的框架，对代码阅读后定位字段匹配位置，进行字段增加并层层返回。 微服务背景 单体架构弊端： 服务器宕机，则引起整个应用不可使用，隔离性差。 只能整体进行伸缩，浪费资源，可伸缩性能差。 代码耦合，可维护性差。 微服务架构弊端： 代码冗余 服务与服务之间存在调用关系。 不同服务在不一样的服务器，涉及到进程和进程之间，服务器和服务器之间的调用。所以需要引入网络调用，但是在微服务架构中，http性能较低，因此需要引入RPC RPC全称Remote Procedure Call，远程过程调用。是一种协议，它屏蔽了分布式计算中各种调用的细节，使得开发者可以像本地调用一样调用一个远程的函数。 gRPC介绍 gR....
