@innoink #41 docker 单机还是挺好的。 集群还是要上 k8s

@KingEngine #24 坐标西安。 不过我领导者奇葩还真是不常见。 虽然脾气有点暴躁，但是对大伙还挺好的，所以有时候也忍了。

DubboX 是当当搞的，主要是添加了 restapi 功能。 现在合并到 dubbo 主分支了。

主要看领导对技术有没有追求。 讲真，小公司单体服务的确够了。

我司非常小公司，自己造了很多轮子。比如配置中心、CD 系统、基于分片的定时器，自研的消息系统等等。
最近发现 k8s 大势已成，我们又开始搞什么服务编排。 妈的搞的好累。

技术领导太变态。天天不怕事大，疯狂让大家搞东西。我就不明白了，把业务完成就好了么，还他妈的非得搞新技术和一线厂商接轨，弄的非常累。。。

最后说到 java，我来公司 2 年，从 springmvc 升级到 springboot 说是搞什么微服务（然后就 mvn 快速生成模板、mvn bom 啥的、boot 的各种自定义的 Starter ），然后接入了 dubbo，然后又接入统一日志管理、链路调用，年初那段时间搞流量接入和 waf。最近搞 k8s。哎。 领导太变态，整个后端团队才 tmd 的 3 个人，又得搞业务，又得搞轮子。 搞的都想离职了。

加入我们有 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 刚好避免这个坑。 大佬你觉得呢？

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