@irisdev 原理就是空间/资源换时间。单一实例，因为 CPU 内存 操作系统的限制，无论是数据库还是 JAVA 应用，吞吐量都是有上限的。所以人们发明了各种拆分工具，比如一次请求，从 DNS 解析->NGINX->多实例和服务化治理->数据库主从/读写分离/分库分表，都是在干这个事情。

1 代码实现 就是 sql 写各种 union all
2 框架实现 相当于封装了一层，本质可能也是 union all
3 中间件 相当于把框架抽出来独立做了一个服务
4 数据库 几乎也是 union all
我这里说的 union all 可能不限于是 sql 语句，就是表达一个汇总的含义。本质上就是把一块大资源拆成若干个小资源。以提升 IO 性能和查询性能。

不在意速度就 CloudSync 同步，在意速度，你还是得开会员。

AppleTv 上的 infuse 加载 Plex 。在加载一个 NFS 的服务（解决 plex 不支持 ISO 的问题，我基本已经把所有 ISO 的都刷成 H265 mkv 了）。
其他设备，也是围绕着 plex 服务为中心去构建，比如我家投影仪比较差，就安装 kodi 加载 plex 。ios 设备就是 infuse + plex 。在家用 infuse ，出门用 plex （ plex 可以比较简单的实现内外网切换，但前提是需要公网 IP ）。
这样家里的观看记录就全在 plex 上了，既能利用 infuse kodi 强大的播放能力，又能够在不同系统的设备上同步历史。
但是目前 Plex 基本处于网络断连的情况，刮削，账户认证都不正常，不推荐这样的方式了，可以以 jellfin 为服务中心去构建。

我首先意识到这并不是个 git 问题，而是一个工程化的问题。就是我有一个通用能力，但是也有若干定制能力。会发生如下情况：
1 通用能力需要及时推广至所有客户。
2 定制的功能随时都有可能变成通用功能。
3 定制的功能 A 要 B 不要 C 要但是与 A 不同.....。
4 通用能力 有些客户可能不需要，或者有些客户需要定制。
目前这种方式无解，因为软件费用给压的太低，所以公司上层觉得能够用所谓的“通用”+“定制”节省成本，最终会搞出四不像，降低软件质量。
我能想到比较好的解决方案就是把通用能力以 jar 的形式让别的项目进行依赖。你要是定制就在自己的工程里随便开发，如果有相似的，copy 改。如果用到通用的功能，就把 jar 引入。

这是一个好问题。感觉问题的本质是，操作系统把操作共享文件协议模拟成了操作本地磁盘。然而不同文件夹共享之上没有一个总的协调。操作系统不知道这几个文件夹同处一个物理磁盘，就没办法进行优化。

可以试试，但是别当成主力。感觉国内特别流行的商业模式，一开始铺的很大，各种推广，让你上了船之后，开始各种表演了。开源一般来说不是一门好生意。

绝对有好处啊。结合调用链，有利于跨平台日志收集、分析、追踪，不过前提是，你公司的得有这些基础设施。