{"id":36700473,"url":"https://github.com/oreoft/true-love-n","last_synced_at":"2026-01-12T11:37:46.665Z","repository":{"id":216588780,"uuid":"741724451","full_name":"oreoft/true-love-n","owner":"oreoft","description":null,"archived":false,"fork":false,"pushed_at":"2026-01-12T03:04:55.000Z","size":960,"stargazers_count":0,"open_issues_count":1,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2026-01-12T07:58:42.762Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/oreoft.png","metadata":{"files":{"readme":"readme.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2024-01-11T01:26:14.000Z","updated_at":"2026-01-12T03:04:59.000Z","dependencies_parsed_at":"2025-04-27T01:18:08.098Z","dependency_job_id":"f6c27ff3-167d-46c1-82e5-1d206230b96d","html_url":"https://github.com/oreoft/true-love-n","commit_stats":null,"previous_names":["oreoft/true-love-n"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/oreoft/true-love-n","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/oreoft%2Ftrue-love-n","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/oreoft%2Ftrue-love-n/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/oreoft%2Ftrue-love-n/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/oreoft%2Ftrue-love-n/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/oreoft","download_url":"https://codeload.github.com/oreoft/true-love-n/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/oreoft%2Ftrue-love-n/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28338971,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-12T10:58:46.209Z","status":"ssl_error","status_checked_at":"2026-01-12T10:58:42.742Z","response_time":98,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-12T11:37:46.600Z","updated_at":"2026-01-12T11:37:46.655Z","avatar_url":"https://github.com/oreoft.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"## 一、背景\r\n\r\n满足自己需要定制化一个微信机器人，之前用的一直是查克大佬版本，然后fork出来修改。随着长时间的使用，有些自己特殊需求没有办法满足，在上面开发扩展性和稳定性都比较差。\r\n\r\n最初查克提供的版本只是作为群聊天的机器人发布，后面我有一些定时提醒、at触发回调、接受三方回调消息等等需求，然后都往这个服务写，之前架构是底层dll注入到微信 -\u003e rpc把消息传出来 -\u003e 本地客户端应用。然后所有业务写到这个客户端应用上，我来数数它要承载的功能：\r\n\r\n\t1. 启动入口(需要拉起微信登陆)\r\n\t1. 接受伪装拦截发出来的rpc请求\r\n\t1. 序列化并且发送rpc请求，\r\n\t1. 起http服务器以及对应接受逻辑\r\n\t1. 起定时任务以及各类定时任务逻辑\r\n\t1. 处理业务(与大预言模型交互，爬一些数据然后清理返回等等)\r\n\r\n服务是不支持热更新的，所以可能我只需要改一个定时任务的逻辑，为了生效这个改动，我每次都得重启整个服务和流程，而且服务越来越臃肿稳定性也很差，有时候可能是一个地方线程处理问题，导致程序卡住，然后机器人就容易丢消息。\r\n\r\n所以我打算进行改造，目的是提高服务的稳定性，丢消息率降低到0%， 提升消息并行处理能力；增加服务扩展能力，提升后期维护开发成本。\r\n\r\n## 二、架构流程\r\n\r\n针对遇到的问题，提出对应的解决办法。查克大佬的sdk已经足够完善，并且社区也很活跃，所以底层依然保持查克大佬sdk\r\n\r\n我把这部分 dll注入到微信-\u003e rpc服务端收/转发消息 -\u003e rpc客户端收/转发消息 保持不变，但除此之外不再做任何的事情，把这个成为base层，然后新增server层来专门处理业务逻辑。\r\n\r\n![image-20240109181654205](https://mypicgogo.oss-cn-hangzhou.aliyuncs.com/tuchuang202401100816234.png)\r\n\r\n## 三、设计目标\r\n\r\n![image-20240109173537617](https://mypicgogo.oss-cn-hangzhou.aliyuncs.com/tuchuang202401100735733.png)\r\n\r\n## 四、设计思路及折衷\r\n\r\n1. 对于base层，配置都采用硬编码，把所有配置尽可能转移到server层，我希望base它比较薄，除非是大的需求否则它可以保持一年半载不需要重启。设计想法也非常简单，入口启动文件，http服务文件，robot操作底层sdk文件，基本上三个文件就搞定了。**并且这是内网服务，所有接口都不鉴权。**\r\n   1. 入口文件启动robot程序，启动web服务器\r\n   2. http服务器文件里面把以下接口暴露\r\n      1. 发送文本消息\r\n      2. 发送图片消息\r\n      3. 获取当前登录所有联系人信息(包括群)\r\n      4. 通过wxid查询昵称\r\n   3. robot操作底层sdk文件最重要的就是把rpc发过来的消息进行http转发到server服务(做好异常处理，如果下游服务挂了，消息就直接丢了)\r\n2. 对于server层，这部分相对来说可以好好设计，因为里面业务相对来说比较复杂，有抽象的空间。这个服务改动进行重启，也比较好，不会需要重启微信，启动速度也比较快，都是http的服务比较可控\r\n   1. 所有消息过来，经过gateway，进行消息的过滤和转发，不同的消息走到不同的handler\r\n      1. 先判断群消息还是私聊消息\r\n         1. 如果是群消息\r\n            1. 先看群是否在响应群里面\r\n            2. 然后再看是否被at\r\n         2. 如果非群聊消息\r\n            1. 如果是文本消息，统一都进行回复\r\n      2. 然后再进行判断是否是聊天消息，还是执行消息，还是查询消息\r\n   2. 推送回调请求， 上面的接口是给base调的，这个接口是给公网调用的，往base推送消息\r\n   3. 定时任务模块，定义成模块，在入口函数里面调用，然后保持一直运行。\r\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Foreoft%2Ftrue-love-n","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Foreoft%2Ftrue-love-n","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Foreoft%2Ftrue-love-n/lists"}