大家好，我是二哥呀。
虽然已经是秋招下半场，但其实还有蛮多公司在发招聘公告，并且有些还是刚刚启动的 26 届校招。
所以还没有 offer 的同学一定不要气馁，你需要做的，可能只是比竞争对手多一点耐心，多一些渠道。
眼里不要只盯着互联网一线大厂，还有很多独角兽、中小公司，都值得去看一看。
就比如说稚晖君的智元机器人，可以划到【制造业、汽车、电子、电器、机械】这一类，就足足有 2000 多家。
对于智元机器人，可能大家的第一印象是，只招 CPP、Python 方向，但我帮大家检测过了，Java 也是可以投的。
JD 的要求也无非是大家耳熟能详的技术栈，比如说 Spring Boot、Spring Cloud、MySQL、Redis、Kafka、Docker 这些。
并且薪资也能开到 30-50k。
对于年后打算换公司的同学来说，确实可以趁年前这段时间去挖掘一下，找一找自己心仪的公司和岗位，看看人家的 JD 要求什么，及时更新一波自己的简历。
就我修改过的一些工作党的简历来说，有些写的蛮糟糕的，就比如说下面这份，提到了 Spring Cloud，但在核心职责中是完全没有表现出来的。
就好像在记流水账一样，还是蜻蜓点水的那种。
这种简历在求职的时候肯定是会碰壁的，因为太划了呀。
换句话说，如果你写了 Spring Cloud，你就应该也提到 Nacos、Gateway、Sentinel、Seata、Skywalking、OpenFeign 等等这些，并且分别用它们实现了什么业务，解决了什么问题，有哪些量化数据，统统都要展示出来。
就像 PmHub 项目中，我给大家列举的这些，这才是一个工作党应该具备的品质。
你不能工作了三五年，仍然停留在一个很没有技术含金量的阶段。
甚至不如校招阶段。
之前有同学在评论区强调技术无用论，说什么业务能力、是不是嫡系比技术重要多了。
但我想说的是，这位同学可能忽略了一点，就是那些爬上去的人、晋升的人、成为嫡系的人，人家本身技术能力也很强，只是你认为不强而已。
对于绝大多数的同学来说，可能一辈子都说不出几句漂亮话，像我一样。😄
与其在别的方面花心思，还收效甚微，真不如踏踏实实钻研一下技术。
接下来，分享一些 PmHub 的经典面试题，有想冲微服务开发经验的同学，都可以参考。
1、网关向服务传递用户信息，用的是HTTP请求头，不是TTL。网关和 pmhub-project 是两个独立的进程，他们之间通过 HTTP 协议通信，用户信息放在请求头里，由 FeignRequestInterceptor 拦截传递。
TTL解决的是同一个进程内部，跨线程的上下文传递问题。TTL 这个我们写了教程，按照教程和面试官交代清楚就可以了。
回答思路：在PmHub中，我们是通过自定义 FeignRequestInterceptor 来实现的。当用户请求到达网关后，网关会解析Token，然后将用户信息（如用户ID、用户名）放入请求头。当服务A通过Feign调用服务B时，这个拦截器会自动将这些请求头信息附加到新的请求上，从而实现了整个调用链的用户身份透传。
在服务内部跨线程的传递场景中，比如使用 @Async 注解或者手动向线程池提交任务。标准的 ThreadLocal 在这种情况下是无法传递父线程的上下文的。 比如‘创建一个项目后，需要异步发送邮件通知、记录操作日志、并更新统计数据’，我们就会引入阿里巴巴的 TransmittableThreadLocal （TTL）。它的原理是通过 TtlRunnable 和 TtlCallable 来包装我们的异步任务，或者直接使用 TtlExecutors 来修饰原有的线程池。
这样，在任务提交时，TTL会把父线程的 ThreadLocal 内容‘备份’下来，在子线程执行任务前再‘恢复’回去，从而巧妙地解决线程池导致的用户信息丢失问题，保证即使在异步场景下，我们的日志归属、数据权限等依然能够正确处理。
2、面试回答： “Gateway与Spring Boot Admin的联动，依赖的是Spring Boot生态标准的 Actuator + Micrometer 机制，并不是一个特殊的私有协议。 具体来说，Gateway作为一个Spring Boot应用，它内置的Micrometer会自动对所有经过网关的请求进行AOP拦截和计时。
当一个请求处理完毕后，Micrometer就会记录下这次请求的总耗时 ，并连同请求的URI、状态码等信息，一同保存在内存中。 Spring Boot Admin服务端则会定期地（通过HTTP协议）访问Gateway暴露的 /actuator/metrics 端点，把这些原始的指标数据‘拉’走。SBA拿到数据后，会自己在后台进行聚合计算，最终在监控界面上以图表的形式，为我们展示出每个接口的QPS、平均耗时、最大耗时等关键性能指标。”
3、你可以这样回答： SkyWalking的告警集成，我们遵循了‘ 配置即代码 ’和‘ 责任分离 ’的原则。
教程里有这样一段话：由于Skywalking采用字节码增强技术，因此对于微服务无代码侵入，只要是普通的微服务即可，不需要引入什么依赖。 换句话说，我们的所有微服务（包括Gateway）在启动时，会通过JVM的 -javaagent 参数挂载SkyWalking的探针（Agent）。
这个探针会无侵入地、自动地为我们的应用生成调用链数据，并将其上报给SkyWalking的OAP后台服务器。应用的职责到此为止。 所有的告警逻辑都在OAP服务端进行配置。
比如，我们定义了一条规则，当‘某个接口的P95响应时间连续3分钟超过1秒’，或者‘服务的实例突然全部下线’时，就触发告警。 在同一个文件里，我们配置了 webhooks 。这里我们会填入一个钉钉群机器人的Webhook地址。 我们将之前定义的告警规则与这个钉钉Webhook进行关联。 这样，当OAP服务器分析收到的链路数据，发现满足了我们定义的告警规则时，它就会自动按照预设的模板，将告警信息格式化，并通过HTTP POST请求发送到钉钉机器人的Webhook地址。
然后，我们的开发团队就能在钉钉群里实时收到告警通知了。 这样做最大的好处是，告警策略的调整（比如修改阈值、增加新的告警规则、更换告警渠道）完全不需要修改任何业务代码，也无需重新部署服务，运维人员可以直接在监控后台完成，实现了监控体系和业务体系的彻底解耦。
ending
一个人可以走得很快，但一群人才能走得更远。二哥的编程星球已经有 10600 多名球友加入了（马上涨价），如果你也需要一个优质的学习环境，戳链接 🔗 加入我们吧。这是一个 简历精修 + 编程项目实战（RAG 派聪明 Java 版/Go 版本、技术派、微服务 PmHub）+ Java 面试指南的私密圈子，你可以阅读星球专栏、向二哥提问、帮你制定学习计划、和球友一起打卡成长。
最后，把二哥的座右铭送给大家：没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。共勉 💪。
回复