@xwayway 另外你还需要有一个足够刚的技术领导，把业务方不合理的需求都怼回去。一个功能最开始做的目标就是能实现目的就行了，不要想做得多复杂，多人性化，后期再慢慢加，不然一开始就做得大而全，很多东西根本用不上，徒增代码复杂性。

流程不规范的话，每个公司都一样。另外项目最一开始就写好单元测试，重构的时候你就知道单元测试有多重要了

说句不太专业的话，没太搞明白家庭里面搞 UPS 以及服务器的意图。

八股文学一遍，jvm 、多线程、spring 、spring boot 、spring cloud （可以发散到整个微服务，服务怎么发现、服务之间怎么调用、服务调用过后，怎么追踪调用链路，包括一些负载均衡、降级、熔断等）、redis 、mysql 、消息中间件（ kafka 、rocketmq 之列的），然后还可以了解下分布式相关的，分布式锁、分布式事务、缓存一致性等，再然后可以了解下 devops 之流的，ci/cd，感兴趣可以了解下云原生，这里面就可以学习 docker 、k8s 、istio 这些。在整个过程中想要深入学习一些东西的话，势必会接触到操作系统原理、计算机网络这些知识。另外想要让自己的代码写得漂亮的话，可以学习些设计模式、DDD （ DDD 不建议完全按照这类思想来落地，主要还是用到服务和类的职责划分）、事件驱动之类的。以上为鄙人愚见，若有不端还望海涵。

我目的很明确，买 ipad 就是为了爱奇艺，所以买的 air4

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

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

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

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

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

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

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

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

我们 commit message 有需求的一般需要贴上 jira 链接，然后大致写下实现了什么。如果是修改 bug，要说下改动点，影响范围什么的

@wizzer #2 不赞同 2 楼的说法，这样最终换来的是一地鸡毛。虽然强扭了瓜，但是再 NB 的“爱情”，也抵不过柴米油盐。

四川人，自己手工做面食基本和我无缘，蒸个馒头都能把狗打死的那种水平

@NibborQ 开车或者公交。公交 131 或者 838