感谢提醒，想起当时 6.3 屯了一点，所以赶紧续了三年。

我们刚好有这个功能：
1. 提供一个服务端来下发未使用的 workerId ；
2. 客户端获取到 workerId 后定期上报心跳到服务端；
3. 服务端维护 workerId 的心跳信息（并针对异常心跳做断言，提前发现问题），一段时间内没心跳后标记为未使用；

当然还有一些细节：
1. 要考虑某个 Pod 反复重启的情况；
2. 引入命名空间的概念，针对数据不会交叉的场景隔离命名空间，不然 workerId 根本不够用；
3. 我们在 MySQL 还实现了一条有意思的 SQL：通过无锁的方式获取未被使用的 workerId ，返回范围在[0-MAX]，不用做取模等；

其实一直都是这样子的吧，只是大部分路口都精简化过的。不过我倒是遇到过那种超级复杂的路口，稍不注意就会懵，都不知道要看哪组红绿灯。

刚好做过类似的事情，我们通过 Checkstyle 来实现格式检查，但如果格式不正确怎么快速格式化呢？因为我们这边基本用的 IDEA 社区版，经过调研最终我用的 editorconfig 配置文件来实现，下面细说：
1 ）将统一的 IDEA 风格导出到 editorconfig 配置里面去（不要怀疑，可以这样玩的，是以 "ij_java" 开头的配置）；
2 ）然后想办法写入到大家的项目目录下，当打开项目时 IDEA 会优先使用当前项目 editorconfig 里面的配置，IDEA 下面也会提示 "one or more code style options are overriden by By EditorConfig"，这样就生效了；
3 ）那怎么让这个配置文件写入到大家的项目目录下呢，我们开发了一个 IDEA 插件，只要大家安装了，启动项目时一旦检测到公司的项目就自动写入配置文件或者更新配置文件；
综上，需要用到两款插件（ Checkstyle + 自研）、editorconfig 就可以实现了，如果喜欢折腾的话就在自研插件里面集成 Checkstyle 代码，代码是开源的。

@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

感谢，原来如此