xwayway

@loryyang 确实是个瓶颈期，大厂进不去，在成都来说，小厂我这个收入大头兵快到头了，转管理岗，没机会

@xbtu 感谢中肯的建议，确实不是技术大牛。一直凭韧劲保持不掉队的节奏。但是目前这个样子，也到了一个瓶颈期了，技术不能更进一步，转管理岗，也没有机会，所以一直只能在成都的中小厂徘徊，连大厂的炉渣也当不了

想过这个问题，想有一个工具，在思维导图里面，能够做成图的结构。然后各个节点还能做超链，链接到文章，但是并没有这种工具。目前用飞书文档，按类别分类，然后每个分类下做个思维导图，再配合详细的文章来整理。

我……还以为能解决电梯内的问题，看来想多了

如果出现大量的同一个 api 被不同服务引用的话。还是建议做一个单独的服务，来专门处理外部 api 调用的问题，内部通过 rpc 调用

据我所知，九眼桥的老哥大多都因为山地车少了，转行偷电瓶车了。不排除看到合适的，可能还是会下手

遗憾的是管理者、乃至技术架构师都不能真正地接受演进式设计（ Evolutionary Design ），尤其不能接受一个具有良好设计的系统，应该是能够被报废的，潜意识中总会希望系统建设能够一步到位，至少是“少走几步能到位”。
摘自 [凤凰架构]

针对你说的这几点，做一个个人浅显的回答：
1. 转发，比如说你一个微服务架构，支持一个 app 需要用到好几十个系统，你不可能给 app 开发人员几十个域名吧，这不得被骂死。app 统一通过一个域名（流量入口），在网关层，进行请求的转发，然后再返回给 app 端，是不是就友好很多了；
2. 流量控制，不说灰度什么的，就说个蓝绿发布。你上线的时候，总不可能不做控制吧，刚起来的应用，立马就收到大量流量了，或者还在请求你已经 [杀死] 的服务，但注册中心还没下线的服务，这不得大量异常；
3. 鉴权，api 网关的鉴权指的是请求用户对请求资源时候有访问权限，而不是业务上的 key，sign 验证。鉴权统一放在网关做，到了业务系统的流量，都认为是有访问权限的，这样业务系统只关注业务。而且有什么升级改造，都可以在网关统一进行。
以上个人愚见，希望能有所帮助。