小公司比較吃虧的兩道微服務面試題
其實選擇工作的時候，很多技術牛人都會選擇一些小而美的公司，技術全面，能夠以一個更全面的視角看整個公司的運作，人和人之間的相處也很簡單。但是，有兩道微服務的面試題，小公司的朋友們會比較吃虧。
題一：你們上下游通訊用的是什麼協議？
題二：你們服務拆分成了幾個子服務？
為什麼吃虧，咱們來分析一下。
題一：你們上下游通訊用的是什麼協議？
在一些小公司，可能直接用的是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系統怎麼做出技術含量–怎樣引導面試》里，我說過其實面試官希望面試者來引導面試，將自己的特長能力充分展現出來。面試者如果可以洞悉面試官的心裡，說明自己的格局是夠的。
最後臨場做了一首打油詩送給大家：
胸中有丘壑，
對答如有神。
驚艷面試官，
事業上青雲。
