其實選擇作業的時候，很多技術牛人都會選擇一些小而美的公司，技術全面，能夠以一個更全面的視角看整個公司的運作，人和人之間的相處也很簡單，但是，有兩道微服務的面試題，小公司的朋友們會比較吃虧，
題一：你們上下游通信用的是什么協議？
題二：你們服務拆分成了幾個子服務？
為什么吃虧，咱們來分析一下，
題一：你們上下游通信用的是什么協議？
在一些小公司，可能直接用的是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系統怎么做出技術含量--怎樣引導面試》里，我說過其實面試官希望面試者來引導面試，將自己的特長能力充分展現出來，面試者如果可以洞悉面試官的心里，說明自己的格局是夠的，
最后臨場做了一首打油詩送給大家：
胸中有丘壑，
對答如有神，
驚艷面試官，
事業上青云，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/423740.html
標籤：其他
下一篇：梯度下降【無約束最優化問題】