网关系统架构
目錄
?
一 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