数据不敏感的就直接阿里云盘，文件形式备份，免费额度足够，上行目前没限带宽，下行免费的比百度强 N 倍也是目前。
但是阿里云盘之前好像有过泄漏问题。

数据敏感且要求高的，考虑 nas + 异步多网盘加密备份。
之前用黑裙，挂载百度云盘和 oneDrive ，每天凌晨进行加密备份。

移动硬盘坏的几率可能比你自己硬盘坏的几率要高。

云计算不需要运维的吗[狗头]
其实不至于吧，大公司就算全量上云，云架构和服务部署维护，总需要人吧？
小公司的运维，其实不仅仅是服务器运维，还要充当桌面运维。
说缩减了岗位我认为，但是说革了运维的命倒不至于。

而大模型，我每天都会使用，使用帮我生成代码，帮我优化语句，提供函数/变量命名给我，
但是长期使用下，会发现早期 GPT2 幻想能力太强，总会根据语义幻想个不存在的方法给我，
GPT3.5 就开始好转，但是输出的结果大多数都需要自己调整一下才能使用。
如果说让它完成一个独立项目，我觉得我需要和它沟通轮数和时长不亚于我自己去完成。
而且 GPT 也有上下文数量限制。
所以说革了程序员的命不赞同，但改变了程序员编码方式就认同。

目前而言，我觉得 ai 真的是一个非常好且节省时间提升效率的助手，但说要让它负责整个项目，目前而言还是太高估它或低估了业务需求。

1 、如果是做一个适配服务，适配目前的 api ，统一使用方法，那我觉得可行吧。
*但是实际情况我看了下都是往 openAI 接口对齐的，豆包、腾讯、阿里 的。虽然接口是对齐，但如果是接入多个外部模型就变了你不能复用模型提供方的记录和限流，必须自己单独做限制记录。

2 、nginx 原生不支持，并且你还涉及到 产生你自己的 token 或 key 给每个部门。

3 、用自己熟悉的技术栈，但要考虑连接数的问题，可以优先考虑支持协程的。

这和 N 年前刚开始等保一样吧。
开源的堡垒机 和 某厂提供的堡垒机。
做等保的时候等保机构告知，不能用开源的，问了下为何，大概原因就是 某厂的 是经过 GA 进行报备的，但是开源的没报备。
如果出了问题，开源的那种需要自己承担问题带来的责任，而 GA 报备过的设备，就算后面发现问题，也属于不可抗因素不需要负责。

其实我觉得很简单的事情
1 、重复支付的问题，只需要执行退款即可，这个是个兜底策略。
2 、常规流程如下：
[前端]->发起预定请求->[后端]
*后端：生成订单返回单号；（没必要做幂等，就算抢购/优惠卷限购的场景，也是对应的方法进行判断而非订单服务主线程这里进行判断幂等。

[前端]->发送支付方式->[后端]
*后端：检查 流水表看是否有支付请求记录，如有则调用对应渠道支付检查，如发现支付成功返回给前端，如发现尚未支付成功则调用渠道的取消订单接口，把之前的支付订单取消掉。然后生成新的支付流水。
支付流水表：流水 ID + 订单 ID + 渠道 ID

[前端]->根据后端返回的支付信息，通过流水 ID 拉起支付->[支付平台]
[前端]->輪詢支付結果，或通過 ws/sse 獲取->[後端]

異步部分：[支付平台]->消息推送(关闭、支付)->[后端]
*后端根据流水 ID ，反查订单 ID ，然后通过支付平台接口二次确认支付结果，如结果一致，且之前尚未处理交易信息，则处理交易信息。如之前已经处理完了交易信息，则对本次建议信息进行退款操作,即一開始提到的兜底策略，這裡只需要保證流水 ID 是冪等即可。

上面應該還有一個是在於處理超時未支付訂單的流程，但這個主要看單量，不同單量不同處理方式，最簡單就直接定時取消，量大的就丟去隊列裡面消費，消費時候檢查支付結果即可。

首先我不懂 GO ，但看了一下大致流程，可能和现实有出入吧。
1 、首先通过 订单 + 用户 产生一个雪花 ID （全局事务 ID ）
2 、通过雪花 ID 进行控制幂等。
---------------如果我没理解错的话，上面这里就忽略了用户需要更改支付途径的场景了，
比如一开始选择微信支付，后来想换支付宝，此时按你这个设计，用户只能重新下单支付。


多层幂等性保障：
网关层限流有必要，去重毫无必要，只是徒增了系统负担，本来根据用户 ID 就能达到限流。至于去重，只需要前端一个 disable 就好了。PS：如果说开控制台修改的话，那其实写脚本刷 token 然后去请求也一样，并且你这里根据客户端层生成 token 进行限流，实际已经没了限流的意义了（因为我可以刷出很多 token ）。

服务端事务管理：
这里的 request_id 是一开始最上面 TransactionID 吗？如果不是没能理解。

同后端，也是 JQUERY 打底，但是选择上选择了 VUE2 ，因为小程序和 uniapp 都基于 vue2 框架（类似吧）。
然后今年也开始用 vue3,对我而言就是先按 vue2 写法写 vue3 ，然后再慢慢按 vue3 的模组形式去写。
至于 react ，没碰过也好奇也觉得神秘，因为实际使用上，发现目前大厂自己内部大多数都是 react 而非 vue

1 、虽然支持自动签发并且能挂载脚本重启服务，但是企业侧而言，如何确保执行 acme 脚本的机器没意外？
2 、如 1 所提，支持执行挂载脚本，但是如果涉及多个云服务，同时需要部署证书，只能写脚本同步到相关的服务中。但是脚本执行出错或有意外没执行，谁负责？
3 、我对接过一个项目，国内某个大厂的，他们有些节点应该还是用旧版 JDK ，不支持 lets encrypt 新的根证书。1 年前的时候，排查了很久，因为部分请求成功部分失败，并且别人对接没这个问题就我们有。最后问他们拿到日志，然后 google 了下发现是 jdk 7 没内置对应根证书的问题。
4 、就算付费的泛域名证书，价格也不贵（相对于企业而言），并且各大云厂商都支持自动部署到相关云服务。

@myki 先不说是否脱离题意，V2 这里禁止 AI 生成内容的回复

企业级 SSD 也不一定多能抗吧，只是相对消费级别的好点。
我之前也有类似的场景，最终我们直接找一台云主机存数据，本地当代理转发，后来直接把本地的也干掉了


上个月也忍不住，但我还是成为了垃圾佬；
主板：倍控-C618 芯片 MATX 4X2.5G 网口 全新 629.00
CPU：E5-2697 V4 二手 248.00 *1
内存：DDR4-2400 32G ECC * 4 二手 159.00 *4
硬盤：用舊的（ 1 個 1T NVME,1 個 500G SSD,1 個 4TB 紫盤）
電源：acer 550W 帶風扇啟停 全新 199
機箱：acerV300 全新 169.00
散熱：大水牛 凌霜 240A 168.00
散熱：挚科 内存超频散热器 99.00
一共 2148

目前在跑：
1 、openWrt 旁路由模式，用來科學上網，因為網絡是 FTTR 的。
2 、飛牛 fnOS ，負責共享，由於換硬盤時候另一個 4T 紫盤進水了，所以沒 raid
3 、開發機器，centos

進 PE,開 DG ，對對應的硬盤右鍵，選擇恢復分區表。
如果數據不重要直接操作，重要的話就找外面的。

亲身经历，早期就是入了退役服务器坑，虽然稳定，但是功耗比较高，并且很多新的不支持，如 NVME 、USB3.0~TYPEC 。而且我自己也真的并非 NAS 发烧，我只是 AIO ，装了 esxi 后热度一过就在旁浪费电费。
后来发现了某南的 X79 和 X99 支持 NVME 和 USB3.0 ，然后主板换了，CPU 也换了（因为便宜）。当时也因为退烧了，只是作为学习机用，但是偶尔 3~4 个月左右，开机都开不了，就提示内存错误，接着四条内存变 3 条能启动。又过几天又不行，又拔一条.....但目前开不了，想开的话要插插拔拔内存，通电几分钟断电再开.....

最后退烧了，不玩洋垃圾了，换了 7800x3d ，啥事也没了。至于一开始的 nas 需求，直接用 N100 的迷你主机顶替了。

dao -> service -> controller -> service -> dao -> controller -> ... loop

不知道你想幹什麼，這個 json 是發佈之後也是本地的，還是說發佈後是請求線上的。
如果是發佈後請求線上的，但是你現在想調試，你可以看看 mock 這方面得。
如果發佈後都是不需要請求後端的，直接 import

@pcxys 本地為何不直接 import 過來

1 、自己去 TB 购买光猫。
-可以和卖家沟通，确认了能注册再购买。

2 、打服务商电话一直保障，师傅上门问你就按实话说时不时就重启。
-要光猫密码是为了改桥接吗？如果是的话你让师傅换新的，直接帮你改桥接就行了，密码要不要也罢。
至于师傅愿不愿意帮你改桥接，这个其实你可以看不改桥接的话会有什么问题，只要一发生这个问题就打服务商电话报障即可，打多了师傅直接冲上来帮你改。

还好看到，赶紧下单了 5 杯咖啡，余额-120