seafile +1

@yyzh mtu 9000 的巨帧注意用来提升网络传输效率和降低对 CPU 的消耗，在云原生的跨数据中心的传输中搭配 Vxlan 应用，实现容器或虚拟主机跨数据中心实现二层网络的自动漂移

聚合支付的意思本就是一个二维码同时支持微信和支付宝的支付。需要添加备注是什么意思？如果是需要知道客户是通过微信还是支付宝的支付，直接在支付成功的订单中查询就可以了。

共用云厂商的资源定价向来都是计算资源（例如 ECS ）会非常便宜，并且是主要的促销对象（类似于星巴克里面的依云矿泉水，消费者在对比咖啡和水的时候就不会觉得咖啡贵了）； RDS 数据库（包括类似的 Redis 、Kafka ）和不同类型的对象存储才是云厂商的利润点，如果简单的和自建的服务器资源对比，可能会相差几十上百倍。

小规模并且业务增长和实时性要求不高的业务场景可以直接购买 ECS 服务器，然后在 ECS 服务器上安装对应的数据库也能使用。不足之处是需要自己做好数据库的维护，优点是同等配置的 ECS 自己配置数据库（即使是高可用配置）也比 RDS 服务器便宜好几倍。

涉及实时性要求高且重要的业务（例如支付类）在自有技术配置不足的情况下，还是建议直接使用 RDS ，毕竟只要简单操作就能使用，并且具备高可用和性能扩展的特点

支持一波，功能整合是趋势

这个厉害了，支持支持

11-02 20:04:44 [b152f9869d464b599c299bd152616354] [local] [threadPoolTaskExecutor-122] INFO -- exec result: ShellResult(exitStatus=137, out=command terminated with exit code 137)

这个线程退出提示的内容是容器里面的吧？容器里面的 Shell 退出要定位到具体的容器，通过容器内部的信息定位确认。在主机层面是很难定位容器内部应用的错误的

不容易啊，这种情况身心煎熬

支付对接相对简单，但是支付如果需要同时面向 B 端和 C 端提供服务就很复杂了。仅仅是涉及的账户系统和分账的功能就需要考虑不同的场景：

比如商户的结算款会结算到商户结算账户，支付公司在银行开的账户叫备付金账户，备付金账户又分存管户，收付户，汇缴户；个人账户，企业账户；会员子账户，商户子账户，中间担保户。

费用入账时，可能记一笔账，也可能记多笔；比如商户佣金费用，则会入两笔账：成本账户入一笔扣款，商家佣金账户入一笔收入；而扣款不用冻结，收入需要冻结 7 天。

需要把业务逻辑梳理清楚，技术上的实现倒是次要问题。有些看起来很简单的内容后端的逻辑其实比较复杂。
1 、面向消费者端的相对容易实现，需要考虑的是用户的支付流程（是否下单支付？支付后的流水对接门店还是对接公司？门店是个体工商户，公司是一般纳税人。如果对接公司，门店之间怎么分账）
2 、是否考虑促销和会员？ 2 者是否需要结合？是否需要配套的后端管理会员和促销信息？
3 、产品图片的上传和管理是门店操作还是专门的团队运营（产品的宣传图片谁制作，谁上传）
4 、顾客在下程序下单的信息通过什么方式传递给门店（收银机？显示大屏？）如果需要，怎么考虑对接
5 、会员的对接、管理等

从公告的内容来看，“服务语雀的数据存储运维团队在进行升级操作”这句的意思给人的感觉是第三方（或者说不是语雀自己的团队）由此推断：
1 、语雀团队更关注功能和日常的运行维护，不涉及存储管理（或者说只是使用存储资源）
2 、存储资源可能是第三方资源（阿里云或是蚂蚁内部存储资源），应该是分布式存储（类似于 ceph ）
3 、存储集群的服务器资源使用的是旧服务器（新服务器可能是另一个群集），旧群集基于之前的业务可能长时间都未更新升级（能用），也没有考虑逐步迁移的新群集
4 、旧存储群集出现问题（例如硬件故障导致磁盘空间或是同步故障等），受技术限制（内部没有技术资源长期维护旧版本）短时间无法迁移切换到新群集
5 、通过数据恢复的方式迁移切换到新的环境（但愿）

@luoshengdu 实际不太可能 8T 数据完全占满的。但是高负载情况下磁盘同步的速率确实很低

同时需要确认整个磁盘阵列的可用空间是多少，如果已用空间占了磁盘的 80%，那可能需要更长时间。像 8T 这么大容量的硬盘如果配置 RAID6 风险还是挺大的，主要是数据同步的时间太长，如果是同一批次的硬盘是可能存在通过过程中其它硬盘故障的情况

商用环境还是 SD-WAN 线路把，其它的操作在线路出现问题后（例如网络不稳定、卡慢等）只能自行慢慢尝试，商用的方案有售后维护支持，最主要的是不会受不可控因素的影响

@crazychang CMDB 也是需要管理和维护的。一方面自动化程度不够的话，资产会记录不全或是无法及时更新（例如新增了软硬件配置等操作），在这个基础上做自动化的应用会存在风险；另外就是管理的维度，如果维度太粗可能无法记录所需的细节内容，太细则对技术和环境要求更高。

需要和日常管理紧密集成，最终还是要回到二次开放或是自研的道路。另外通过 CMDB 提供知识库的需求也需要慎重考虑，毕竟 CMDB 的核心不是文档管理

还是要看日志的反馈。重点检查连接数和端口的配置情况。

@yngzij 正规的零售行业都会用的吧。想想那么多的支付 APP 和支付方式（微信、支付宝、翼支付、各大银行 APP 等），通过被扫的方式支付，普通的商家不可能只支持一种支付方式，也不可能有那么多的技术能力自主开发对接不同的支付方，因此聚合支付的存在是有理由的。只要是合法的聚合支付

1 、这个行业只能靠规模产生效益，短期内微盈利是不可能实现的（亏多久、亏多少）
2 、商业模式只能存在于现有的外卖平台无法覆盖的地方（差异化发展但也注定没有规模）
3 、日用品的商品毛利（非快餐、盒饭等即食商品）在 23%，商家和用户愿意为多出来的平台费用和跑腿付多少费用
真正要做的话把源头做起来经营，例如预制菜或是半成品菜等这样加工后的商品

有技术团队且需要大存储容量的，预算有限的企业用 TrueNAS （ 64G+12*8T Sata + 2*480 SSD+JBOD ，RAIDZ2+缓存）可用空间 60T ，已稳定运行超过 6 年
个人还剩建议用 unraid 吧