- 主题:项目都是C++的，结果新来的架构师不懂C++
而且很明显，问题出在整个方案设计本身
让相关组件的同学负责出报告和优化方案，这说句不客气的话，就是所谓架构师无法下沉到产品，然后只好虚张声势，甩锅的行为
这话不是架构师应该说的，甚至优化方案本身就是架构师应该出的，因为这个问题恰恰就是架构设计注定的
我不知道这里的同学说，架构师只需要拼组件，这样脱离产品，是否经过现实的锤炼
至少在我经历的实际过程中，架构师对产品的内在实现的把握需要非常高，即使不是产品逻辑层的问题，甚至是操作系统kernel的问题，只要一旦在现场出了问题，架构师一定是最后被寄予厚望，来搞定问题的人
【 在 leaf918 的大作中提到: 】
: 这种问题统计下平均耗时，哪里占比大，原因是什么，写相关组件的同学负责出报告和优化方案，
: 一周内就可以搞定了，
--
FROM 123.168.95.*
我是回复leaf918的帖子
我举的例子，方案出了问题，确实是架构师应该负责的寻找方案问题，并提出改进方案的
我回帖的原因是，leaf918说，让相关组件同学出方案，一个周搞定，对此我不认可，所以回帖
架构师的职责，远远没有站在高处出个方案这么轻松，
还是那句话，如果仅仅是如此，找麦肯锡安永等对应的咨询部门来出个方案就好了，何必请个专职的架构师
【 在 oldwatch 的大作中提到: 】
: 我不知道“拼组件“是怎么导出”脱离产品“的
: 拼组件最终目的都是实现功能要求
:
: ...................
--
FROM 223.104.194.*
所以，出了问题，让相关组件的同学出方案，这种做法，和外部闪人的有本质区别没？
【 在 oldwatch 的大作中提到: 】
: 仔细想想，外部咨询和内部人员出方案核心区别在哪儿
: 无非就是外部人员出完ppt就闪身走人，内部人员得持续跟进
:
: ...................
--
FROM 223.104.194.*
那倒也不是
其实云原生的理念是对的，
应用程序只管自己逻辑，不需要操心流量路由，分发，负载均衡，统计数据报告等
但是实际上，这几年充满了各种或明或暗的坑坑洼洼，有的还很深，
产品发布了，所有出的问题，即使是基础组件的问题，都需要产品本身的人搞定，
架构师只会从high level指指画画，有问题了，让别人出计划出方案，这种架构师基本上只能在理论上存活，没法正常生存
【 在 hgoldfish 的大作中提到: 】
: 所以我一直说现在开源社区流行的各种技术都是公有云厂商的阴谋，故意让大家的项目都变得卡顿繁重，一台机器能搞定的问题变十台，好让公有云厂商多赚钱。
:
--
FROM 223.104.194.*
架构师跟产品强关联，这个没问题吧
如果架构师对产品的实现原理都不知道，他只能接受被开发人员牵着鼻子走的现实
【 在 zhangkung 的大作中提到: 】
: 架构师跟编程语言强关联么？
--
FROM 123.168.95.*
每个pod里面都有一个envoy，所以一路上会经过好几个envoy，
有时候某个组件又要截获消息做点别的事情（比如更复杂的服务发现、消息路由），为了对应用做到基本透明，不嵌入到应用逻辑内部，所以自身又会额外注入另外一个类envoy或者修改过的envoy，所以会出现一个pod里面有一前一后两个envoy...
【 在 lambdai 的大作中提到: 】
: 好奇除了envoy之外还有哪里用了nghttp2？ grpc用的是不知道哪儿来的chttp
: 另外类grpc的是强需求吧，基本是trace和log以外的最重要的组件了吧
--
FROM 123.168.95.*
都在用
基本上，envoy是云原生里面最不可回避最无可替代的组件
【 在 littleSram 的大作中提到: 】
: 阿里在用envoy吧
--
FROM 223.81.245.*
我并不算是互联网行业的
但这几年，因为产品向虚拟化，然后再往云原生转型，确实也经历了不少或深或浅的坑
比如，2019年，RHEL/CentOS 7.X kernel里面一个multiqueue的深坑，在虚拟环境下打开virtio-net的multiqueue，会造成发出去的包乱序的问题，就把产品以及我给狠狠的坑了一下
去年疑似被k8s环境下，CFS quota over throttling给坑了一把
今年早些时候又被openstack的NUMA问题给扰了一小段
其实我不愿意给自己扣一个架构的帽子，我也看不上不接地气只会PPT的架构，至于前面那种，以项目管理的方式作架构，出了问题，让工程师出方案的，就更匪夷所思了。
产品在现场出了问题，那时候，什么样的人能出的上力，这是很清楚的。这时候，需要从很底（操作系统，网络协议，计算机基本体系结构），到很顶（产品实现的原理甚至细节），都要有挺多的理解，或者去做挺多的调查，才能在各种纷繁复杂的线索中，找出可能的问题，当然，也需要运气。
无论如何，不接地气的架构，大概不是一个好架构，至少，对这个产品来说，不够好。
有人说，出了问题不应该是架构来搞；那可能是没经历过实战，那时候，老板手里能抓住什么稻草，就会抓住什么稻草，何况，产品出了严重问题，哪有人可以独善其身。
所以，产品出了问题，懵逼的架构，装死不吱声的架构，或者指望别人出方案搞定的架构，在我眼里，都不是好架构
【 在 littleSram 的大作中提到: 】
: 哈哈哈，你可以新开一个帖子了
: :
--
FROM 223.81.245.*
其实我倒觉得相反
k8s本身并没有离开linux内核提供的这些基础太多，比如namespace，cfs share, quota，ipvlan等基础，有时候出了问题，稍稍一挖，就会发现又穿透k8s，掉进了linux本身的问题里去了
甚至有时候我都觉得 k8s有点太简陋，或者某些关键设计理念本身有点不自洽，
最典型的，pod是k8s认为的最小的完整的功能体，但是k8s却把资源的限定放在了容器级别（因为沿用了docker对cfs的使用方式理念），所以，一个pod里面的不同容器之间，一个容器的富余资源配额，不能被同一pod的另一个容器挪用，所以，在流量类型有变化的情况下，预先设定好的静态的容器资源配额可能就不是最优的了，即使最近出来一个static cpu manager，也只是用来解决cfs over throttle问题的，不是解决pod内部动态资源配比问题的
【 在 littleSram 的大作中提到: 】
: 非常理解
: 关于云原生，我觉得是趋势，确实复杂，好多人都有类似的感觉，当对k8s了解的越多，越发现know nothing about k8s
: 关于架构师，我见到的都是写PPT向老板汇报的那种，基本不写代码，但是会画所谓的架构图，有具体的问题，不会参与。反正这些人都号称架构师。
: ...................
--
FROM 223.81.245.*
本质上，架构师是和产品强相关的，虽然不能要求架构师都能做更多的代码，fix更多的bug，毕竟人的精力有限，做了这个，就得放弃一些那个
但至少，架构师不能是浮在上空，对产品的原理却一点都不懂，最后只能靠询问，然后根据有限的二手信息做判断
可能很多人在有意无意的，混淆架构师的角色，项目管理类人员的角色，ScrumMaster的角色
【 在 bruce1988 的大作中提到: 】
: 我们公司有的架构师，一个人的代码量和bug fix率顶10个人，即便离开项目组好几年了，真正遇到疑难问题的时候，还得找他。他还能给你解决了。
: 还有的架构师连你的code在哪里都不知道。
: 每次向上汇报，需要先问engineer温习一下。要不然就忘了
: ...................
--
FROM 223.81.245.*