@5261 是直接指定 Nginx 的内网地址

按照中国会计准则的新规定，数据作为企业资产可以计入“无形资产”，我认为这并没有任何创新，因为在中国的企业会计准则中，很多年前就已经把“软件”定义成无形资产，可以进入财务报表。

“数据”的形态是什么呢，不就是 API 或者 XLS 、TXT 、CSV 文件吗？或者就是 010101 的二进制机器代码，这些技术对象本身就是“软件”的一种，所以数字化的数据资产其性质根本上就是软件，再去定义“数据是无形资产”，纯属画蛇添足。

软件资产的估值方式一般采用购置（包括重置）价格或者开发成本，数据也可以采用类似方式，然而数据生成是自动的、甚至是熵增，所以实际估值非常困难——我经历过几个数据资产估值项目，目前根本没有符合准则的公认方法。

seafile?

iredmail

感受下气氛

showdoc 吧

云环境中 ECS 之类的计算资源很便宜，这个主要是用来引流和对标的（让人觉得云上资源很便宜），但是以下这几个大头的应用就被忽略了。
1 、RDS 数据库服务（特别是启用了高可用多节点的群集），可以参照自有 IDC 的数据库配置让顾问报下这个费用（ CPU 、内存、存储），这里的存储是按存储容量收取费用的
2 、Redis 或 ES 群集费用
3 、网络带宽费用
4 、安全费用（ WAF 之类）

也可以换一种思路：用 ECS 主机自己搭建 MSSQL 的高可用环境

1 、将现在的 RDS 服务改为 3 台 ECS 服务器
2 、在 ECS 服务器上自主安装配置 MSSQL 服务
3 、配置并启用 MSSQL 的 always on ，如果可以分离数据库的读操作
4 、是否需要启用 NLB 结合使用效果再调整

一是看这个出错的页面报什么错误 大部份的是数据库没有正确配置导致

另外去安装的后台界面看安装的日志文件 日志文件里会有详细的出错信息

@lengrongec ZFS 文件系统肯定是没问题的，存储最大的要求是稳定（硬件和相关配件的稳定也是基础要求）。如果使用普通的机架式服务器可以考虑 truenas 系统（需要稳定的考虑 freebsd 的版本，但需要注意硬件和系统的匹配）

飞书里的会议功能

@lengrongec 当前分布式存储都是基于 IP 网络，FC-SAN 和匹配的 HBA 卡和 FC 交换机只能配置独立存储（传统的磁盘柜模式）。也就是只能选 ZFS 的方案

想法是很美好的，但是零售涉及很多环节，各个环节都需要均衡不能出现短板，否则很容易栽跟头。要从这些环节上思考自己的优势和特点。和软件行业类似，店铺经营也需要有自己的特色能力才能匹配对应的消费群体。
1 、店铺位置。包括但不限于店铺的租金（要不要转让费），租约要求（能签多少年）、店铺覆盖的人群（流动人员、小区、单位、城中村等），例如小区对应的群体（消费能力，可以看小区的停车费用、所停的车辆、车辆的价位、小区的主要人群：老年、家庭、中年、实际入住率：看每晚亮灯的情况等）。综合这些因素评估成本和服务的人群

2 、商品。生鲜商品的损耗大概是 40%，如果没有把握，需要先少量进货试点。商品的品质也决定店铺经营的口碑，如果没有稳定的进货渠道（ 1 、畅销的商品不能经常缺货 2 、价格需要保持稳定 3 、商品的口味保持一致）很容易搞砸口碑。
同时需要结合店铺覆盖的人群选择相关的商品：考虑消费能力、年龄层次、消费需求、店铺自身特色等

3 、经营。日常经营涉及的方面更多。店铺的卫生、环境、灯光、温度、商品摆放和促销策略都需要按不同的条件调整并保持

4 、优势部分。能玩转系统和会员。会员积累和口碑效应是面对竞争的优势，只有保持这 2 个优势才能确保有盈利的可能（要考虑品牌连锁竞争开店）。好的口碑需要时间积累（商品品质、价格、服务）。

综合分析，要做好长期考虑（例如预计亏半年）积累经验、客户资源和口碑，通过长期的品质和口碑引流，最终实现类似会员的区域性经营（这也决定了目标客群不太可能是老年人和对价格敏感的人群）

@euph
1 、收集和消费数据。只有线上下单商家获取到的客户信息才是最全面的（例如微信 openid 、手机号、手机型号、手机配置、手机系统版本、IEMI 号码、商品信息、下单时间、历史购物记录等），从这些数据里可以提取消费者的标签：例如高端消费人群、进口食品爱好者、足球季、夜宵、90 后、烟民等，即使商品上盈利能力有限，这些消费者的数据标签（包括个体和群体的）也能产生价值（内部营销推广或者卖给外部的商业企业）

2 、降低运营成本。这种类型本质就是个仓库，只需要每天定时补货即可（补货时同时整理商品陈列摆放），同时店里没有人员服务，发生客诉也只能通过线上的方式维权，这样的方式其实就是线上商城小型化同时搬到了线下，连补货的操作都可以是通过系统管理，实际经营者都不需要出面甚至只需要出钱开店即可（需要考验后端系统管理匹配能力和门店实际损耗）

新零售火起来的时候，大量的资本入场，认为可以类似互联网那样先把规模做起来后面再考虑盈利和商业化。

天猫和京东小店开起来的原因一方面是有大量的费用（例如门头广告费用报销、商品价格优惠等），另一方面门店投资人员（个体户）也认为大品牌有商品和供应链价格优势，加上互联网式的营销推广（有地推团队），规模一下就起来了。当然，电商对这些门店也有对应的管理要求（例如门头、灯光等）和考核机制（从电商拿指定金额的货，例如每周或每月 5 万）

但实体零售的经营不像互联网那样通过简单的模板或是功能定制就能搞定用户，让用户买单。它的经营涉及多方面：店铺的环境、灯光、卫生、服务态度；商品对应的目标客群（城中村、CBD 、工厂、家庭用户、高消费人群、老年人、90 后等），不同的客群对应的商品和服务要求都不一样

商品的选择也是一样，如果是便利店，大部分的饮料、牛奶这些即使是电商也没有特别的优势（数量少和配送时效要求高），高毛利的商品例如电器用品这些，零售的这些门店又不具备服务能力（了解产品和流程，售后和安装的对接等）

店铺经营的人员水平参差不齐或者说能力一般，学习能力和接受新事物的能力有限，基本上玩不转会员营销、私域流量运营这些的工具，更有一些的完全是请人管理，每天就只是打发时间。

以上这些在没有具备规模化的复制和管理能力（需要经营监督到店巡查的人员）前，这类门店是不可能具备盈利能力的，因此刺激政策暂停、补贴结束、门店回归正常营业后就只留下一地鸡毛了。

@cnoder 这个是最早尝试的方法，达不到要求有 2 个原因：
1 、默认无法基于被访问的域名判断（当然可以通过 openresty lua 代码读取 $host 和 X-Real-IP ，但如果配置的二级域名较多或者是经常变化就很难动态调整）
2 、最大的问题是已经建立的连接无法实现网速的限制（频率控制也不够平缓，有延迟并且突发的峰值对整体网络有影响）

@wheat0r 主要是想了解有没有实现这样需求的成功案例。和防火墙联动肯定是可以实现这样的特性，但是怎么样配置对接？有哪些坑和难点？需要有清晰的认知

@fenglangjuxu 基于 Nginx 这类的 HTTP 协议不行，在原理上它无法对已经建立连接的链路重置（如果是服务端主动发起重置请求则需要更改后端应用，这个就不具备普适性）

@fenglangjuxu 用过 openresty 的一些插件，也没有匹配到合适的。特别是针对云盘下载已建立连接的这种无法按要求限制网速。我在想是不是 Nginx 是 7 层应用，而针对网络限速的是四层的原因，所以无法做到有效的限制。

按这个理解有没有可以通过 Nginx 和 防火墙（或网关）联动的配置案例？