@lower 可能实际上是一个 shar 文件，打包了之后再通过 shar 工具在头上加一段用 sh 写的自解压代码

@AllenHua 我是说它并不“原始”

可以理解为，Arch 并没有像 rpm/deb 一样为它的打包格式取一个单独的.arch 或者.pacman 的名字来刷存在感，只是很朴素地叫它 pkg.tar.gz 而已。

@AllenHua “没想到还有 pkg.tar.gz 这种原始 Linux 安装包”……这个理解可能有问题。tar.gz 只是一种把多个文件包在一起的归档格式，并不是说跟普通的 tar.gz 文件一样“解开就行”。某种打包格式用了 tar.gz ，甚至文件名末尾显式写了.tar.gz ，并不说明没有跟 deb/rpm 对等的控制机制。其实 deb 包的实际归档格式就是 ar ，你能说 deb 就是原始的 ar 安装包吗？

如果是淘宝这种级别的一互大场景，你需要考虑的不只是这两个操作（我觉得称为两个“方案”用词太豪华了）的技术细节差异，如同前面几楼说的，可能需要做架构设计先。
如果是普通的小规模系统，你是一个新手，只是做一个普通的简单查询……那么，建议先学好 SQL ，理解关系数据库。ORM 只是把人肉写 SQL 换成编程语言这一侧的书写方式而已。

这种多口**充电头**就是真的只能当充电头用，也就是说连上去被它供电的设备自己是要有电池的，不适合给无电池的设备供电，后面这种需求要每个设备用独立的单口头子。

连三元运算符都能吵起来，那 if expression 你们是不是要当魔鬼了

趁着年轻还能折腾得动早点润出去是好事。
但除此之外全都是槽点。

比如说用 Python Flask 写的可以参照这个例子 https://gist.github.com/jrialland/bf017843bbead538c20c382a19d880fe
其它语言和框架应该有类似 trick

因为后端的应用并不具备“意识到自己有可能运行在前缀路径下”的能力，所以动态页面里生成的静态资源链接还是按照自己运行在根路径下的。
要解决这个问题，要么改造后端程序加入这种探测能力。要么（不一定能 100%完美准确判定）在 nginx 里加入改写规则，对后端返回的页面里静态资源的绝对路径做改写加上前缀。

这种涨法……有一种加速主义的即视感

“基础设置中也有选项概念吗？”那反问一句，你理解的基础设施是什么呢？
最基础的虚拟机、存储、网络、安全策略显然都是有配置选项的。往上一层，关系数据库、键值数据库、缓存、负载均衡也都是有配置选项的。

问题不只出在你这端。一线互联网大厂优化掉的架构师在社会上输出只适合大厂场景的架构价值观也是对中小规模非互联网的行业信息化生态的伤害。

@aapon 那可以考虑直接找运营商要 VPN 方案，说不定可以给你们 MPLS……当然这个可能你出面不行，得做一个方案往上报。

你所说的“但在国产化操作系统中不完美兼容”，应该就是 SSLVPN 客户端的问题。那么用正经的 site-to-site VPN ，在网络层面路由能通，对使用国产化操作系统的机子来说是透明的，就不存在兼容性问题了。当然，根本还是要看上级监管部门的要求。如果想#3s 说的那样一定要拉专线才能过审，那就老老实实拉专线了。安全政策是底线。

“某 SSLVPN”大概率是深信服的吧……这种 VPN 就不是针对物联网设备和服务器的。它的目标是给不做 IT 的普通文员从单独的个人电脑上连企业内网用，只要打开浏览器按提示安装插件后用户名口令登录就行，比 site-to-sited 的正经 VPN 少了复杂的配置分发操作。
你有什么特别的理由排斥硬件 VPN ？既然都要考虑等保了，那成熟的标准协议 VPN （比如 IPSec site-to-site ）应该是优选考虑的方案。最好选有网络设备背景的厂家，比如华为、华三，而不是深信服这种只做安全的。
不过呢，还不如拿你们的需求先问问你们的等保评测服务商。虽然，等保是一个政治行为，有“做等保的懂个屁安全”的笑话，但人家毕竟是吃这行饭的，见多识广，知道各种坑。