再看了一遍描述，好像是同一台服务的两个地址，server bind 成 intranet 了而已？
iptable 能搞定

看你基础设施情况，比如有不有 公用 的 gateway , 或者 lvs 之类的

如果要轻的方案的话，试试 http://github.com/rapiz1/rathole

@peasant 我恰恰相反，忙的时候没时间写多少代码，闲的时候，就是不停的写，毕竟，总是有做不完的 feat/fix/improv ，没事来还还债也好

这是基础的并发原语之一，各 api 下设计都类似
eg.

cpp: https://en.cppreference.com/w/cpp/thread/condition_variable

pthread:

```
....
int
pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);
....
```

@AnroZ 对的，因为条件变量就是这么用的，或者说就是这么设计的

@thevita '通用' -> '同意' ......

@winglight2016 通用，最后先确定下自己 usa case 下当前的瓶颈在哪，感觉恐怕还不太行

只是“心脏刺痛” 而 没有 其他类似胸闷 的症状的话，大部分其实跟心脏没关系, 是 “肋间神经痛” 引起了, 一般只是间歇性出现，不用过分紧张，注意休息就好了，当然，还是要放在心上，如果出现持续没缓解，进行性加重，或是伴随其他症状及时就医。

用 IPV6, 今天刚搞了，暂时没问题. (直接通过 ipv6 连也行, 但是不能保证外面用的时候有 ipv6 ，相当于有两条链路了)

不是应该考虑优缺点的问题，单纯从逻辑上说，存算分离 带来了更高的复杂性，顺带的是更高的成本(大部分可能是折腾成本，但你好像不是很在意)，但这写复杂性都是为了解耦计算和存储资源，使之更灵活，更符合业务的需求，所以关键问题是，你是否面临这样的需求。（最后，我觉得你的需求应该不是 要不要存算分离，你的需求应该就是 "折腾"，那关系什么缺点呢？

都能用，我都用过

我原来在公司把 conf 和 jira 部在了一台上, subpath 方式(/jira, /wiki) 的方式用了几个月, 后来改成 subdomain (jira.xxx.com, wiki.xxx.com), 都基本没遇到什么问题

所以我的感觉就是 选 1. 因为, 方案 2. 的不足就是 我看着不舒服, 影响我心情....

就是用 ip 库啊，看你需求(准确, 更新, 粒度) 有免费的和收费的企业服务可选

现在在公网上扫描+批量打的基本都是, 挖矿 /勒索, 不会使用特别复杂的漏洞, 不会使用未知漏洞（因为划不来，追求的就是广撒网），如果你是因为这样中招，我要怀疑你的专业能力了

现在中招比 10 年前难多了吧？ 1. 个人用户来说, 各种全家桶别的不说，推更新还是很及时的，win10 后也有自动更新了, 基本就杜绝了病毒 /木马的泛滥，2. 对于专业 /企业 用户，确实面临的问题更复杂了, 这必然需要你自己有安全意识和基础的技能

看需求吧，如果你的 db 是支撑应用的，把 db 独立于代码管理更复杂吧？这种情况我也推荐用 flyway 这种方案，挺好的

你就说能不能用吧，会影响赚钱速度吗