@docx #11
他的 IP 是黑名单 短信敏感不让你发短信或者邮箱验证码而已

@ChenDJ #10
没有起诉流程吗？

沈阳这边就是
三环以内户口不能上摩托车

但是有完整流程，你就按流程行政诉讼，有完整教程，铁路法院指定管辖这类案件，他们天天的案子全是这种，拿判决就上牌。甚至网上有写好的起诉书文本你改个自己个人信息，再配几个你自己的个人情况证据，就行。

铁路法院判一个这种案子只要 30 秒，也不开庭，都是不开庭审理直接给判决书。而且你胜诉连诉讼费都会延迟很久以后退给你。

@Ilavena #6
非家庭摇号，你知道满 5 年开始摇，十年内摇到的概率是多少吗

@cdlnls #6
大胆点 99%

@inza9hi #45
按照你说的，我就假设你是做广告联盟类的业务，大写入记录，流出基本就是一些死的参数，其实这个很匹配我这边现在的一个系统，就是纯向上写入型的

我这有一个 mysql 单表日写入记录 1.3 亿行的，写居多读极少，报表为主的业务，到一定日子就狂删数据 后端 MYSQL INNODB CLUSTER 汇总库 存储规模已经接近 10TB 级数据 这也是我这边最早吃 innodb cluster 螃蟹的一个应用

也是用户侧延迟敏感的，甚至都不是 https 的前端，都是 websocket 的前端，为了快速把用户侧的采集数据反馈回来，是长连接反馈数据的

程序架构直接分布了，业务跑在边缘，后置汇总数据

这种用云厂商负载均衡器本身就没啥卵用 我这给出的结构都是直接分布式多级数据，后置汇总
这样才能保证偏远地区的末端延迟，单纯的你放在一个 BGP 的全国中心点都不可接受

就这种系统，我这单月云带宽成本都不到 2 万，各种钻云厂商计费模式的空子
而且还有各种云下单线数据中心处理区域请求

这个架构不是单纯的云架构，要站在一个高处，能去指挥整个业务程序的架构铺设，进行规划，可用性，用户侧延迟，都做到极限，否则没啥用

@inza9hi #45
这些都得根据实际情况去分析 各种流量图 请求模式 用户分布 时段分布都得结合 再去匹配云上的计费模式 需要个能站在全局角度还熟悉云服务的人去规划设计

显然随便找外人 大概没法匹配你公司的商业机密保密需求

招个有合同保障的，懂行的能统盘全局的架构设计，好好做方案，一点点通过实验性切换去验证，这样公司商业机密安全也有保障。
另外，再跟阿里好好谈谈折扣，你这议价能力太差了。。。

基本上以你现在透露出来的这些信息，以我的经验大致确定你们是花了大量冤枉钱的。。。

gemimi 的特点就是快，别管他会不会，不会也会尽快给你编一个

你要找的是不是 FXP

@paopjian #11
这年头 卖 29 块钱的鼠标都接入 deepseek 了

@Leoking222 #13
从零开始，你得加个零再乘以二
商业软件人家开发成本分摊到了销售数十万套里面
你自己一套……

我猜不是打锚点固定在墙上的
打锚点固定在楼体上的几乎不会出共振