16.微服务基础设施

  1. 1.问个关于1.14之前的基于主动让出的调度和1.14的抢占式调度的一个疑问:1.14 之前的主动让出的调度为什么就使得STW的时间变长、为什么会延长栈扫描时间呢(https://go.goeemption.md)
  2. 2.注册中心的场景下是不是更适合AP,毕竟保证注册中心整体可用是更紧要的,拿到部分过时数据并不会造成很大影响。
  3. 3.曹大说一下在阿里Go的技术部门(mosn之类的),面试的时候问什么吧,不想写业务了,面试P6需要几轮技术面,算法写的多么,每一面的关注点是什么
  4. 4.Go语言为什么不适合特别高IO(几wqps)的服务呢,那什么语言适合?
  5. 5.在并发量比较大的场景下可以直接去查询es吗?比如将用户产生的行为记录保存到es中,查询的时候也从es查
  6. 6.生产环境中,es mysql这种建议部署在k8s中么?之前网上看到这种有状态服务放容器中有一些问题。有点迷..
  7. 7.有个需求要做大概 50-60 万个 html SEO 静态页面,是否可以考虑用 ES 或 mongo 来存,然后直接返回?(总共大概在 200w 个页面左右)
  8. 8.es查询数据的时候有什么缺点吗(被面过)
  9. 9.微服务中的各个组件是不是都需要部署成集群,避免单点故障阿,比如consul做的服务发现,nacos做的配置中心等等
  10. 10.我们的服务最前面是nginx做的网关入口,这个nginx也是需要做成集群吗,否则也有单点故障吧,那么nginx前面还得在需要个4层负载均衡吧,否则不知道流量转到哪个nginx
  11. 11.下游的业务处理方一般如何做幂等,比如去重,补偿之类的
  12. 12.分布式任务调度平台/系统里,如果运行多个实例,如何保证同一周期内任务不重复执行多次呢?比如这样的场景:检查指定的数据,根据特定条件发送通知。

1.问个关于1.14之前的基于主动让出的调度和1.14的抢占式调度的一个疑问:1.14 之前的主动让出的调度为什么就使得STW的时间变长、为什么会延长栈扫描时间呢(https://go.goeemption.md)

图片

  • stw 需要等待所有 goroutine 停下来,这个看我 gopherchina 那个分享的 ppt,等待期间是 stw 的,如果这时候有用户的 goroutine 在执行一个需要时间比较长的循环,stw 就会被拉长,如果是死循环,那 stw 的时间就是无限长

2.注册中心的场景下是不是更适合AP,毕竟保证注册中心整体可用是更紧要的,拿到部分过时数据并不会造成很大影响。

  • 是的,AP 更合适
  • client 端要有故障实例摘除功能,否则会有比较大的业务影响

3.曹大说一下在阿里Go的技术部门(mosn之类的),面试的时候问什么吧,不想写业务了,面试P6需要几轮技术面,算法写的多么,每一面的关注点是什么

  • 面试,网络知识,nginx 的概念,基础,网络编程模型(grpc,thrift server,怎么编解码,怎么处理请求,goroutine-per-conn,还是 2g per conn),操作系统,graceful 重启(那我原来进程的连接、buffer、文件 fd 这些要怎么处理)
  • 领域知识
    • registry,业界的 registry 的技术上的关键点,每一个都是怎么实现j
    • mq,肯定会考常见 mq 设计、架构

4.Go语言为什么不适合特别高IO(几wqps)的服务呢,那什么语言适合?

  • 几 w qps 的时候,gc,runtime 对系统整体的影响会很大
  • gc + schedule,占了系统的 CPU 40%+,延迟会很高

5.在并发量比较大的场景下可以直接去查询es吗?比如将用户产生的行为记录保存到es中,查询的时候也从es查

  • 不适合,根据场景分析
  • traceid –> log
  • 直接用缓存优化

6.生产环境中,es mysql这种建议部署在k8s中么?之前网上看到这种有状态服务放容器中有一些问题。有点迷..

  • 我现在待过的公司,核心存储暂时还没有容器化
  • 国内的大公司如果存储容器化了,肯定会出来宣传的(我看到京东有一个)

7.有个需求要做大概 50-60 万个 html SEO 静态页面,是否可以考虑用 ES 或 mongo 来存,然后直接返回?(总共大概在 200w 个页面左右)

  • es 不适合做主存储
  • 如果是检索需求的话,es 是可以的,200w 这个量不大的

8.es查询数据的时候有什么缺点吗(被面过)

  • es 扛并发查询的能力一般,比 mysql 肯定是差远了,相比 mysql 主要的优点是任意组合查询稍微好一些(这种场景下 mysql 没法建索引,比如我有 50 个字段,他们可以任意组合来查询),所以除了检索以外,它适合客服、运营之类的查询特别复杂的系统
  • 插入的数据需要等待 refresh_interval 才能查到,所以 es 无法当主存储使用
  • dsl 比较难写?这算缺点么,现在其实直接支持 jdbc 连接用 sql 来查了

9.微服务中的各个组件是不是都需要部署成集群,避免单点故障阿,比如consul做的服务发现,nacos做的配置中心等等

  • 是的,都是集群

10.我们的服务最前面是nginx做的网关入口,这个nginx也是需要做成集群吗,否则也有单点故障吧,那么nginx前面还得在需要个4层负载均衡吧,否则不知道流量转到哪个nginx

  • 要么有个 LB
  • 要么客户端负载均衡~
  • 要么就 dns

11.下游的业务处理方一般如何做幂等,比如去重,补偿之类的

  • 下游自己可以加个锁(可能是简单的 redis setnx 之类的,如果是”粗粒度”的任务,比如一小时跑一次那种,用 etcd 之类的 lock 也可以(如果怕任务执行期间 crash 的话,还需要自己建个任务执行进度表,任务执行完把 done 写进去,后台线程定时扫描这些预期外的未执行任务,做补偿执行)
  • 如果是数据更新,下游要用 update xxx set yyy = 1 where 后面跟版本号之类的判断,不能用 set yyy = yyy+1 这种形式,前者可以做到多次执行结果一样,但后者就不行了
  • 严谨的业务需要用 flink 之类的流式计算框架~在 producer 消息不重复的情况下,流式计算框架的分布式快照可以保证系统内的 exactly once,下游 sink 侧用 2pc 来保证幂等,感 systems》这两本书,前面那本应该有翻译了

12.分布式任务调度平台/系统里,如果运行多个实例,如何保证同一周期内任务不重复执行多次呢?比如这样的场景:检查指定的数据,根据特定条件发送通知。

  • 看着是个去重需求吧?简单实现的话,用 redis 的 setnx 就可以了~粗粒度也可以 etcd lock
  • 怕执行期间 crash 的话,就需要自己搞个任务表,后台线程定时扫描未 ack/done 的任务这种方式来实现了

转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 lihuanjie113@gmail.com

×

喜欢就点赞,疼爱就打赏