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

羡慕下就罢了，否则最终就成为金池长老了。
自己够用了，能维持目前生活那就够了，没啥好比的，要比为何不和 2 马 1 刘比？

@snipking 换了几批，嗷嗷给你干的没见过，嗷嗷发代码问你的一大堆，再不是就一句我不会。搞到有时候我都怀疑是不是自己哪里出现问题了

@sam7ikoma
第一个问题：出师有名其实不太重要，现实中哪来那么多圣人，真的想开不是随便找个借口的事情吗？
第二个问题：这就有点......你说的完全正确，但按 OP 的说法，我猜測是 OP 所在的公司本來用第三方的，然后机缘巧合下找到了 OP ，接着在想把自己公司用的做成行业通用去卖，故成立开发部门，但找人难，且公司想控制成本，所以调了两个人给 OP ，这种时候其实做什么和是否做出来成效不在 OP ，如果 OP 真有高昂的信心我觉得早就润出来自己干了。
第三个问题：我觉得这才是 OP 的主要问题，所以上来发帖不是找方案，是发泄一下而已。

不过第二个问题，我之前看法和你完全一样，但现实却是找了一堆智障的给你，你说不行就说你不会教人，增加 HR 招聘成本；你要勉强用就越用越生气，问题基本是传递给你让你解决，又怕背责又嫌麻烦。更主要的是当你想夺取人事权，就开始觉得你是不是没事干工作不饱满。

不过最后，希望在座各位都没经历过这些糟心事。