- 主题:各位大神就这个架构的话招个人搭架构需要什么要求
如果是创业项目，自己又搞不清楚这摊事儿，你要的是先找个靠谱的技术合伙人，这种时候最重要的是人，不是具体什么技术架构。再什么架构都要演进，否则都得被淘汰。
如果是一锤子买卖，也不指望长久做，找个外包公司聊聊，也不用管团队配置了，反正做完就扔的，让外包给你对付一个就行，那就更别在乎什么技术架构了。
看楼主的状态，似乎是找不准自己的定位，要做一个自己不熟悉的领域，慎之慎之......
【 在 xiaolun (杭杭一生健康快乐) 的大作中提到: 】
: 所以要怎么配置团队呢？各个工种要什么级别的
--
FROM 111.199.220.*
那这货就应该提供基座，投标公司在基座上开发，你可以找人聊聊，说不定等着你报价呢...
【 在 xiaolun (杭杭一生健康快乐) 的大作中提到: 】
: 这是某大型国企架构师的图，要求投标公司按照这个架构设计才可以
--
FROM 111.199.220.*
这里所谓"使用zk管理"能支持哪些特性呢，如果是某些特殊场景，那比k8s默认的scheduler快并不奇怪。
但是k8s scheduler本身是可以调优的，另外如果你的场景特殊也可以自己实现scheduler，应该不会比zk差，毕竟从性能上来说etcd比zk高
【 在 lushan5436 (密如) 的大作中提到: 】
: 高可用，感觉还真不如zk，至少我发现k8s明显在服务宕机后到开始重启时间远大于使用zk管理。
--
FROM 221.220.225.*
就这个单一场景来说，你的描述有些模糊的地方需要澄清：
1、服务因何“主动”，是指计划内的重启，还是意外崩溃？如果指前者，k8s的流程是，通过先在pod上修改状态，然后才会向下影响到容器，如果你所谓立即生效仅指作为一致性存储的zk/etcd感知到这个事情，那么都是立即生效。
2、如果所谓生效是指负载均衡器感知到，那么依赖于具体的负载均衡器策略，这恐怕不能算做zk或者etcd的差别，或者说类似的策略下，效果是几乎一样的。
3、如果是指重新调度，同样的，取决于你的调度器策略，zk本身恐怕没有调度能力，etcd也一样。k8s默认的调度器确实是基于轮询的，但更多是因为它要照顾到通用场景，而且可以通过调优来平衡调度的延迟和公平。也许你基于zk实现的调度方案对延迟更加重视，那么在k8s中你完全可以通过自定义调度器来实现类似的效果。
【 在 lushan5436 (密如) 的大作中提到: 】
: 你确信么？，我不清楚，k8s管理的是pod，不是服务本身，zk管理的是服务本身，如果服务主动退出，zk是立即生效。服务退出，pod退出，etcd监控到，怎么也谈不上快。而且etcd监控不知道是不是轮询，如果是更慢
--
FROM 221.220.225.*