markgor

数据不敏感的就直接阿里云盘，文件形式备份，免费额度足够，上行目前没限带宽，下行免费的比百度强 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 、就算付费的泛域名证书，价格也不贵（相对于企业而言），并且各大云厂商都支持自动部署到相关云服务。