@autoxbc 国家除了要求互联网企业数据落地境内以外，还要求外企在国内是中外合资，且外资持股比例不超过 50%。
意思就是在中国境内开设公司，公司的实际控制人是中国人，不受国外控制。

另外补充一下，有些注册中心用的是 push 模式，有的用的 pull ，有的用的长链接轮训。 主动 push 和长链接轮训的这种，如果 B 能优雅停机，那么 A 是能及时获取到最新的服务列表。

如果 B 异常 down 机或者网络故障，那么 A 依然还是要做好回退策略的。

是的呢。
各个 service 也是定期从 eureka 获取最新的服务可以用 ip 列表，然后本地按照一定的策略去访问。
如果某个服务 A 挂了，B 服务本地从 eureka 获取的 A 服务 ip 列表还没更新，那么也是会出现访问到已经 down 机的那个 ip 上。

要么做好服务 fallback ，要么做好故障转移

为什么不能有这些内容呢？
git 的本质是一个版本管理工具。
除了代码以外，合同、文章等文字内容也可以使用 git 进行版本管理。
github 不是 codehub 。

@mikeven 都是无线的。

那真是太好了。
现在的 iCloud 部分请求需要连到国外去，各种卡顿。

什么病啊，小病没必要挤大医院啊

批量更新在并发度不高的情况下就很容易造成死锁。
特别是隔离级别在 RR 的情况下。
跟 mysql 锁机制有关。

本质上就是树结构的遍历算法。
BFS 请用队列
DFS 请用递归 or 栈

关闭 facetime 和 imessage 、共享相册，然后专门注册一个邮箱只给 icloud 用。

看标题的意思得出 lz 的目的主要是想拉一票人一起来 diss 这种写法的程序员。
在实际应用里碰到数据库 select 、json 等反序列化情况可能会出现 null 值使用 primitive data type 导致的 NPE 问题。
另外楼上也谈到了 null 值在许多场合的确是有实际语义的，用特殊值取代 NULL 的定义有时候反而是弄巧成拙。

lz 这种就是经验不够但是又觉得自己很牛逼的那种。殊不知小丑竟是我自己系列。

浮点数做运算会出误差的。
0.3+0.3+0.3 算出来的结果是 0.89999999999.
强行四舍五入精度不够的话，容易产生误差，假设一笔误差 0.00001 ，一天上百万笔交易金额产生的误差就会以千万为单位。。一年下来就是好几百万了。

@dingwen07
话说现在这个 winget 我有两个比较不满意的地方
一个是需要开代理
另一个有时候 windows 的安装过程是有一些选项的，winget 安装时候直接用的默认选项一步到底，事后配置麻烦。

单个用户频繁更新算不上并发。直接加行锁完事了。
就算一秒钟更新 20 下，行锁都是绰绰有余。
你觉得不合适大概率只是你自己觉得，跑一下压测就知道了，大多数情况只是杞人忧天。。

一般来说都是结合 http status 和业务状态码一起用的。
40x 系列表示这些请求已经进入到了应用内部处理，但是由于请求参数不对、权限不对、url 路径不对等原因应用内部返回了这些错误状态码。
50x 系列表示 http 请求中间经过的某个网关发生了异常、超时，或者请求已经进入到了应用内部但是应用内部出现异常等原因。

200 表示请求已经已经进入到了应用内部处理。至于业务里出现的一个错误码，比如余额不足、账号未实名认证啦这些，当然需要添加一个 code 表示异常错误来方便前端进行处理。

其实业务 code 和 http status 也有重叠的地方。比如查找 id=1000 的 book ，https://xx.xx/detail?id=1000 ，你就会去纠结到底是 404 还是弄一个业务 code 。我自己的偏好是 404 只用于 url 在后端是否有对应的 RequestMapping ，对于根据某某参数、条件查不到某数据的这种情况我喜欢放到业务 code 里。这样的话 40x 、50x 系列的 http status 的功能就更偏向于运维监控层面而非业务相关。而且这样还有个好处就是内容传输协议不再局限于 http ，我可以随时调整协议格式，比如采用 grpc ，我不需要再去考虑迁移协议后怎么兼容原来 http 404 的问题，因为我的数据返回的业务 code 里已经涵盖了 http 404 的这种情况。

前端这边肯定是先进行 http status 判断，然后再进行业务 code 判断。

说到底还是因为 http status 这东西已经出现了几十年了，跟不上现在的互联网应用变化，所以国内的设计都是以实用角度出发，存粹把 http 协议当成是一个传输的载体。现在很多公司做的接口甚至都把 url 部分废弃掉了，需要访问哪个接口把服务名称写进 http 参数里交给后端做分发。

github 早期的 url 是很 restful 的，后边规模大了，也开始不 restful 了。也就 V2EX 上一群没见过世面的小学生喜欢把 restful 挂嘴上。

我 2018 macbook pro ，插着电源用了一年，循环不到 30 次，结果电池容量就已经只剩 85%。
长期插着电源并不是什么好事。

最好的方法就是扩展 spring ，
同时 accept 接受 application/json 和 application/x-www-form-urlencoded 两种 request ，
这样你们爱传啥传啥。

nodejs 前边几年吹的很厉害，前后端一把梭。
经过几年时间的检验，nodejs 在后端届并没有展现出杀手级的应用，反而还被异军突起的 go 和 k8s 杀了一道。
现在 nodejs 基本已经沦落为用来 js 打包、本地 webpack 调试一类的支持工具了。。。