好久不见，2024年一整年没有更新 bubble，因为实在是经历了太多丰富的事情了。

具体干啥了​

首先我的网站虽然首页没有更新，但我的 self-host 清单却变多了，而这些服务大多数都运行良好，SLA也超过了 99.9%。这些服务包括但不限于邮件的收发、CICD、运维监控、笔记、工作流等，并且这些业务中的绝大多数都能完美接入 SSO 服务，我想如果我有时间，我会分享一下这些项目。

与此同时我发起并参与的项目“米物百科”也上线了小程序和网页版，并且新增了几位核心合作伙伴。这个项目应该会持续下去，并且后续会继续新增更多的功能。如检索、更多的信息、对比等。可以去围观一下：https://mijia.wiki 。

2024年我还参与了一个较大的开源项目发布前的开发工作，感谢小米及生态链的各位大佬以及米粉朋友们，我也认识了不少可爱的小伙伴~ 另外欢迎点 Star（虽然点了我也不会有奖金）：https://github.com/XiaoMi/ha_xiaomi_home 。

饼​

对，还有之前画的饼。

limail 的项目其实已经可以用了，并且我也在用，非常好用。但未公开，因为成本实在是太太太高了。 其实项目主要分为两部分：

1. 邮件匿名平台：提供一个匿名邮件地址，类似 iCloud 的隐私转发邮箱。可以实现一网站一邮箱，有效避免垃圾广告。
2. 消息处理平台：将接收到的邮件或其它通知，经过大模型进行分类及压缩，对推送的消息进行压缩，并推送到指定渠道（比如飞书、bark等）以实现验证码、邮件的摘要发送。避免每次阅读验证码需要花费大量时间寻找。

看到这里各路大佬们应该猜到成本巨高的部分了。我正在考虑将第一部分开放出来，允许注册与非注册用户使用。

• 如果你有统一身份管理信息，可以到 https://scarborough.lzj.ac.cn/ 使用
• 出于合规原因，下面提及的功能目前不对互联网开放注册使用（仅科研及测试使用）。如果你是高校、科研机构的导师、或者我的朋友，请通过其它方式或邮件与我联系 jimmy@lzj.ac.cn。我会很高兴收到你的信息。

Scarborough 斯卡布罗​

Scarborough 是服务台框架，类似一个 Console，用户可以在 Scarborough 平台使用各种科学研究与服务工具。

平台作用​

我规划了许多的项目正在开发，包括知识库、数据仓、智能流控制系统、Limail 等工具。这些工具可以相互配合使用，比如可以使用 数据仓 的指定内容可以使用 智能流控制系统 自动归纳到个人的知识库中。

如果为每个平台独立开发一个 Console 将会无限增大开发与维护难度，也会造成使用的割裂感（特别是在移动端，不方便切换多页面的时候）。Scarborough 就像 一个巨大的集市一样，为各种工具提供一个统一的使用入口。以后会可能会陆续提及这些功能。

Limail 身份系统​

Limail 狸猫是一个消息与身份管理平台，旨在合法的情况下从根源上解决账号安全问题、消息混杂问题。

• 统一信息管理拟解决的问题：

1. 消息来源渠道过多，过于混乱问题。
2. 信息或通知信息熵与信息价混乱，错过重要信息或被无关消息浪费时间问题。
3. 验证码在一堆无关文字中无法迅速找到的问题。
4. 通过邮件或其它方式发送的验证码，无法快速复制的问题。
5. 消息来源无法验证，消息内容可能存在有害信息的问题。

• 在信息安全方面拟解决的问题：

1. 当你的一些识别信息，比如电子邮箱、手机号或者用户名被知晓后，这些信息可能会被用于尝试登录其他平台，以检查你是否在那些平台上也拥有账号的问题。
2. 在网购活动后，可能会出现频繁接到自动语音电话的情况的问题。
3. 点开一份邮件后，对方就已经收到你已读邮件的信息的问题。

上面的问题只是冰山一角，狸猫系统需要解决的问题不仅仅于此。

上图了​

这个网站终于终于，我把图片功能开发好了，丢张AI生成的图纪念一下：

提示词： 想象一个古代欧洲宫廷风格的数据中心油画：一座豪华的大厅，墙壁上挂着精美的壁毯和典雅的画作，天花板上有精致的雕刻和金箔装饰。在大厅中央，放置着服务器大型机柜排列着，上面装满了服务器设备。机柜之间，穿着传统宫廷服饰的人物（男性和女性，展现不同种族）忙碌地在机柜间来回走动，手持羽毛笔和硬盘。在一角，一个穿着华丽服饰的贵族（白人男性）正凝视着一个装饰繁复的屏幕，侧面还有几个人在使用MacBook。整个场景融合了古代欧洲宫廷的奢华与现代数据中心的科技感，展现了一种独特的时空融合。

让我们根据这个描述来生成相应的图像。

最近在忙于英语的学习还有学校突如其来的、堆积如山的作业。首页这部分会暂时更新内容，特性的话等以后需要了再添加。

这是一段我在账号管理功能上的成长史，如果你只想了解现在我所使用的技术请跳过成长史部分。

成长史​

• 最早在 2008 年搭建我的第一个 page 的时候就想实现登录、注册等功能。当时正值小学期间，最多就只能通过 Excel 实现的账号管理登录。
• 接下来是到了初中，接触了 VisualBasic，能方便地实现一个账号登录。但遇到了两个问题，一是VB程序很容易就被反编译出密码了，联网认证又不会（甚至不会写服务器端）。 二是一个exe程序还是经常更新的那种，很难给朋友随时演示，也不方便传播（毕竟谁知道你的程序会不会带病毒）
• 接下来还是初中，用 VisualBasic 实现了多 Windows 服务器监控和基本管理、基础 Web 后端（返回个字符串之类的，什么标准什么Json根本没有）。 当然，网页端也实现了登录：基于404找不到 xxx.com/密码.html 实现的账号密码验证。
• 到高中的时候，PHP 已经达到了“世界上最好的语言”。登录也实现了，但是账号密码存储方式是：基于文件存储。 回过头想想，数据库比我做的什么基于文件存储简单多了，但是我却从一个大家都走的平路和奇奇怪怪又难走的路线中选择了奇奇怪怪的路中最难走的一条。
• 到大学时，有了自己的时间。现在不但用上了数据库，还用上了各种数据库和加密方式。下面就是最近更新的账号管理机制。

使用开源账户管理​

选型介绍​

目前，我对账号管理方法是域控+单点登录。虽然原理大部分都懂，也实现过，但是想要做成一套可视化界面实属工程量巨大。 所以我将目光瞄准到目前的开源项目中去，比如 Zitadel。根据 Zitadel 的 SDK 我也成功对接了不少平台，但其中也遇到了不少坑。 具体对接和部署的问题在 Blog 我就不一一赘述了，等我上岸（起码一只脚上岸）再整理这部分的资料。

担忧的点与解决方案（只要我不看他就没事）​

1. 这种项目会不会突然割韭菜？我认为的是，如果他割韭菜了，那就是时候自建了（或者找下一家）。
2. 遇到 bug 自己又修不了很麻烦？既然是开源项目，提 pr 就好了，顺便成为开源社区的一员。
3. 公开技术栈会不会遇到针对性攻击？会，但无可避免。 即使是自建也难免有漏洞，而且故意隐藏技术栈其实难度并不小，需要从底层或者核心修改大量信息，所以我个人来说，对于我的大多数项目我并不会选择刻意隐藏使用的任何技术栈。 只能做好蜜罐、攻击溯源、防火墙和服务与数据分离等手段。
4. 认证系统会有流量攻击吗？会，过 CDN 只是为了静态响应更快。防御步骤分为以下内容：先分区清洗（地区、ASN、运营商）再到全量清洗、做好攻击溯源与特征记录（剩下靠法制）。 当然攻击意图也很重要，我分为三种情况：误打，无可避免。对于乱打，如果是因为觉得好玩...要不考虑下与我联系，互相交个朋友少个敌人？对于恶意打...我谢谢你啊？

账号分配​

目前我可以公开使用的工具和服务会尽量开放，但是有些资源因为实在是成本太高了，或者出于保护机制（比如毕业设计内容），我不得不设置身份验证，请见谅。

能要账号吗？出于合规原因，我暂时不会向外提供任何信息登记渠道。如果你是高校、科研机构的导师、或者我的好朋友，请通过邮件或其他方式与我联系 jimmy@lzj.ac.cn。我会很高兴收到你的消息。

我将网站架构从 Next.js 迁移到了开源的 Docusaurus，同时也将服务器从之前的服务+CDN架构迁移到了完全的Serverless环境。

1. 关于迁移到 Docusaurus​

目前，我一个人的开发速度尚不足以支持我构思的平台。因此，我决定将更多的资源投入到我认为更关键和令人激动的功能开发中。当然，这可能会导致一些不便，例如某些以前的高级Web操作无法实现，但这不会妨碍我继续沿用之前的设计和我的用户界面（UI）设计。同时，我的开发工作也将持续进行，包括组件和图标的设计。

如果您不是专业开发人员，也不熟悉 Docusaurus 是什么：

• Docusaurus 是一个完备的页面设计工具，我（作为用户）可以全身心投入到内容创作，而无需担心各种排版问题。当然，如果我需要特殊的排版或更多功能，也可以在基础上进行定制开发。
• 我认为最大的好处是 Docusaurus 基于开源社区，因此可以随时获得社区提供的新功能，例如新的按钮、输入框等，而我无需花费太多时间在这方面。

2. 关于抛弃传统服务架构​

在这次更新中，最显著的变化之一是我抛弃了之前的传统服务架构，转向了完全的 Serverless 架构。虽然从理论角度来看，我可以列举许多采用 Serverless 的理由，但以下几点才是真正打动我的原因：

1. 成本问题​

从传统服务器架构转向微服务架构后，在相同的运算量储备情况下，我的实际支出减少了约60%。

2. 简化运维​

几乎不需要进行繁琐的运维工作。

• 首先是负载均衡： 我们需要考虑负载均衡，但无需担心服务器层面的负载均衡。当然，如果碰巧涉及到无状态服务，我们可以在CDN层面进行负载均衡，从而显著减少了维护负担和成本。
• 然后是服务器自身的问题： 包括网络、系统、安全和系统更新。尽管在使用 Self Host Serverless 时仍然会遇到这些运维问题，但面对简单且经济实惠的负载均衡解决方案，不必担心由于一个服务的失误而导致整个服务器崩溃。当然，对于财力雄厚、一直使用专用负载均衡的大企业来说，这个问题可能不成问题。
• 接下来是部署的问题： 传统部署方式通常涉及关闭服务、复制文件并重新启动。但是在容器技术和Serverless技术的帮助下，这些过程几乎不再需要。再加上现代的自动化部署流程，目前我的大多数网站（约90%）都已实现自动化部署。

3. 安全性​

这一点非常有趣。尽管不能说Serverless化就一定更安全，但至少关于系统安全层面的问题变得更加抽象化。我简单列举一下安全发展的时间线：

• 2020年：使用密码通过公共网络登录服务器，数据库也在服务器上。
• 2021年：通过证书登录服务器，将数据库放置在与互联网隔离的另一台服务器上。
• 2022年：使用证书登录服务器，不再使用专用服务器存放数据库。
• 2023年：所有公共服务都不再依赖专用服务器。

这里是一些以前的碎碎念

• 5/22/2023 页面标题逐渐适配，前端缓存命中率98%。
• 5/16/2023 更新了一堆东西，真 · 一堆。
• 5/12/2023 Perfect，现在这个页面可以通过专用工具编辑而无需修改代码！
• 5/9/2023 当你看到这段文字的时候证明这个网站前端已经被我使用NextJs又又又重构一次了：
  1. 前端已经实现了SSR+SSD+CSR，首屏时间大大降低并且有更好的SEO效果。使用NextJS的技术。
  2. 既然SSR了，老办法OSS肯定不是很行得通，云服务器维护起来又麻烦，所以实现了Serverless+云虚拟容器。
  3. 登录注册这个目前还在研究SSO+AD，毕竟...对接的平台太多了。
  4. 这个网站发展方向主要是做技术分享与资料共享，也会涉及到一些个人的小工具和私有的一些小功能，我也不急毕竟我的小破站也没什么访问量。
     以上的技术后续会写成文章分享（画饼）
• 2/23/2023 上了一批私有系统，集群基本完成。首页正在使用 React重构，以快速实现跨页面的功能。
• 2/22/2023 登录系统从本地搭建 OAuth 技术栈切换到 LDAP/SSO 的研究。
• 2/11/2022 功能也挺麻烦的，不过这个网站应该不会鸽掉毕竟服务器给了钱的。
• 8/10/2022 网站的 UI 初步完工。
• 1/30/2022 最近在搞云存储模块，上线了一些小功能做测试和给几个常聊天的朋友测试，稳定性不错。但是数据备份有很大难度（主要是贵）。