Posts

实现的目标 本项目使用Transformer模型对邮件进行垃圾邮件（spam）和正常邮件（ham）的分类。 数据集来源 数据集来自 SpamAssassin公共语料库 项目结构 data_processor.py: 处理数据加载和处理 data_preprocessor.py: 为模型准备数据 model.py: 定义Transformer模型 trainer.py: 包含模型训练逻辑 evaluator.py: 评估训练好的模型 main.py: 协调整个处理过程 environment.yml: 定义Conda环境

在一个风和日丽的周六中午，有点热，然后坐在我旁边的同事突然发现公司的 Wifi 神秘消失了。 “额，咱们公司的wifi是不是用不了了呀” “我看看，好像是哦，这是咋回事？诶，这好像是我的工作职责内的事情耶，我去看看…” 问题排查经过 打开手机查看wifi列表发现平时经常连接的wifi消失无踪，但是有很多小的wifi密密麻麻的。 和mentor远程交流怀疑是不是AC控制器掉电导致的。 遂重启AC控制器，发现无效。 检查POE交换机的状态。 mentor检查线上设备，发现AP都下线了。 把POE交换机上的AP网线拔掉重新连接。 然后在交换机的命令行模式中排查问题，发现是AC控制器的管理模式变了，授权没了，导致AP上线不了。 基础知识 AP, Access Point 无线AP：即无线接入点，它用于无线网络的无线交换机，也是无线网络的核心。 通俗理解：AP是一个信号发射器，我们收到的WIFI信号都是AP发射出来的 AP的分类 面板式AP 吸顶式AP 室外AP 网上把AP划分为’胖AP’和’瘦AP' 胖AP：自带管理功能的AP，例：我们的家用路由器 瘦AP：不带管理功能的AP，简单来说可以把它理解成一个信号发送与接收的天线（需要AC控制） AC, Access controller 接入控制器 即无线控制器，是一种网络设备，负责管理某个区域内无线网络中的AP(瘦AP)。 主要功能：调节无缝漫游 例：你用手机，从商场1楼走到2楼，由AC来觉得什么时候让你的手机从1楼的AP切换到2楼的AP上。确保你不会因远离1楼的AP导致信号不好而无法联网。 如果你直接用2个普通的无线路由器，就会发生手机一直连着信号不好的1楼而不切换到2楼。直到1楼彻底没有信号后才会重新链接到2楼的路由上 一般来说，一台AC最多可以连接1024个AP，而每个AP最多可以连接255个手机。 可以批量设置AP密码，AP的SSID。

理解Context 这篇文章介绍的很清楚：深入理解Go Context 这个比较详细，但是层次不好：理解GO CONTEXT机制 关于context的使用场景 context的主要使用场景在于：一个任务在处理的过程中可能会启动很多个协程来进行处理。在这个过程中，如果上游的任务想要取消，下游的任务也应当一起取消。context的任务就来了。 内容介绍 context包的内容可以概括为：1个接口，4个实现，6个方法 接口 context.Context 一个接口是指：context.Context type Context interface { Deadline() (deadline time.Time, ok bool) Done() <-chan struct{} Err() error Value(key interface{}) interface{} } Deadline( ) Deadline会返回一个超时时间，Goroutine获得了超时时间后，例如可以对某些io操作设定超时时间。 函数签名 Deadline() (deadline time.Time, ok bool) Deadline 返回的时间 deadline time.Time 代表这个ctx应该被取消的时间。返回的 ok 如果是 false 表示这个context没有设置deadline。连续调用 Deadline 会返回相同的结果。 // Deadline returns the time when work done on behalf of this context // should be canceled. Deadline returns ok==false when no deadline is // set....

gRPC服务的架构图 RPC调用总的来说就是客户端调用存根的代码，然后存根代码和RPC库实现通信，服务端的存根收到了信息后交给具体的服务进行处理，之后再原路返回就完了。 这里附上一篇关于gRPC讲解的博客园的文章 Proto文件代码生成 项目的前后端都是使用的gRPC进行通信，都需要使用protoc编译器把之前定义好的proto文件进行编译生成对应的代码进行调用。 问题1 timestamp.proto文件找不到 timestamp.proto是google的一个时间戳的包，因为在我们自己的proto文件中使用到了google.protobuf.Timestamp，在proeo文件的最上方也要导入对应的proto文件import "google/protobuf/timestamp.proto"; 我记得在下载protoc编译器的时候，压缩包下面就有一个include文件夹，其中就包含有timestamp.proto文件 问题2 go代码生成对应的包名和位置对不上 项目的后端采用的是go，想要把proto文件编译成golang的代码。这就需要在proto文件中加上go_package的字段，比如： syntax = "proto3"; package rpc.auth; option go_package = "github.com/BigNoseCattyHome/aorb/backend/rpc/auth;auth"; import "google/protobuf/timestamp.proto"; // 定义消息，用于请求和响应结构 message LoginRequest { string username = 1; // 用户名/用户ID string password = 2; // 密码的md5摘要 string device_id = 3; // 设备ID google.protobuf.Timestamp timestamp = 4; // 时间戳 string nonce = 5; // 随机数 } 然后在使用protoc编译的时候，在命令行中也要加上go的一些选项，比如： protoc --go_out=. person.proto // 找到当前目录下的person.proto并生成go的代码，输出到当前目录(.) 但是又有了一个问题就是在该文件夹下面，会生成你的包名go_package的层级目录，最后才是你的最终代码。但是我想让proto文件直接生成在一个固定的文件夹位置，并且没有那么多的层级文件夹。 然后发现了有一个命令选项是--go_opt=paths=source_relative,使得生成的Go代码文件的路径与对应的.proto文件的路径保持一致 问题3 dart代码生成的时候老是存在找不到pb.xx 后来上google和stackoverflow看了半天，发现结果是依赖版本的问题，把protobuf的依赖版本从^2....

Auth服务 这里先写我们的初步规划，最终的实现放在最后写。这实际上也是我们的开发思路。 初步规划的API /api/v1/auth/login ​ 登录接口允许用户输入用户名和密码进行登录，服务器验证成功后，会返回一个JWT。JWT会存储在客户端的本地存储中 /api/v1/auth/register ​ 用户注册，填写用户的基本信息，在服务器的数据库上进行注册 /api/v1/auth/verify ​ 用户在拿着JWT去访问别的微服务的时候，我们要先验证这个JWT的合法性。确保用户合法。具体的实现就是去检查这个JWT是否过期，用户名是否正确。 /api/v1/auth/refresh ​ JWT有一个Expire过期时间，当用户还在使用的时候，JWT需要刷新。就使用刷新令牌进行刷新，经过服务器验证之后，返回一个新的刷新令牌。 /api/v1/auth/logout ​ 退出登录，需要在客户端本地删除token，并且把刷新令牌revoke 查阅资料：刷新Token的策略 刷新令牌（Refresh Token） 定义： 刷新令牌是一种用于获取新的访问令牌（Access Token）的凭证，通常在访问令牌过期后使用，以避免用户频繁重新登录。 工作原理： 用户首次登录时，服务器颁发一个访问令牌和一个刷新令牌。 访问令牌用于访问受保护的资源，具有较短的有效期。 当访问令牌过期时，客户端使用刷新令牌向服务器请求新的访问令牌。 服务器验证刷新令牌的有效性，如果有效，则颁发新的访问令牌，并可能同时颁发新的刷新令牌。 优点： 提高用户体验，减少频繁登录的需求。 访问令牌具有较短的有效期，降低安全风险。 缺点： 需要妥善保护刷新令牌，因为刷新令牌的泄露可能导致长期的安全问题。 实现强制注销或更改密码后立即失效所有令牌比较困难。 缓存令牌（Cached Token） 定义： 缓存令牌是指将令牌存储在缓存系统（如Redis）中，以便快速验证和撤销令牌。 工作原理： 用户登录后，服务器生成一个令牌并将其存储在缓存系统中。 客户端在访问受保护的资源时，携带令牌。 服务器从缓存系统中验证令牌的有效性。 如果需要撤销令牌，服务器可以从缓存系统中删除该令牌。 优点： 快速验证和撤销令牌，提高系统的响应速度。 灵活的令牌管理，可以随时撤销某个令牌。 缺点： 增加了系统的复杂性，需要维护缓存系统。 依赖外部服务，如果缓存系统出现故障，会影响整个系统的正常运行。 双令牌机制（Dual Token Mechanism） 定义： 双令牌机制是指使用两种不同类型的令牌来实现更复杂的授权和身份验证流程。 工作原理： 用户通过身份验证后，服务器颁发一个身份验证令牌（例如JWT）和一个授权令牌（例如OAuth 2.0的访问令牌）。 身份验证令牌用于证明用户的身份，通常具有较长的有效期。 授权令牌用于访问受保护的资源，通常具有较短的有效期。 当授权令牌过期时，客户端可以使用身份验证令牌向服务器请求新的授权令牌。 优点： 身份验证令牌具有较长的有效期，减少用户频繁登录的需求。 授权令牌具有较短的有效期，降低安全风险。 可以实现更复杂的授权策略。 缺点： 实现和管理双令牌机制比单一令牌机制更复杂。 需要妥善保护身份验证令牌，因为身份验证令牌的泄露可能导致长期的安全问题。 总结 刷新令牌主要用于在访问令牌过期后获取新的访问令牌，减少用户频繁登录的需求。 缓存令牌通过将令牌存储在缓存系统中，实现快速验证和撤销令牌。 双令牌机制使用两种不同类型的令牌来实现更复杂的身份验证和授权流程。 每种机制都有其适用的场景和优缺点，选择合适的机制需要根据具体的安全需求和业务场景来决定。...