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 吧

ipip.net 免费的有限制，提供收费版本

试着回答以下几个问题：
1 、业务的高峰期是什么时候？访问量是多少？有哪些服务器资源？高峰期服务器资源占用情况如何？
2 、新上线的业务预估访问量比旧业务高 10 倍，能不能公用服务器？新购服务器需要什么配置？
3 、业务量没有变化为什么访问变慢了？
3 、各历史业务高峰期服务器资源变化有什么特点？

@fan88 Panabit 的商业版是绑定硬件的，主要是做了网络驱动优化和授权管理

@Eytoyes 金山安全早几年就改名“猎鹰安全”了，硬件设备向来不是他们的强项。
1 、如果自己的团队有一定的技术能力，考虑成本可以选择 Panabit(派网)。这个产品有开源版本和商业版本。开源版本有性能和接入用户数（ IP 地址）限制
2 、选深信服。深信服设备的 UI 界面和售后服务在行业里是有口碑的。某种程度服务抵消了设备的不足和缺点。
3 、对设备性能有要求的（例如接入数量过万）需要综合评估，一定程度上厂商支持硬件设备的定制化配置

1 、存储系统自身的稳定性（内核匹配、异常处理机制、数据同步、数据传输、性能影响等）
2 、存储软件和硬件设备的匹配，硬盘固件（如 SSD 芯片类）、网卡固件、网卡驱动等

多云业务切换有 2 个重要的点：一是自有的技术团队有实力，二是要解决数据库层面的问题。CDN+多云可以解决前端访问的问题，但是后端数据库的问题需要技术团队评估解决。

云原生环境其实没有解决数据库的问题，云原生数据库解决的是 OLAP 的场景（偏数据库分析），OLTP 的场景仍然依赖传统的数据库，某些场景还需要依靠硬件性能。

如果是 OLTP 的业务场景+数据量大的情况需要评估数据同步、数据一致性问题（存在主备、评估脑裂）已经故障发生时校验数据的实际和切换时间。理论上如果需要实时自动切换只能通过数据库底层存储设备级别的同步功能才能实现（考虑 IDC 间的距离+光信号延时，不同云厂商的通讯即使是转型时延也无法满足）