一天隔壁組的小王灰頭土臉的跑過來，問我說：「李哥，你會設計微服務閘道器系統嗎？」。我一愣，小王怎麼突然問這麼抽象的問題，關鍵是我們最近也沒有這樣的需求。吃午飯的時候，在我旁敲側擊的追問下，小王招供了，原來小王偷偷跑去阿里面試了。技術一面挺順利的，結果在技術二面的時候卡住了，面試官問了小王關於閘道器的問題。對話大致如下：
面試官：「你們的微服務有統一的閘道器嗎？」。
小王：「有呀，我們使用了 spring cloud zuul 作為閘道器。」。
面試官：「那你知道它的具體實現原理嗎？」。
小王：「額，了解一些。它內部其實是乙個 servlet 攔截了所有請求，然後**客戶端請求，最後將結果返回給客戶端。」
面試官：「好的，那你知道它具體的架構設計嗎？」。
小王：「額，這個沒有詳細了解過。」。
......
省略一些無關緊要的話題
......
面試官：「今天的面試就到此結束，有後續的結果的話我們會**通知你，感謝你參加今天的面試。」
其實這已經成為一種常態，工作三到五年的程式設計師面試的時候除了紮實的基本功之外，系統設計題目是在所難免的。我想這可能是大多數程式設計師需要了解的知識點，所以專門寫了一篇關於微服務架構的閘道器的文章來和大家一起聊聊微服務閘道器設計這個話題。文章簡介如下：
隨著網際網路技術的發展，微服務架構已經成為每個網際網路公司的標配。伴隨著服務粒度的細化，服務應用數量極速**。如何暴露服務來對外統一口徑，如何做流量控制來保護服務，如何對所有請求進行安全校驗是我們不得不考慮的乙個重要問題。在單體應用時代，我們通常會寫乙個***來完成這件事情，它會截獲所有外部請求去校驗請求的合法性，日誌記錄，流量控制等操作。但是在微服務時代，由於服務眾多，我們不可能單獨為每個服務做這樣的事情，這既是設計的不合理同時會造成大量的重複工作。因此，我想和大家一起聊聊在微服務架構中如何完成這件事，如何搭建我們的微服務閘道器。
閘道器的應用場景和功能
zuul 閘道器的架構分析
zuul 閘道器實戰
zuul 對接配置中心
zull 閘道器生產實踐
spring cloud zuul 簡介
zuul2.0 vs zuul1.0
佇列演算法題 如何設計乙個排序系統
設計乙個排隊序列，能夠讓每個進入隊伍的使用者看到自己在佇列中所處的位置和變化，隊伍中隨時有人加入和退出 當有人退出影響到使用者排名時，需要及時的反饋。解析 既然是排隊序列，那麼加入只能排在隊尾。所以，他不會影響到原先所有人的排序。但是，有人退出時需要注意，隊頭的人和隊中間的人退出才會影響使用者排名，...
乙個資料結構面書題
閱讀下面的 它的輸出結果是什麼？class node object def init self,sname self.lchildren self.sname sname def repr self return format self.sname def print all 1 self prin...
如何設計乙個秒殺系統
秒殺場景一般會在電商 舉行一些活動或者節假日在12306 上搶票時遇到。對於電商 中一些稀缺或者 商品，電商 一般會在約定時間點對其進行限量銷售，因為這些商品的特殊性，會吸引大量使用者前來搶購，並且會在約定的時間點同時在秒殺頁面進行搶購。限流 鑑於只有少部分使用者能夠秒殺成功，所以要限制大部分流量，...