加入我们有 3 个 node ，其中有 2 个 node 是可以使用 80 端口的 ，这时候我们发布 ingress-nginx Deployment 的时候， 可以添加 node 的 nodeSelector ，这样 deployment 就会被运行在指定的 label 的 node 上。

下面是命令

# 添加 node 的 label
kubectl label nodes <node-name> <label-key>=<label-value>
# 删除 只需在命令行最后指定 Label 的 key 名并与一个减号相连即可：
kubectl label nodes <node-name> <label-key>-
# 如果添加 label
修改一个 Label 的值，需要加上--overwrite 参数：
kubectl label nodes <node-name> <label-key>=<label-value> --overwrite

@abmin521 #11 我也是这么想的:-)

@SliceOnion #4 大佬，我觉得您这个方案有点绕了。

@artandlol #1
整个服务没法全部容器化，而且资源有限，如果真改不了，那就只能通过 node selector 来处理 80 端口了。 本来设想 k8s 前面有一个 ng 来做 waf。

docker 的本质是进程。除了主进程其他进程都是野孩子。所以你需要容器编排。k8s 的 pod 可以搞成多容器的，如果有启动顺序要求可以试试 statusfulset 这个玩意。

我回来好好几年了，楼主能自己搞还是挺牛逼的。加油。

环境挺好，顶一波

效率工程 主要做啥的？

火贴留名

如果我是你，我不会再去这位”大佬“进行 pk，没啥意义。因为自己已经认为老板信任大佬大于自己。这时候我们需要考虑更深层的问题。
1.大佬是否能把你干掉？ 他是否有干掉你的想法。
2.自己在团队，能留下的核心因素是啥？

老板一般希望有内斗，因为可以做事情的裁决，这样老板自己压力不会太大。
所以你的处境其实没那么糟。原因 1.跟了项目 3 年的老人，如果挤掉你团队其他成员怎么看？就算把你挤掉，这位”大佬“大概率会以同样的方式被干掉，所以你不亏。2.创业 3 年，其中的代码的坑，不是技术能力好，就能处理的，就算是大牛，改垃圾代码也是一件很操蛋的事情。 所以 你也可以根据老板的意愿主动把有些活给他负责，但注意的是交付给以后就不能在接手，除非他认怂。再此同时，尽可能的增加压力，烦躁+deadline 很容易把水货大牛给压爆。 如果没爆那还是跟着他，看看哪些是你的弱项，也是一个学习的过程。

这种情况，这位大佬聪明的话，不会太过分的和你闹，因为他现在需要证明自己和扎稳脚。

我对你的所在环境理解不多，所以这块，也是只是臆测，希望对你有帮助。

要说单调递增的 ID 生成，还数 TiDB 的 TSO 牛逼， 设计很轻巧，性能又不差，实现还简单。

@xuxueli #4 👍

一直关注这个项目， 最开始只是简单的 xml 配置，到现在采用 disconf 类似的 注解。挺赞的。

对于 todo 的
3、考虑移除 ZK，改为 "Server 端广播 + long-polling" 方式实现，降低学习、部署成本；

我不建议这么做，而是 基于当下的 javaClient 实现一个 agent 来实现配置转发，和请求的过程。即原有的 server 不变，对于异构语言（ PHP、go ）等，直接链接 agent， 可以通过 http 或者 ws 协议和 agent 数据交互，提供相应的接口和协议规范，可以依靠社区力量完善其他语言客户端，比 Server 端广播 + long-polling 靠谱很多。另外 zk 有着生产环境的验证，您做成能保证 Server 端广播比 zk 还稳定么？ 所以这个路线个人主观认为，在走岔路。

鉴于其他语言对于 zk client 实现，坑很多。所以 agent 使用 java 刚好避免这个坑。 大佬你觉得呢？

矿泉水都要经过调整，因为钙镁离子等需要达到一个合适的值。 矿泉水中的某些离子会感觉都苦涩，就口感而言好喝的水肯定是蒸馏水或者纯净水。

java 用 RandomAccessFile 读流的时候判断是\n 就行

JAVA 相关的
Queue
Stack
LinkedList
LinkedHashMap
HashMap
Guava 的 FutureTask （单向列表）
RocketMQ 的 index （单向列表）

@alamaya #40 如果面试官看到你并没有机会做过分布式，而且还得用线上的问题来刁难，那么请你直接投诉。如果非要求不行，这家肯定不是你的菜。