举个例子，假设需要分别返回“课程信息”给 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 抓包省心很多

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

已经通知 3 号开始上班。

点赞

你是在哪里收到通知的？我也去看看

一直喜欢在天涯看贴，爱好八卦，😺

@Vegetable

好的，谢谢了。目前我们 APP 嵌入的网页也要求能够在浏览器里面正常打开，正常分享。所以有很多考虑。

@diferent 所言极是。