- 主题:项目都是C++的，结果新来的架构师不懂C++
架构师跟产品强关联，这个没问题吧
如果架构师对产品的实现原理都不知道，他只能接受被开发人员牵着鼻子走的现实
【 在 zhangkung 的大作中提到: 】
: 架构师跟编程语言强关联么？
--
FROM 123.168.95.*
好奇除了envoy之外还有哪里用了nghttp2？ grpc用的是不知道哪儿来的chttp
另外类grpc的是强需求吧，基本是trace和log以外的最重要的组件了吧
【 在 wallyz 的大作中提到: 】
: 举个例子，产品上云原生
: 组件间通信，赶时髦，用了grpc
: 为了用grpc，又造了一个gw，转换原来的消息，并打包成grpc，
: ...................
--
FROM 221.220.128.*
每个pod里面都有一个envoy，所以一路上会经过好几个envoy，
有时候某个组件又要截获消息做点别的事情（比如更复杂的服务发现、消息路由），为了对应用做到基本透明，不嵌入到应用逻辑内部，所以自身又会额外注入另外一个类envoy或者修改过的envoy，所以会出现一个pod里面有一前一后两个envoy...
【 在 lambdai 的大作中提到: 】
: 好奇除了envoy之外还有哪里用了nghttp2？ grpc用的是不知道哪儿来的chttp
: 另外类grpc的是强需求吧，基本是trace和log以外的最重要的组件了吧
--
FROM 123.168.95.*
阿里在用envoy吧
【 在 wallyz 的大作中提到: 】
: 每个pod里面都有一个envoy，所以一路上会经过好几个envoy，
: 有时候某个组件又要截获消息做点别的事情（比如更复杂的服务发现、消息路由），为了对应用做到基本透明，不嵌入到应用逻辑内部，所以自身又会额外注入另外一个类envoy或者修改过的envoy，所以会出现一个pod里面有一前一后两个envoy...
:
: ...................
--
FROM 114.242.248.*
这么多层, 怎么比istio还野...
【 在 wallyz 的大作中提到: 】
: 每个pod里面都有一个envoy，所以一路上会经过好几个envoy，
: 有时候某个组件又要截获消息做点别的事情（比如更复杂的服务发现、消息路由），为了对应用做到基本透明，不嵌入到应用逻辑内部，所以自身又会额外注入另外一个类envoy或者修改过的envoy，所以会出现一个pod里面有一前一后两个envoy...
:
: ...................
--
FROM 221.220.128.*
都在用
基本上，envoy是云原生里面最不可回避最无可替代的组件
【 在 littleSram 的大作中提到: 】
: 阿里在用envoy吧
--
FROM 223.81.245.*
哈哈哈，你可以新开一个帖子了
【 在 wallyz 的大作中提到: 】
: 都在用
: 基本上，envoy是云原生里面最不可回避最无可替代的组件
:
--
FROM 114.242.248.*
我并不算是互联网行业的
但这几年，因为产品向虚拟化，然后再往云原生转型，确实也经历了不少或深或浅的坑
比如，2019年，RHEL/CentOS 7.X kernel里面一个multiqueue的深坑，在虚拟环境下打开virtio-net的multiqueue，会造成发出去的包乱序的问题，就把产品以及我给狠狠的坑了一下
去年疑似被k8s环境下，CFS quota over throttling给坑了一把
今年早些时候又被openstack的NUMA问题给扰了一小段
其实我不愿意给自己扣一个架构的帽子，我也看不上不接地气只会PPT的架构，至于前面那种，以项目管理的方式作架构，出了问题，让工程师出方案的，就更匪夷所思了。
产品在现场出了问题，那时候，什么样的人能出的上力，这是很清楚的。这时候，需要从很底（操作系统，网络协议，计算机基本体系结构），到很顶（产品实现的原理甚至细节），都要有挺多的理解，或者去做挺多的调查，才能在各种纷繁复杂的线索中，找出可能的问题，当然，也需要运气。
无论如何，不接地气的架构，大概不是一个好架构，至少，对这个产品来说，不够好。
有人说，出了问题不应该是架构来搞；那可能是没经历过实战，那时候，老板手里能抓住什么稻草，就会抓住什么稻草，何况，产品出了严重问题，哪有人可以独善其身。
所以，产品出了问题，懵逼的架构，装死不吱声的架构，或者指望别人出方案搞定的架构，在我眼里，都不是好架构
【 在 littleSram 的大作中提到: 】
: 哈哈哈，你可以新开一个帖子了
: :
--
FROM 223.81.245.*
非常理解
关于云原生，我觉得是趋势，确实复杂，好多人都有类似的感觉，当对k8s了解的越多，越发现know nothing about k8s
关于架构师，我见到的都是写PPT向老板汇报的那种，基本不写代码，但是会画所谓的架构图，有具体的问题，不会参与。反正这些人都号称架构师。
反正不写代码的架构师我认为，一定会脱离一线，一定会成为你说得那种人。因为技术发展很快，很快知识就折旧了。能生存的只能是少数大牛。
【 在 wallyz 的大作中提到: 】
: 我并不算是互联网行业的
: 但这几年，因为产品向虚拟化，然后再往云原生转型，确实也经历了不少或深或浅的坑
: 比如，2019年，RHEL/CentOS 7.X kernel里面一个multiqueue的深坑，在虚拟环境下打开virtio-net的multiqueue，会造成发出去的包乱序的问题，就把产品以及我给狠狠的坑了一下
: ...................
--
FROM 114.242.248.*
我们公司有的架构师，一个人的代码量和bug fix率顶10个人，即便离开项目组好几年了，真正遇到疑难问题的时候，还得找他。他还能给你解决了。
还有的架构师连你的code在哪里都不知道。
每次向上汇报，需要先问engineer温习一下。要不然就忘了
- 来自 水木社区APP v3.4.2
【 在 wallyz 的大作中提到: 】
: 我并不算是互联网行业的
:
: 但这几年，因为产品向虚拟化，然后再往云原生转型，确实也经历了不少或深或浅的坑
:
: 比如，2019年，RHEL/CentOS 7.X kernel里面一个multiqueue的深坑，在虚拟环境下打开virtio-net的multiqueue，会造成发出去的包乱序的问题，就把产品以及我给狠狠的坑了一下
:
: 去年疑似被k8s环境下，CFS quota over throttling给坑了一把
:
: 今年早些时候又被openstack的NUMA问题给扰了一小段
:
: 其实我不愿意给自己扣一个架构的帽子，我也看不上不接地气只会PPT的架构，至于前面那种，以项目管理的方式作架构，出了问题，让工程师出方案的，就更匪夷所思了。
:
: 产品在现场出了问题，那时候，什么样的人能出的上力，这是很清楚的。这时候，需要从很底（操作系统，网络协议，计算机基本体系结构），到很顶（产品实现的原理甚至细节），都要有挺多的理解，或者去做挺多的调查，才能在各种纷繁复杂的线索中，找出可能的问题，当然，也需要运气。
:
: 无论如何，不接地气的架构，大概不是一个好架构，至少，对这个产品来说，不够好。
:
: 有人说，出了问题不应该是架构来搞；那可能是没经历过实战，那时候，老板手里能抓住什么稻草，就会抓住什么稻草，何况，产品出了严重问题，哪有人可以独善其身。
: 所以，产品出了问题，懵逼的架构，装死不吱声的架构，或者指望别人出方案搞定的架构，在我眼里，都不是好架构
--
FROM 116.88.151.*