网关系统架构
目錄
?
一 API網關業務域?
1 ?業務域?
2 ?統一接入?
3 ?安全防護?
4 ?流量管控?
5 ?協議轉換?
6 ?其他業務?
1) ? 接口文檔管理?
2) ? 調試工具和示例?
3) ? SDK自動生成能力?
4) ? API增強?
二 API網關核心指標?
1 ?模型?
2 ?安全性?
3 ?高并發性?
4 ?高可用性?
5 ?擴展性?
6 ?運維成本?
?三 API網關架構?
1 ?幾個要點?
2 ?網關整體模塊?
3 ?系統領域劃分?
4 ?系統分層模型?
5 ?防護層?
??6 ?接入層?
1) ? 接入規范?
2) ? 接入?
3) ? 文檔?
7 ?核心層?
1) ? 驗證層?
2) ? 增強層?
3) ? 協議轉換?
8 ? ? ? ?高并發、高可用?
四 安全?
1 ?核心要素?
2 ?安全策略?
1) ? 安全策略?
2) ? 通用安全策略?
3) ? 設備級安全?
4) ? 應用級安全?
5) ? 接口級安全?
6) ? 用戶級別安全?
3 ?企業級設備安全解決方案?
1) ? 設備注冊?
2) ? 用戶登錄?
3) ? HTTP請求處理
一 API網關業務域?
API網關作為內外的橋梁；對外通過暴露HTTP接口提供服務；對內管理所有業務系統對外暴露的接口，并將請求分發到內部各個業務系統。
1 ?業務域?
2 ?統一接入?
作為對外的門面，網關應該擁有統一且簡潔的規范，以減少接入的成本。同時這也可以體現出專業化的技術能力。
統一的規范應該至少包括以下內容：
統一的編碼規則。
統一的返回數據的結構。
統一的錯誤申明與處理方式。
統一的公共參數，例如識別用戶身份的token，識別渠道來源的source等。
統一的加簽、加解密方式；統一的身份認證或安全體系。
3 ?安全防護?
作為請求的入口，是保護內部系統的第一道屏障，當遭受攻擊時要盡可能的將影響降為最低。所以應該具備清洗惡意攻擊的流量，能夠在流量異常的時候屏蔽這些異常請求，或者對這些請求進行限制。
驗證請求信息，屏蔽非法請求，確保接口的安全性，保證所有達底層業務系統的請求都是安全、可靠地。
4 ?流量管控?
系統的承受能力都有限，例如：當營銷活動做得好時，系統請求量超過系統的服務能力的極限，如果放任不管，勢必壓垮內部系統，此時應該對內部系統提供一定的保護。
作為服務能力的出口，一旦不可用，在外部看來所有的服務都不可用，所以應該網關必須高可用、高并發。
常見的手段有：限流、降級、熔斷
5 ?協議轉換?
對外提供的都是HTTP接口，但內部系統是使用Dubbo來相互調用的，所以網關勢必要能夠完成協議轉換，并通過負載均衡等手段將請求高效的分發到內部系統中去。
6 ?其他業務?
1) ? 接口文檔管理?
業務發展變化勢必引起服務的增加或者擴展，如果能夠統一的對文檔進行維護，勢必會降低開發、聯調、定位問題成本。我們的做法是通過api規范自動生成接口文檔。
2) ? 調試工具和示例?
當接入方很多，提供一個調試工具或者提供示例將會極大的簡化接入成本。
3) ? SDK自動生成能力?
為客戶端（Android、IOS或者第三方調用者）生成SDK，簡化接入、降低對方開發成本。
4) ? API增強?
參數注入。例如注入userId、來源、ip等。?
合并多個請求。例如：在一個頁面中可能需要訪問多個接口才能拿到所有的數據，此時為了方便調用方使用，網關可以提供合并多個接口的能力，讓調用方同時發起多個http請求。
二 API網關核心指標?
1 ?模型?
2 ?安全性?
常用的手段有：
防篡改，例如參數加簽。
請求安全：請求端加密，網關層解密。
身份校驗：必須是合法的用戶，必須是合法的第三方。
接口安全級別。例如：接口不需要登錄即可訪問；需要登錄方可訪問；接口僅提供給app，H5不能使用等
接口權限限制。
黑白名單。
HTTPS。
3 ?高并發性?
作為企業級API的入口，所有接口都通過網關，流量可想而知是非常大的。
常見的手段有：
多級緩存
應用級緩存：堆緩存、磁盤緩存；
分布式緩存：熱點數據緩存
并發：線程池；請求緩存；請求合并
4 ?高可用性?
網關故障時，在外部來看就是整個系統不可用；所以網關應該做到7*24小時穩定運行；能夠自動伸縮；API熱更新；對做到接口級別、應用級別的限流和降級；支持負載均衡；支持多機房；（準）實時的系統監控；應該有一定的隔離性，避免單點故障引起雪崩。
5 ?擴展性?
網關縱向擴展性：企業的服務能力、安全性隨業務的發展而變化，所以網關要能隨著業務發展靈活的調整。
網關橫向擴展性：網關需要能應對業務發展而帶來的流量激增，至少緊急是可以通過增加機器帶來成比例的增加服務能力。
網關應該避免頻繁調整。
6 ?運維成本?
升級發布網關、新服務的接入應該簡單，方便。
?三 API網關架構?
1 ?幾個要點?
要支持高并發、高可用。
不必要、非安全的請求不要到下游服務中去。
網關不負責任何業務相關內容，僅負責協議轉換、請求轉發。
接口要符合規范；文檔與接口應同步。
2 ?網關整體模塊?
?
3 ?系統領域劃分?
防護層
? ? ?? 負責安全與流控；保障系統安全；可以直接在nginx層編碼，例如openresty。
接入層
? ? ? 負責統一接入相關的所有內容。
核心層
? ? ? 負責請求驗證、API增強、協議轉換、負載均衡等。另外核心層也可以包含限流、降級、熔斷功能
4 ?系統分層模型?
服務提供者將服務注冊到網關
防護層作為網關的第一入口；過濾掉非法、無法處理的請求后，將請求交給核心層處理。
核心層轉換協議通過Dubbo調用服務提供者接口，然后將調用數據沉淀，為防護層限流、降級、熔斷等提供數據支撐。
5 ?防護層?
防護層主要業務域是：限流、降級、熔斷；核心目標是保證后端系統不會大流量、異常流量擊垮。
防護層是入口，從性能上考慮，完全可以通過在nginx層實現，例如通過openresty實現。架構如下：
?
6 ?接入層?
作為統一接入方，網關應該提供API規范，以保證對API的統一性。
1) ? 接入規范?
a) ? ?模型?
b) ? ?規范?
API組
? ? ? ? 用于對api進行歸類，限制錯誤碼范圍等。
API方法
? ? ? ? 對應于每一個API接口，包括：名稱、描述、使用范圍、安全級別、狀態、適用范圍。
公共參數
? ? ? ? 例如：token、sign、渠道、format、方法、應用等。
業務參數
? ? ? ? 名稱、是否必填、默認值、是否加密等
錯誤碼聲明
? ? ? ? 類、屬性注釋
2) ? 接入?
服務提供者，根據規范定義接口，然后接入到網關，網關進行校驗，校驗通過則生成文檔、SDK、RPC實例等。
?
3) ? 文檔?
通過注解來定義規范，其中非常重要第一點就是生成客戶端調用文檔，并且文檔應該和接入的接口同步更新。因為接入時解析注解，所以很容易做到這一點。
7 ?核心層?
1) ? 驗證層?
驗證層主要保證交付給業務系統的接口都是合法、有效的。
安全驗證分為：常規型（sign驗證）、應用型（Appkey）、用戶型（token）、接口型（安全級別、參數必填、非空等）四種驗證；這四種分別對應不同層次，用于不同目的。
?
2) ? 增強層?
增強層主要提供API增強功能，例如：支持合并多個api請求；請求參數注入等。
3) ? 協議轉換?
將外部的HTTP接口轉換成內部的Dubbo接口。
8 ? ? ? ?高并發、高可用?
高并發、高可用技術以后找機會詳細分析，這里暫不詳細討論。
從上面的領域劃分、系統分層中可以看到，每一層都是可以分布式集群部署，并且可以水平擴展的，最不濟的情況是流量激增的時候等比例的增加服務器。
四 安全?
目前有很多的成熟的安全策略，他們足以應對絕大多數公司的安全需要；使用他們的時候需要清晰每種策略的用途以及適用范圍。在這里主要介紹常用的幾種策略，如：通用安全策略、設備級安全、應用級安全、接口級安全、用戶級別安全來介紹幾種。
1 ?核心要素?
衡量一個系統是否安全主要有兩個核心要素：
? ? ?? 破解的難度。
? ? ?? 破解后危害范圍有多大。
? ? ?? 對于開發者而言，通過抓包獲取請求的參數，通過分析javascript的邏輯或者反編譯app來分析app的邏輯，兩方面結合起來就可以偽造用戶請求，面對這種困境，我們應該盡可能增大破解難度，降低破解后對系統的危害以及影響面。
2 ?安全策略?
1) ? 安全策略?
2) ? 通用安全策略?
a) ? ?請求信息加簽?
請求參數加簽的最重要目的是實現請求數據防篡改功能。主要用于防止通過修改請求數據偽造請求，攻擊系統、破壞用戶數據的行為。
一般而言在H5、app中，加簽邏輯都可以通過（反編譯代碼）分析代碼來獲悉，一般僅僅將加簽作為請求防篡改的手段。
如果是服務端A向服務端B發送請求，因為服務端代碼部署在內網，他人無法獲知其中邏輯，此時可以通過兩端約定一個字符串，加簽的時候使用此字符串，但是請求時不傳遞次字符串，服務端B收到請求以后，同樣在加簽的時候使用此字符串，由此可以實現請求防篡改、請求參數安全的目的。個人并不是很贊同這種做法，主要原因是將請求參數防篡改和請求參數安全兩者混淆了，并且因為兩端約定的字符串恒定不變，一旦被人破譯出此字符串，將導致他人可以完全偽造此參數。
b) ? ?防止請求重復提交?
相同的請求多次提交到服務端，在大多數場景中（并不是所有場景中）都不是正常的行為，此時應該處理掉這些重復的請求。常見的處理手段有：客戶端提交一次請求以后禁用按鈕；客戶端進入頁面時在頁面中保存一個隨機字符串，服務端同時受到的請求中含有相同的此值時，忽略后一個請求；服務端防并發處理等等。
c) ? ?注入攻擊?
最常見的就是SQL注入了。
d) ? ?Cookie劫持?
第三方通過javascript獲取、修改Cookie的信息。服務端通過httponly模式來設置cookie可以解決這個問題。
e) ? ?混淆打包?
混淆打包主要針對app、javascript，用于增大他人破解難度。
3) ? 設備級安全?
設備級安全主要是用于防止第三方通過反編譯app、分析javascript代碼，解析出系統安全規則，從而完成系統攻擊的目的。
后文將介紹一種保障App的設備級安全的方案。
4) ? 應用級安全?
常見的場景有：營銷活動中，一個用戶只能參加一次活動，如一個用戶只能秒殺一個商品；同一個ip最多能只能參加10次抽獎。使用驗證碼接收器，通過虛擬號注冊app，刷獎勵；同一個ip（某一個時間段內）的請求量不能超過N，防止并發攻擊；等等。
這些場景與具體的業務相關，而且很多時候規則也會各有不同，通常使用分布式鎖、風控等手段一起這些問題。
5) ? 接口級安全?
常見的場景有：接口的參數、返回結果是否需要加密；接口有只有在登錄狀態時才能訪問還是任何時候都能訪問；接口是否只是針對app的還是app、h5、web都可以訪問；請求中是否包含了接口要求的所有參數；參數格式是否符合要求等等。
6) ? 用戶級別安全?
常見的場景有：是否擁有某一個菜單的權限；是否必須登錄或授權才能使用某部分功能；是否允許自己的信息被他人查看；等等。
3 ?企業級設備安全解決方案?
沒有最好的方案，只有最適合的方案。設計安全方案時要充分考慮公司的安全級別、業務訴求、開發人員水平、使用復雜度等。
以下是之前使用過的一種安全解決方案。這里僅討論RSA加密的方式，其實也支持AES加密，流程比較簡單，所以就不做討論。
1) ? 設備注冊?
app第一次打開的時候進行設備注冊，其核心目標是為了生成device token和證書。
device token是設備token，通過它可以解析出是哪一臺設備。
證書中包含RSA加密的公鑰，如果請求參數需要加密，客戶端可以通過此公鑰進行加密。
2) ? 用戶登錄?
登錄流程其實是獲取user token的過程；這樣做的目的是：這里還將用戶信息和設備信息綁定在一起了，可以做到一臺設備一個用戶；可以很簡單的實現設備互踢，即一個用戶只能在一個設備互踢。
3) ? HTTP請求處理
收到HTTP請求以后，通過解析user token或者device token來獲取用戶、設備信息，如果是合法的用戶、設備，那么允許用戶的后續操作，如果是不合法的，將請求直接攔截掉。
總結
- 上一篇： 串口服务器与无线网桥组合,网桥和无线网桥
- 下一篇： 介绍一款原创的四则运算算式生成器：Cal