@Cielsky 要脑补的地方实在太多了。原问题唯一出现的一个有用的名词，“根目录”，还需要被脑补成“根分区”。

这需求都描述不清楚，诸位是靠心理感应作答吗？

@nightwitch 现代解决方案都是虚拟化隔离，类似 unix 的场景都是几十年前的事情了。真没有 root 。socat 这么简单的，预编译好的静态二进制也是一堆的。直接扔到 ~/.local/bin 不香吗？

看了这个问题。

这个连 IP1 和 IP2, IP3 是不是公网 IP ，基本 IP 类型，后端有没有 root 权限，如果是内网 IP 在不在一个 vlan 这些统统没有说。

缺少这些信息，只能是用户态代理 L4/L7 转发。

还有
@nightwitch 能告诉我哪个发行版没有带 socat 要自己编译的？

要排查的话，用 memory dump

一般来说是驱动，跑一下 driver verifer

@i3x 关机以后还能充到 100% 应该还是固件有问题。我有印象的时候，电池的充放电都是可以控制的，不会自己充。

@qiumaoyuan 用 Linux 玩老笔记本这个厂商规格手册还是要能自己搞到，而且要还会看，不太可能有人和你有一模一样的本子，而且花时间搞这些事情。一般联想应该都可以改这个。这种事情最后一招是这样的：笔记本电池排线肯定有一条是控制充电的，绝大部分把那根线用物理手段断开就不会充电了，电池拿不到充电信号是不会开始充电的，不过硬改后果自负吧。

这个看具体电池上的 IC 的。只是控制阈值，有些电池就是 cat 写入一下 /sys/class/ 下面的文件，不需要什么 tlp ，具体要查一下厂商文档。

@neoblackcap 这个当然谈不上对错。只是想看看一开始选 celery 会是基于什么考虑。

@tulongtou 我估计你们应该是 django 这类，而且要有个任务展示管理的页面。

@ipwx 说的就是这个问题，redis 不是正宗的消息服务(message broker)。如果我换一个例子，比如说用 rabbitmq ，是用 pika 还是 celery 的话，可能更好一些。

你说的 job queue 。kafka 有一个叫 kq 的库。现实是非常简单的。kq, rq 这类库的实现说白了就是 Worker, Queue, Job, Message 这四个类。这个其实是一个类似于 web 服务的 MVC 的范式。就和不能说所有的 web 服务都必须要有 MVC 一样，不是所有用到消息服务的，都一定要遵守这个范式。

运维是个框。

只要不是开发的工作，都算是运维。很多公司，连审计和等保都是运维组负责。

说白了就是没预算，又需要一定专业知识的杂活。

之所以最后都转开发也是这个道理。因为运维的多余的预算是没有的，省下的开发工时、CPU 内存肯定不会变成运维的奖金。最后，要多拿钱必然是在跳槽和转业务线中选一个。

手动狗头一下。CPython 的 gc 机制难道不是重启吗？

我觉得 CPython 的 gc 研究可以用一行代码总结：

gc.set_threshold(0)

@hidemyself OA 系统能有一千在线算不得了了。现在做电商基本是用大厂平台。都是在对接各大厂的接口而已。那种电商的业务系统，本质上就是 OA ，都是业务逻辑复杂，其实并没有什么好说的。就算单做微信，也有各种微店供应商，完全不想花钱，直接用官方小商店好了。

要连微信都不做，流量又不能从天下掉下来，那估计 SKU 只有个位数，并发几百，几千个交易，项目就算成功了。

这种也没有说要推广吧？真推广，政策就直接捆绑了。现在明显没有，连等保也没有要求。真有要求的都是比较关键的地方。

保密的话，按原则讲，什么样的密级，用什么等级的加密。你让所有人都用上这个加密，不等于给自己增加攻击算法的人数吗？

@presoul 我没做过 dot net ，所以不能直接举相关的例子。但是 flink 这种算是简单的，按理就算没学过 Java 也不难理解。你可以去看一下它的 kubernetes native 实现。应该可以回答你的问题，简单说至少也需要选出 leader 和实现并发锁，这个分布式应用回避不了的。

你这种应该是把原有的应用迁移至 k8s 。比较大的应用肯定是有自己的一套框架的，没有涉及这方面的改动，很可能是框架已经实现了这一部分，只需要一个地方去查找刷新一下活动节点。这种事情多和同事沟通。人家肯定比 v 站上不知道哪来的人，更了解自己的系统，同事不好沟通，也应该好好分析应用的行为和代码。

一般 k8s 部署的系统不可能简单到只有几个 web services ，或者并行计算实例。

哪怕部署过 flink 也应该知道上 k8s cloud native 的应用还是需要改不少东西的。默认靠 service 完成不了需求。自己写 operator 或者应用直接调 k8s api 。你要说没有必要，这锅后面就是你的了，这玩意实现，我觉得没有什么难度，但是具体到应用也是一件麻烦的事情。

你的用户是开发，用户说有必要，你“感觉”没有必要。你再想一想说“感觉”合适吗。

@idblife istio 或者说 service mesh 的核心，其实是一堆 CRD ，算是定义流量怎么走的一个标准——telemetry 这些暂时不讨论——相当于 nginx.conf 语法的东西。

原生 service 功能太少，ingress 功能多一些，但是肯定有 api 的。api 你过一次，无论是 nginx 还是 envoy 都意味着延迟增加。

简单的说，一切都是砍需求。当然，要流量分发，不太可能砍到连 envoyproxy 都不要了，至少目前为止，网络插件还没有普及。但是还是可能减少流量通过 envoyproxy 这种的次数。需求砍到一定程度，istio 去掉你觉得不必要的功能，也就差不多了。

@idblife istio 大部分在 L7 算简单的，linkerd 估计更找不到方案，不然就是让开发在框架上做，还有就是 k8s 的网络插件上做。都是比优化 istio 更复杂，而且用的人更少，istio10% 看具体需求。我觉得还能再争取一下，但要再省，也就这三条路了。你确定真的需要，我只是假设从 8% 降到 1% 吗？追求这指标的成本是指数级增长的。

istio 本身我不是太喜欢。推广做得确实是比较优秀的。

不过运维大点规模服务的系统，一年至少化掉几百万小一千万吧，都是厂商求着给你做的。就这连优化 istio 也做不到的话，做 AB 分发这种基础需求还需要在 v 站上讨论，未免太不靠谱了。

这种基本上都要基于特定的版本和生态环境讨论。真的生产上组件和版本的选取也不是想怎么来都行的。厂商一般都是谈生意的时候，顺便帮你整个方案。谁没事会在 v 站上讨论这些？

OP 给的信息也过少。不会是哪个集成商在 v 站这里薅出一个方案文档？感觉可能是甲方上过一个 istio 失败了。所以这次不能用 istio 了。

就算在这里拿了个方案，感觉让 OP 实施，失败的概率还是过高。

只是提醒一下其它人。

是只是光解析，还是这个域名直接可以被访问。

如果是解析以后的域名是通的，这个不管有没有触发域名备案系统，都是必须处理的。因为涉及到钓鱼的问题。