发表于   |   分类于 生活   |   暂无评论

昨天的时候和一个朋友出去玩。是意外的。其实我是高兴的。
晚上天渐渐黑了，海河岸边的一排整齐排列的灯把水面的粼粼染成金属一般的橙色。
我和她就这样沿着这条河慢慢走着。
微风吹来，不似下午那么的热，晚上的风也变得温和，轻轻刮过面颊觉得很舒服。
广场零次的有着跳广场舞的，卖咖啡的，还有垂钓的，也有和我们一样从外面过来只是想来走走的。
不知道晚上的天津是什么味道的，我默默跟在她旁边。有时候她走的比较快，我就跟上，有时候我走的比较快，就向后去找她。有的时候不小心挨到了，鼻尖缭绕着淡淡的香味，不可名状。
我是没有什么感慨的，只是想跟着走在她旁边。
四周不知道为什么随着我们的脚步越来越静，走到头了。周围还是黄色的，灯光打在建筑上，人为的制造出了一种朦胧感。
我们停下，我看了看她，问她接下来去哪。
后来我们回去了。直到现在我才堪堪有种遗憾。
我不是很敢去想让这段意外能一直保持着，或许也是因为逐渐知道这是不可能的。
昨天的下午还有晚上，就像是我枯燥生活意外的被溅到了一滴水，还在的时候没有感觉到什么，当意识到的时候，已经蒸发了。
我幻想过这次会面，很是期待，我又害怕这种期待会让这一会面变得无味。
后来才发现原来是我期待的不够多，就这样让它流过去了。
生活回到从前那样，没有变化。但我好像回不去了。

发表于   |   分类于 生活 , 分享   |   暂无评论

今天帮忙部署一下实验室接的一个项目的后端
出了几个比较大的问题，好在最后还是成功的完成了工作

第一个就是公司的服务器不能连外部的局域网，所以这就导致了不能使用git从仓库来拉取项目，只能是手动的上传。
他们那边的运维工具是堡垒机，说实话我还是第一次见，觉得很新奇。
和那种直接将服务器ip和账号密码给你的模式不同，他们是有一个统一的终端来保存这些服务器的信息，当选择特定的要运维的服务器的时候可以选择本地或者跳板机的ssh应用连接到服务器。
一开始因为本地的xshell没有配xfrp，然后不能上传文件，在这里卡了很久。
事实上一开始我都不知道服务器不能连外网。
因为不能连外网，所以不能用git来拉取，还有就是不能使用go mod tidy。
说实话这两步恶心了我很久。
对于前一个其实一开始就想过todesk把文件传过去，然后用xfrp传过去。
但是那边用windows应用连接不能访问本地的文件，后面想这个windows应用连接应该就是用堡垒机，或者说跳板机连接。
之后换本地连接，但是本地的xshell没有配xfrp，一开始想的是用rz -E，但是没有安装lrzsz
而且因为是内网所以安装不了。
后来就是我自己尝试安装xfrp，但是发现要使用的话安装7和5都让用（注xshell版本是5），一直提示要更新，更新到8之后确实可以用，但是在xshell界面跳转到xfrp界面时会发现报错，并且连接就掉了（指xfrp）xshell还健在。
其实在安装xfrp的过程中还把机器差点搞崩溃了
幸亏后面冒死重启没事
最后无奈还是求助了那边的运维，后面下午的时候他们装了一个版本为4的xshell和xfrp终于可以用了

下午的时候将go的项目文件上传
上传之后发现了一个大问题就是因为得装依赖，用go mod tidy
这个过程需要联网，所以行不通
后面想到要不就在本地编译一下再上传
但是后来发现由于之前项目负责人留下的技术债，导致在编译的时候有一个文件路径的变量是使用的当前编译环境的路径并且写死。
后面发现修改起来很困难，一度想放弃。
之后没办法在5点多的时候和那边的运维反映，然后他们说要连外网得申请，
找谁申请？谁负责找谁。 ……
后来去找了另外一个公司那边的人，这次干脆说服务器不允许连外网，让我自己想办法解决。

后面想过直接将本地gopath下面的依赖打包，然后传到服务器的gopath，但是还是会强制的使用go download
之后了解了一下知道了有 go mod vendor这一条指令，可以将项目用到的依赖打包
之后只要将vendor文件夹放到服务器项目的根目录下就可以了
不过后面还是出问题了
因为go mod和go sum和我开发的环境对不上，所以少了一些对应版本的依赖
后来发现是因为一开始我为了将项目拖进去，使用的是gitee上下载的zip包，不是本地在开发的
所以可能会有些出路。
后来我想过将go.mod和go.sum直接替换，但是失败了，也尝试过将部分依赖的版本号，手动修改到和开发环境一致，但是也失败了。

最后没办法就在下的master的zip包里运行了一次go mod vendor，然后将这里面的vendor包传到服务器。
最后是成功运行了，但是有报错，后面问了一下学长，主要是sonic包导入有问题。
这个sonic包是字节跳动的一个包，说是有魔法，正常用download下，下不干净，必须要用go get。
其实到这里的时候我的耐心快要没了。
不过最后突然灵光一现，将本地开发环境和vendor文件夹一块打包成zip
传到服务器，然后解压
最后成了。
我觉得成的原因主要就是这最后一次是整体传上去而不是分开的。

后面的任务就简单了，调试一下，配一下日志。我的工作结束了。
之后前端unity的部署，还有数据库方面的检查就是另外两位学长的工作了。
一下子就轻松了。

这次的部署任务还是很开心的，总体来说。因为对于我来说，这也是第一次给企业部署项目，多少也有点激动。也学到了挺多经验的。而且我已经很久没有做过运维性质的活了，真的感觉挺不错。当然这个不错是建立在我成功，并且不用返工的前提下，hhh。

发表于   |   分类于 linux   |   暂无评论

在 Linux 上安装了 etcd 后，可以通过以下几种方式查看它的状态：

方法一：使用 etcdctl 工具

etcdctl 是 etcd 的命令行工具，可以用于查看集群状态、成员信息等。

1. 查看 etcd 版本

etcdctl version

2. 设置环境变量（如果你是使用默认配置）

export ETCDCTL_API=3

3. 查看健康状态

etcdctl endpoint health

如果 etcd 正常运行，会返回类似：

127.0.0.1:2379 is healthy: successfully committed proposal: took = 1.233ms

4. 查看成员列表

etcdctl member list

5. 查看集群状态

etcdctl endpoint status --write-out=table

方法二：使用 systemd 查看服务状态

如果你是使用 systemd 安装/启动的 etcd，可以使用：

systemctl status etcd

也可以用：

journalctl -u etcd -f

实时查看日志输出。

方法三：查看进程和监听端口

查看是否有 etcd 进程运行：

ps aux | grep etcd

查看 etcd 是否监听了默认端口 2379：

ss -tunlp | grep 2379

方法四：通过 HTTP API（如果你开放了接口）

例如：

curl http://localhost:2379/health

返回：

{"health":"true"}

说明服务正常。

发表于   |   分类于 Go   |   暂无评论

这个报错：

json: Unmarshal(non-pointer model.Submit)

出现在语句：

err := c.ShouldBind(codedata)

说明在调用 ShouldBind 时传入了一个 非指针类型 的参数，而它需要一个指针类型来把 JSON 数据反序列化进去。

问题详解：

在 Go 的 encoding/json 包（Gin 的绑定底层也是用它）中，json.Unmarshal 必须接收一个指针，否则无法修改原变量的值。

例如：

type Submit struct {
    Code string `json:"code"`
}

错误写法（非指针）：

var codedata model.Submit // 这是值类型
err := c.ShouldBind(codedata) // 这里会报错：json: Unmarshal(non-pointer model.Submit)

正确写法（指针）：

var codedata model.Submit
err := c.ShouldBind(&codedata) // 正确，传指针

正确写法总结：

var codedata model.Submit
err := c.ShouldBind(&codedata)
if err != nil {
    c.JSON(400, gin.H{"error": err.Error()})
    return
}