搞 freeswitch 的时候弄过 stun 服务，专门获取外网 ip 的协议

frp/ipv6

盯上了倒数第三行，扫描行数高一个数量级

这是我不喜欢 go 的一个地方，没有构造函数，方法没有默认参数

最简单粗暴的方法是 while(sleep(1000)) {data = select db;if(data) break;}

@xylophone21 我更倾向于在 APP 聚合，让后端接口层更原子化，尤其是产品快速迭代时期，减小前后俩部门的沟通成本和联调复杂度。UI 变化时，前端仅需改变组装方式，只有业务逻辑变动时需要后端针对某个模块做修改。两个数据有交叉的页面，也只用维护一个接口。不太了解 APP，是不是原子接口也更容易封装组件。如果某个模块发生异常，其他数据可以正常显示。当然讨论前提必须是 h2，1.1 要么阻塞排队要么创建新连接，肯定无法接受

如果能上 h2 协议，觉得聚合的优势不大，反而增加维护成本

@x97bgt 大概算是更复杂的负载均衡吧，istio 的虚拟服务可以控制流量

灰度发布，上新服务时保留老服务，并且设置一个特殊标记决定流量往哪走，比如 http header，要求测试用客户端带上标记，同时服务内互相调用时传递，所以这个客户端走的都是新版本服务，而线上版本仍然是老服务

回想起第一次跳槽后老板说不用管 ie6 的喜悦

微信公众号发出的请求是 http1.0 的，istio 默认拒绝

你不分析怎么知道一坨字符串里面包含什么东西？你怎么就确定它是 map[string]interface{}？

code review 和做架构一样吧，需要根据实际情况柔性处理

@lixm 这个方案不错，阿里云的 DMS 企业版好像已经支持了

好奇使用场景，学习一下

apache 设置成多进程+多线程的工作模式，php 开启 opcache，mysql 热点数据同步到 redis
你还需要掌握一个压测工具，ab/webbench/wrk，一边优化一边确认结果

你们先坐一起讨论 api 设计，后端决定接口格式，前端决定需要哪些接口，举个例子
后端：统一用 post，返回数据是 json，其中有...公共属性，xxx 是状态码，xxx 是错误信息，xxx 是数据，登录信息放在 cookie 里
前端：我需要一个文章分页列表接口，返回标题，摘要，时间等等属性，还有一个文章内容接口，给我标题和正文

然后前端去封装请求方法，后端按刚刚的需求给出接口命名和返回数据格式定义，最好能上线一套假数据接口，两边就能同时开工了

基础知识类的问题找搜索引擎效率最高，经验和策略类的问题再找大佬