Kong 企业版会在国内直接面向企业用户销售或者通过做企业信息化实施的厂家集成销售吗？——来自一个用了好几年 Kong 开源版并且最近在评估 APISIX 的传统行业信息化人员

喜欢 Consolas 又要用非 Windows 系统可以试试开源仿制品 Inconsolata

还不是你们（我们）惯出来的毛病

另外，HTTP API 给 web 前端浏览器里用 JS 调用和给第三方应用系统的后端调用也是两种不同的场景，对最佳实践的选择也有影响。

如果发生错误，是与业务逻辑无关的系统错误（不论是客户端还是服务器，自己方还是外方），还是与系统无关的业务错误？前者表明系统没毛病，是用户操作的错，要由用户解决，并且允许出现的常态；后者表明用户操作没毛病，是系统的错，由技术人员（某方的开发或运维）来解决，即使发生的频率不低也不应该视为允许出现的常态。有些错误很容易分辨出属于哪一类，而有些就需要技术和业务都精通的老司机才能准确分辨。HTTP 状态码和 body 数据之争的本质是，针对这两类错误如何设计报错机制。

@iyaozhen 屁股决定脑袋。你所谓的对业务的监控，是指想知道业务挂了，这个问题本来就属于基建。我也说了，如果业务系统里发现有基建问题，硬生生抓住包成一个 200 抛回给调用方，这个我也不能接受的。但很多莱塞特福原教旨主义者想要做的是把业务逻辑层面的错误也给放到 HTTP 状态码里，比如一个大学生离校系统里要去查学生在各个单位的业务是否已结清，我一个图书馆系统的接口发现还有书没还的时候，给他返回 HTTP 200 再加一个 JSON 表示业务层面这个操作不成功，但我的系统没挂，调用方传进来的参数也符合 schema ，权限也对，所以在 HTTP 层面我认为没问题，不应该返回错误码……有人说这样不清真，应该改成在 HTTP 码里把这个当“错误”来返回，不能塞进 200 的 JSON 里。这不是扯鸡巴蛋吗。总不会有人为了方便监控离校系统调用图书馆系统接口时的业务逻辑错误率而想把我千奇百怪的业务错误码从 JSON 里提出来放到 HTTP 状态码吧。

当然，我坚决反对 JDBC 连不上数据库服务器的时候抓出来异常还要包到 200 里向上返回……业务逻辑上的错误（责任在甲乙方最终用户，不涉及基础设施运维）用 200 包起来返回是一个美丑的问题，基础设施错误还要这么搞，是沙雕还是沙壁的问题。

至于拿监控说事的……监控啥？

如果是为了监控基础设施，我 JSON 里封的是业务逻辑层面的错误，关你基础设施屁事？

如果是为了监控业务错误，却嫌错误代码封在 JSON 里不方便……你就是想让我把业务错误代码放到 HTTP 里去对吧？你是不是觉得我这边各种各样的业务错误怎么映射到 HTTP 那几个状态码里很简单？你个普罗米修斯崽懂个屁的业务。

我的业务 API 又不只是为了让你来做监控而存在的，我要给别的业务单位调用啊。HTTP 状态码没出错，业务状态码出错的时候，可以去找管业务系统的人处理，HTTP 状态码出错了找管基础设施的人处理，这两拨人不是同样技能的啊。业务端有个什么狗屁错（而且还不是那种 unrecoverable 的外部环境错，是业务逻辑的错，要业务用户处理的）都返回成 HTTP 错误码一级一级传上去，查个业务级错误都要基础设施的人联动，这是制造民怨吗？你来给我做基础设施架构让我有办法一键定位出错的层次和节点吗？可是我只能拿到够做业务功能的经费，而且是单个单个项目做，没有做基础设施的条件，我让一个行业人士起家的地方性行业性中小型业务信息化开发商给我做业务系统开发的时候顺便免费做一套云原生的微服务的可观测的可这个那个狗屁的基础设施，并且以后的其它同类业务开发商要逼着他们不允许用自己的积累，一定要做在这些所谓现代的平台上，这忒外祖母的现实吗？

@adoal 我这么说倒不是反对用 HTTP 状态码表示业务状态，而是说要想清楚以自己的团队和周边状态、项目背景、后续配套支持力度，甚至是组织机构设置、职权划分、撕逼流程，这样做是否真的能把事情做得更好，需要付出什么样的代价，做得更好的结果是否会引发其它可能的问题？工程上做选择都是 trade off ，有些看起来好的，能不能落地好是要结合实际的。

@jorneyr 你不是没说清楚，是没理解别人的答案。别人的意思大多都是让你换用支持 VPN 的路由器设备。不过这个事其实可大可小，往大里说可以问运营商卖 MPLS VPN 服务，这个可以做到全透明的，你自己的路由器都不用配置。不过看你表述，只是“可以购买路由器”，那应该不会花这种钱。网友们推荐的 WG 、ZT 之类的，看样子你们也未必有人能搞定技术门槛。那……关键词“蒲公英”可以看看。就是做向日葵远程控制的那个公司出的硬件。

用 HTTP 状态码表示业务结果，需要对业务和技术都有深刻理解的老司机做精心设计，否则会画虎类犬。
HTTP 状态码数量就那么一些，而业务的结果状态数量是不可控的，随着业务接口膨胀起来，如何映射到 HTTP 状态码的分类，如何表示业务状态细节，都不是空口说一句优雅、规范就能解决的，是要实打实一个个干出来的，要踩坑踩水甚至踩屎的。
在实际架构中，可能经过 API 网关以及其它各种反代和中间件，业务状态逐级向上传递，业务状态码跟基础设施状态码在同一个命名空间，必然会导致设计工作量和难度更大。
最后，在 HTTP 状态码的命名空间里表示业务状态，受惠最大的其实是做系统运行状态监控的。但，同样的问题，如果没有业务和技术都足够资深的老司机来做设计，很可能出现监控信息的无序，失去意义，甚至搞出用 AI 过滤有效监控异常的笑话。
先不说团队素质、集成方团队素质、遗留系统对接之类的非技术问题吧。
总之，理想很美好，但是，陈皓给用户方做咨询的顾问团队能做好的事，不等于人人都能做好。

申请国家核高基（误

其实你在 Linux 下的做法也不地道。Linux 下，在生产环境跑的守护进程，当代的主流做法是写一个 systemd unit 来做启动控制，而不是用交互登录的帐号手工启动。Windows 下也是同理，要做成服务。

满满的人文关怀👍

执行力真棒

商用补贴民用。民用宽带的质量是政治任务，只好贴钱，通过商用宽带的商业手段割羊毛补回来。

以前我们中层领导在拉我们部门开会时说过一句话：我这个外行来的领导现在能在 XXX 界得到同行尊敬，是因为上级任命我坐在这个位置上，一但把我调离，XXX 界的人遇到我根本不会理我，只有你们在这个行业有积累的专家才会不管坐什么位置都能一直得到同行尊敬。

当然，这并不能改变我们必须听他命令的事实，不论是否合理，内行外行。

我见过的商用品牌机都是负压。商用机就是个干活工具，换代很快，没必要为了精心呵护做正压设计。