@odirus

很多时候很多事情不是自己能够决定的，那就尽量让这件事情朝着自己利益最大化的方向发展，以前我也不愿意填，但养成这个习惯之后每天都会沉淀内容，整理知识体系，避免碎片化。

我就发现有些同学一件事情讲不清楚，写的东西别人也看不懂，必须当面沟通（ Battle ）才行，但以后如果去了一家远程办公的公司，那就完蛋了，所以逐步培养自己吧。

我们也要填，但我觉得填的意义还是蛮大的，确保任务要能够追溯：
1 ）开发前记录这个任务的需求来源以及会议结论（撕 B 结论）；
2 ）开发中记录遇到的一些重难点、可能的潜在隐患等，同时将 git commit message 与 issue id 关联起来，方便 Review 的时候让对方了解背景和想法；
3 ）开发完成后可以沉淀一些心得体会，可以用于后期的分享和自己的笔记沉淀；
我们是在记录工时的同时顺便记录上述信息（用的 Redmine ），可以让自己或者组长了解为此付出的精力以及这中间的过程，以后再追溯这个问题的时候可以了解当时的一些决策过程（需求上或者技术上）。

感谢各位，这个帖子可以关闭了，是我自己填了路由器规则后没点击保存，所以没生效。。。抱歉，我的疏忽

@Lunatic1 我这边只映射 3389 就是不行，不知道是不是网络本身的问题

举个例子，假设需要分别返回“课程信息”给 PC 端和 APP 端，他们需要返回的字段详细程度是不一样的，可以这样做

查询课程 ID -> 查询出该课程的详细信息 -> 缓存到某个地方（例如 ES ） -> 通过 Graphql 分别取各个端需要的字段信息 -> 返回给端

更新课程 ID -> 更新 DB 中的课程信息 -> 更新 ES 中的课程信息

要不每个微服务打包成两种？一种是 jar 、一种是 war，需要合并的话就把多个 war 包丢到一个 Tomcat 里面

如果使用最后一条记录 ID 来查询的话貌似要漏数据，假设数据如下
ctime, id
1, 8
1, 9
2, 10
2, 11
3, 12
3, 13

如果按照 order by ctime desc, id asc 的话查询结果是 （ 3, 12 ）
后续页面按照 "order by ctime desc, id asc where ctime < ${最后一条记录的 ctime} and id < ${最后一条记录的 id}" 的话查询结果是 （ 2, 10 ）

所以我建议查询方式是 order by ctime desc, id desc，第一页查询结果是 （ 3, 13 ）
后续页面按照 "order by ctime desc, id desc where ctime <= ${最后一条记录的 ctime} and id < ${最后一条记录的 id}" ，查询结果是 （ 3, 12 ），特别注意那个等号

有主键吧？

"select * from t limit 10000, 10" 变为 "select * from t where pk > ${上一页的最大值} limit 10" 这种方案试过没有呢？

前期的技术选型很重要，最好有前瞻性的思考。

刚开始起步要求快用 PHP 无可厚非，团队上来了就用编译型语言如 Java 等适合协作，新旧系统之间用 RPC 来打通，慢慢的把就老系统过渡到新系统，团队足够强的话也可以考虑引入 ServiceMesh 来屏蔽语言差异。

这样看来前期最重要的就是开放给外部的接口（例如提供给客户端的或者三方的）一定要有较好的扩展性；当内部有互相调用的时候要制定好系统之间的接口调用规范，也要有较好的扩展性，协议最好是跨语言的，可能会牺牲掉一些性能，但以后方便扩展到多语言生态。

总之，制定好服务与服务之间的接口规范，服务与外部系统的接口规范，以后内部随便怎么折腾都没关系。

我们这边的发展路线就是 PHP -> JAVA 、PHP （当时用的 Thrift ） -> Java -> 未来可能会引入 ServiceMesh 概念来拥抱多语言开发生态

@bazingaterry
@Artail

感谢，原来如此

我再咨询一个问题

如果我用了 stream 这类软件，并且在系统里面信任了证书（ iOS，Android 我知道有个版本问题），代码里面是否可以看出我用的自签发证书而拒绝响应呢？

我们再测试过程中用抓包软件比较多，所以想了解得多一些，感谢各位了。

@hshpy 我就是用的这种方式，我看了一下电影板块里面的猫眼数据是可以看到完整 API 响应的。主页搜索是看不到的

@n329291362 了解了

@kerro1990 @xi_lin

各位大佬，请问 “app 内置证书抓不到” 这个说法是用到了哪方面的知识点呢，想学习一下。

以前我发现有些软件不到包，是因为程序内部的 http client 可能没有实现代理功能，也就是说即使设置了代理，程序会这条规则。后面我用的是 Stream 这类软件（信任了自签发的证书），发现大部分的包都可以抓了。

如果按照我的理解，app 验证证书就无法抓包的话，一旦我使用了 stream 这类软件并使用自签名证书，stream 无法抓到包，那 APP 也应该无法继续收到请求响应了，但我今天开启了 stream 之后 APP 依然是可以显示搜索结果的，这个地方就很疑惑了...

我自己试了一下，应该是有部分抓不到，对客户端知之甚少，听各位大佬分析

我感觉 iOS 抓包省心很多

估计今天的钉钉消息队列堆积太多了，远程办公比平时交流得更加频繁。