前言
裁员增效潮滚滚而来，特总结一些实际场景方案的面试题，希望对大家找工作有一些帮助。
注册中心
题目： 有三台机器，分别部署了微服务A、微服务B、注册中心，其中A和B都有服务接口提供并正常注册到了注册中心，A和B之间有依赖调用，当前整个环境在正常运行，如果现在注册中心这台机器断电了，整个环境还是否可用，有哪些影响？
解析： 此题考察对注册中心原理的理解，这里不管注册中心是zookeep还是eureaka都是一样的。部分面试者会反问：注册中心一般会部署多台，不会都死掉的，面试官会强调场景中只有一台，并且部署多台也无法保证不会都出故障，只是概率问题。
首先要想清楚有没有影响，
- 微服务中的消费者是如何知道生产者的IP端口的呢？
是通过向注册中心问询得知； - 是什么阶段问的？
服务启动时 - 生产者增加或减少怎么知道？
zk是推给消费者更新生产者列表
eureaka是消费者定时查询生产者列表并更新
答案： 整个环境可用，但如果A或B需要重启，就无法正常运行了。
消息中间件
题目： 有三台机器，分别部署了微服务A、微服务B、消息中间件（比如RockeMQ），现在定义了一条点对点的消息，其中A是生产者、B是消费者，已知A成功生产一条消息，问B有没有可能收到两条消息？
解析： 消息中间件有什么作用，什么场景适合使用这些我向大家在各种面试宝典中已背的滚瓜烂熟，初级程序员还可以蒙混过关，但高级程序员是要独立负责一个子系统的定位，要有一定的技术把控力，你可以不懂具体实现，但你要知道这里有坑。
答案： 有可能，您问为什么有可能，请官方文档说明：
什么叫至少，什么是大多数就不用我多解释了吧。有同学会问那其他的消息中间件呢，其实都是一样的产品规格，这是通用规格，并非RocketMQ一家缩水。
解决方案
题目： 公司有个一个官网，是N年前开发的，伴随者客户访问量的增长，运行缓慢，请给出一个优化方案？
解析： 这个案例在公司中发生的概率很高，是考你解决问题的整体思路是否有，或者说有没有方法论，回答的不同能反映出你不同的经历，知识结构等等。
答案： 一个老法师的回答：
- 看病先诊脉，公司是否有链路追踪等监控系统，如果没有建议接入sky-walking看最大的病因在哪里。
- 根据我几年积累的经验有以下几种优化的策略：
动静分离： 动态服务器（比如Tomcat\Jboss）处理静态资源的效率很低，可以分离使用Nginx部署静态资源。
分级缓存： 本地缓存+Redis缓存 当然通常用Redis就够了
消峰解耦： 结合具体业务可以利用消息中间件进行消峰解耦。
题目： 现在我们公司要提供一个服务接口给第三方调用，如何保障通信安全？
解析： 这个问题是旨在考察面试者的知识储备，是否在工作中对加解密问题进行过自己的理解和思考或是学习。
答案：首先通信协议约定为https，设置网络白名单，当然以上是防君子难防小人，要想安全还要采用非对称方式进行签名，保证通讯的安全性。
题目： 我司现有一个手机充值业务，业务模式如下： 商户预充值到我司电子账户，我司提供手机充值接口，比如入参商户号、手机号、充值金额、签名，出参： 是否成功。收到充值请求后，处理流程如下：
- 检查商户是否在黑明单
- 检查商户的账户状态是否冻结
- 检查商户的电子账户余额是否充足
- 加锁
- 电子账户余额扣减
- 调用第三方接口对手机号充值
- 释放锁
大部分商户都运转正常，但其中一个大商户，部署终端比较多，反馈经常卡顿，请分析可能是什么原因导致，如何进行优化提升性能？
解析： 这个一个比较开放的题目，旨在考察面试者的实际应用经验，面对一个具体业务场景，能否找到关键问题，并给出一些行之有效的解决方案
答案：
- 产生的原因
大概率是加锁导致的， 大部分商户没有产生问题是因为他们的并发量小，锁冲突的概率小，而大商户的业务量大，这个锁就成了业务瓶颈。 - 优化可以考虑以下几个方面
大商户都是我们的重要客户，一般都具有良好的资质，既然有黑名单，是不是可以有白名单或大客户名单，对白名单客户，1-3的检查项进行简化。
大商户的电子账户可以设计成多个，可以把资金分散到多个子账户上，这个余额扣减就可以分散了，等同小商户。
加锁的范围有点大了，还包含调用第三方充值接口，其实没有必要，这部分可以放到锁的外部。
结束语
2023年刚刚过去，伴随着经济周期的变化，国际关系的动荡，越来越多的公司认清了现实，保留子弹，活下去才是硬道理。朋友圈子不断传来公司裁员的消息，但却少有招人的公司，市场供需严重失调，本人也经历年终奖推迟、下调，虽万般腹诽，面对市场大势力却是无能为力，唯天行健，君子当自强不息，与君共勉。
