不要瞎写！不要瞎写！不要瞎写！
平时我们在调一些rpc/db数据或获取一些远程setting时，常常会把他们保存在本地cache里，但每次又需要考虑存本地全局变量还是cache组件，还要考虑序列化反序列化，保存时间，数据结构调整之类的事，导致一些类似的工作会搞好几遍。于是我就搞了这个duration_cache的东西，他只需要在你原先读取数据的基础上调整一行代码就可以帮你把数据保存起来，过期后再重新获取，一般是不需要考虑结构调整，也不自己处理过期，使用了泛型，所以支持所有类型数据。 具体本地缓存用的freecache，因为它支持单key过期时间，同时使用了zero-gc的策略，保证了性能，不过也不时动态扩容；另外有个点是每个key大小不能大于千分之一的总容量 另外使用了singleflight来保证不会有并发更新的问题 使用方法很简单： 原代码示例： cacheRs, err := cache.GetUser(ctx, 1234) if err == nil && cacheRs != nil { return cacheRs, nil } row, err := db.GetUser(ctx, 1234) if
现状 graph TB WIFI(交换机+WIFI AP) WIFI-->TV LAN1 --> WIFI optical-modem(光猫) --> ikuai WIFI-->LAN2 LAN2-->nas LAN2 --> debian12 WIFI --> cell1(手机1) WIFI --> cell2(手机2) WIFI --> computer1(电脑1) WIFI --> computer2(电脑2) WIFI --> Switch(Switch游戏机) subgraph PVE ikuai(ikuai主路由) --> openwrt(openwrt旁路由) openwrt-->LAN1(LAN1) LAN2 subgraph debian12 subgraph docker nginx bolg end end subgraph nas qbittorrent(qbittorent下载器) jellyfin(jellyfin视频服务器) nastools flaresolverr end
什么是ALL IN ONE 之前从v2ex上看到，中年油腻男的三大爱好是路由器、nas和充电头，虽然目前还感知不到充电头的魅力，但我一直是对nas念念不忘的，同时对软路由也是有点兴趣。 从当年最早的19年的蜗牛星际这类矿机开始，一直想着搞一台nas，只是拖着没下手，慢慢的蜗牛的价格涨了，做为所谓的垃圾佬觉得不管涨了多少，只要涨价那我肯定是亏了，这一拖时间更长了，直到最近家属特批了一笔自由资金，终于可以想着搞一台nas。 但是nas就是nas吗？当然不是，也要包含之前提到的软路由，另一个想要鼓捣的起点home-assistant，之后可以对接apple-tv、手机的影音服务器，自己网站服务器，偶尔会用到的windows等等都可以扔到上面，那就需要一台不止是nas的ALL IN ONE，通过虚拟化方式把这些系统都装在一起的机器。 怎么搞？ 吹的这么多，其实就是个普通的台式电脑而已，这么说也确实是，而且正常来说还是个配置比正常低的多的电脑，但同时因为它的用途特点，也会有一些特别的地方： 24 * 7在线：nas这类设备一般是24小时全天开机，运行稳定正常的情况下几年不关机也很常见，所以要求
一个老婆儿在河边洗衣服，两只老虎走过来，它们一边走，一边说话。 一只说：“咱把老婆儿吃了。”另一只点头同意。 老婆儿听了老虎的话，回到家愁得哭起来。一只蝎子足出来问：“老婆儿老婆儿，你哭啥？” 老婆儿说：“老虎打赌蹦黄河，半夜三更要吃我。”蝎子说：“别怕，它吃不了你。”说完就爬到炕边上。 老婆儿仍然哭，鸡蛋滚过来问：“老婆儿老婆儿，你哭啥？ 老婆儿说：“老虎打赌蹦黄河，半夜三更要吃我。”鸡蛋说：“你别怕，它吃不了你。”说完，就站在火合边。 老婆儿仍然哭，西瓜皮走来问：“老婆儿老婆儿，你哭啥？”老婆儿说：“老虎打赌蹦黄河，半夜三更要吃我。”西瓜皮说：“你别怕，它吃不了你。”说完，就站在门旮旯里。 最后，石磙子骨碌骨碌滚来问：“老婆儿老婆儿，你哭啥？”老婆儿说：“老虎打赌蹦黄河，半夜三更要吃我。”石磙子说：“你别怕，它吃不了你。”说完，它就關房檐上。 到了半夜，老虎来了，它在院子里大声喊：老婆子，为啥不点灯？” 老婆儿说：“家穷，买不起火柴，想点，你抽根干草点吧。” 老虎到炕边抽干草，蝎子狠狠蜇了它一下。它到火边点火，鸡蛋“吧”地一声崩瞎了它一只眼。老虎害怕了，扭头就跑，西瓜皮利溜一下，把
记得最早做app大家都提lamp，学会这4个就完事 现在写个代码，做个系统，设计个架构高低得k8s一下，k8s一来，那链路追踪、微服务监控、服务发现、稳定性方案之类的哗哗的就来了，那多了这么多东西，除了显得高大上，吹牛逼外，实际上多了什么好处？ 微服务的目的 我觉得就是2个点 解决复杂的业务： 业务涉及面比较广，一个或少量模块会让业务逻辑过于集中，使得代码越来越复杂，越来越庞大，耦合严重 在将要进行重构改造时会发现历史包袱特别重，很容易迁一发而动全身 稳定性不好，可能产生二级服务出问题拖垮一级服务的问题 扩容不方便，CPU密集型服务和io密集型服务对于扩容需求不一样 解决复杂的人： 参数业务的人数据太多，一个团队十几个人改同一个模块，可能会常常要去解冲突 不同的人不同的想法，一个模块很容易出现很多种不同风格的代码 代码互相耦合但又不互相负责，导致很容易带着别人的bug代码上线 微服务当前问题 有能力要微，没能力也要微 一些团队为了能解决好上面两个点，带入了微服务，但微服务又需要一整套链路才可以发挥一个好的作用，而这套架构需要一个完整的基础、运维团队来维护，这是一笔成
eLangX
