小公司比较吃亏的两道微服务面试题

小公司比较吃亏的两道微服务面试题,第1张

公司比较吃亏的两道微服务面试

其实选择工作的时候,很多技术牛人都会选择一些小而美的公司,技术全面,能够以一个更全面的视角看整个公司的运作,人和人之间的相处也很简单。但是,有两道微服务的面试题,小公司的朋友们会比较吃亏。

题一:你们上下游通信用的是什么协议?

题二:你们服务拆分成了几个子服务?

为什么吃亏,咱们来分析一下。

题一:你们上下游通信用的是什么协议?

在一些小公司,可能直接用的是http协议。如果直接这样回答面试官。面试官下一个问题就有点难度了:“为什么用HTTP协议呢?”

这时候心里那个苦啊:“我也想用dubbo这样的RPC框架啊。但是公司非要用http,我自己又做不了主。但我总不能这么说吧”

最好的回答是真实的回答,但是要回答到本质。首先从面试官问题的本质出发,面试官实际的考察点是:服务通信方式RPC与REST的区别与怎么选取。

要是我,我这么回答:我们公司的基础设施还不是很完善,没有类似Dubbo这样的服务治理工具。所以我们还是使用基于http协议的REST调用。如果将来我们公司有了类似Dubbo这样的服务治理工具,并且足够稳定。内部之间的调用还是用RPC调用更为合适。

因为RPC与REST相比较,主要的区别如下:

对于公司内部的使用,理想的情况是有标准的服务化能力和高性能,更适合RPC。

题二:你们服务拆分成了几个子服务?

在一些小公司,可能一个项目就是一个微信小程序,用户量几万的样子。这时候前后端分离,后端一个单体应用就足够。如果直接这样回答面试官。面试官会怀疑你对微服务完全没有经验。

这时候,首先还是要事实就是。做人诚信是根本。那要怎么回答呢?要是我,我这么回答。

目前综合项目本身的复杂度、业务量、成本和沟通上考量,目前我们项目采用的单体架构。将来,我们业务量上来,也可能会按领域拆分,毕竟架构不是设计出来的,而是演进而来的。

虽然我自身所做的项目简单,但是如果不局限我自身做的,我对整体也有一定了解,我就说说我了解的内容吧。

根据康威定律,公司的组织架构设计等价于组织间的沟通结构,也极大的反应了公司的系统架构。我在一个小公司,所有人员加起来就是个2个披萨(国外的大,一个披萨大概够6个人吃)的团队,开发测试运营都在一起。做的事情白话一点说就是个公众号小程序。

我们的项目想要工作,借助了微信开放平台,同时我们的服务器是放阿里云上的。如果把微信开放平台和阿里云纳入到架构中,是下面的样子(这时候如果是现场面试,我建议拿起白板笔边画边说):

图画的比较粗糙,意思到了就可以了。反正我没有在面试中卡过谁画画水平不行。其实面试者在图中维护的只是核心服务部分。熔断、限流和降级都是在核心服务内部使用hystrix或者直接使用spring cloud来完成的。服务注册发现如题一所说因为是使用http协议,实际上是例如nginx之类的负载均衡器来完成。图中也涉及OAuth2,这是微服务安全的主流实现方式。

上面这张就把面试官的注意引入了Spring Cloud等一个个具体的技术问题,和自己所在的平台关系不大了。

总结

在《CURD系统怎么做出技术含量--怎样引导面试》里,我说过其实面试官希望面试者来引导面试,将自己的特长能力充分展现出来。面试者如果可以洞悉面试官的心里,说明自己的格局是够的。

最后临场做了一首打油诗送给大家:

胸中有丘壑,

对答如有神。

惊艳面试官,

事业上青云。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5722346.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-18
下一篇 2022-12-18

发表评论

登录后才能评论

评论列表(0条)

保存