成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

敖丙:大廠是如何設計接口的?我:傻瓜...

開發 架構
所謂冪等,簡單地說,就是對接口的多次調用所產生的結果和調用一次是一致的。數據發生改變才需要做冪等,有些接口是天然保證冪等性的。

[[351337]]

本文轉載自微信公眾號「三太子敖丙」,作者三太子敖丙 。轉載本文請聯系三太子敖丙公眾號。

背景

隨著業務的發展,系統架構從單體架構變為面向服務架構,水平分層架構;再變為微服務架構,

服務網格,服務與服務間的交互越來越復雜,如何優雅的設計一個接口,需要考慮哪些方面?特別是對公服務(比如BFF)需要對外提供公網域名的接口,安全性怎么保證,我整理了我工作以來一些常見的措施以及具體如何去實現:

數據有效性校驗

合法性校驗包括:常規性校驗以及業務校驗;常規性校驗:包括必填字段校驗,長度校驗,類型校驗,格式校驗等;業務校驗:根據實際業務而定,比如訂單金額不能小于0等;

冪等設計

所謂冪等,簡單地說,就是對接口的多次調用所產生的結果和調用一次是一致的。數據發生改變才需要做冪等,有些接口是天然保證冪等性的。

比如查詢接口,有些對數據的修改是一個常量,并且無其他記錄和操作,那也可以說是具有冪等性的。其他情況下,所有涉及對數據的修改、狀態的變更就都有必要防止重復性操作的發生。通過間接的實現接口的冪等性來防止重復操作所帶來的影響。

又比如我們電商比較常見的加減GMV同一個消息無論過來多少次結果都應該只加減一次,不然會導致金額錯誤甚至造成資損。

請求層面: 多次執行的結果是一致的業務層面: 同一個用戶不重復下單,商品不超賣,MQ不重復消費

冪等的本質是分布式鎖的問題,分布式鎖正常可以通過redis或zookeeper實現;

在分布式環境下,鎖定全局唯一資源,使請求串行化,實際表現為互斥鎖,防止重復,解決冪等

安全性

1. 數據加密

我們知道數據在傳輸過程中是很容易被抓包的,如果直接傳輸比如http協議傳輸,那么數據在傳輸的過程中可能被任何人獲取。

所以必須對數據進行加密,常見的做法是對敏感數據比如身份證號進行md5加密。現在主流的做法是使用https協議,在http和tcp之間添加一層數數據安全層(SSL層),這一層負責數據的加密和解密。https如何配置和使用,大家翻閱我歷史文章自行去研究。

對稱加密: 密鑰在加密過程中和解密過程中是不變的,常見的算法有DES,AES;優點是加解密計算速度快;缺點是數據傳送前,服務雙方必須約定好密鑰,如果一方密鑰泄露,加密信息也就不安全了。

非對稱加密: 密鑰成對出現,一個密鑰加密之后,由另外一個密鑰來解密;私鑰放在服務端文件中,公鑰可以發布給任何人使用;優點是比對稱加密更安全,但是加解密的速度比對稱加密慢多了,廣泛使用的是RSA算法;

https的實現正好是結合了兩種加密方式,整合了雙方的優點,在安全性和性能方面都比較好。對稱加密和非對稱加密的代碼實現,jdk提供了相關的工具類可以直接使用,本文不過多介紹。

2. 數據簽名

介紹3種數據簽名安全策略:摘要[KEY] , 簽名[證書] , 簽名+加密[證書]

安全策略 描述 安全級別
摘要[Key] 將數據和Key(自定義契約密碼)組合后進行摘要 安全級別低,契約密鑰安全性非常低。在契約密鑰安全情況下能基本保障數據的不可篡改性。
簽名[證書] 使用證書和非對稱簽名算法對數據進行簽名 安全級別中,能夠保障數據的不可篡改性和不可抵賴性,但是不能保障數據的私密性
簽名-加密[證書] 使用證書和非對稱算法對數據簽名,使用一次一密的密鑰和對稱算法對數據進行加密 安全級別高,能夠保障數據的不可篡改性和不可抵賴性,而且能保障數據的私密性。
  • 機密性(Confidentiality): 未經許可不許看
  • 完整性(Integrity) : 不許篡改
  • 可用性(Availability) : 防止不可用
  • 不可抵賴性(Non-Repudiation): 用戶不能否認其行為

摘要[KEY]過程:將需要提交的數據通過某種方式組合成一個字符串,然后通過md5生成一段加密字符串,這段字符串就是數據包的簽名,比如:

  1. str:參數1={參數1}&參數2={參數2}&……&參數n={參數n}$key={用戶密鑰}; 
  2. MD5.encrypt(str); 

摘要[KEY]原理:Hash算法不可逆,并且計算結果具有唯一性,在key 的隱私得到保證的情況下,可以保證完整性摘要[KEY]缺陷:key的隱私性很難保證,明文傳輸

簽名[證書]過程:客戶端對明文做一個md5/SHA計算,對計算后的值通過私鑰加密得到密文,客戶端將明文和密文發送給服務端,服務端對密文通過公鑰解密得到值A,同時服務端對明文做一個md5/SHA計算得到值B,比較值A與值B,相同得驗證通過,能夠保障不可篡性和不可抵賴性,但是不能保障數據的私密性(明文傳輸)

簽名+加密[證書]過程:客戶端生成一個隨機字符串,作為password,然后把這個password通過B公鑰加密生成密文C,把A明文通過password加密生成密文B, 同時把A明文做MD5/SHA計算后的值通過A私鑰加密得到簽名D, 把密文B和密文C和簽名D發給服務端,服務端通過私鑰解密文C得到password,然后通過password解密文B就可以得到A明文,同時簽名可以用來驗證發送者是不是A,以及A發送的數據有沒有被第三方修改過。

可以假設存在一個惡意的一方X,冒充了A,發送了密文B(password生成),密文C服務端收到數據后,仍然可以正常解密得到明文,但是卻無法證明這個明文數據是A發送的還是惡意用戶B發送的。簽名D的含義就是A自己簽名,服務端可以驗證。X由于沒有A的私鑰,這個簽名它無法冒充,會被服務端識別出來。

加密-簽名

3. 時間戳機制

數據經過了加密處理,酒店抓取到了數據也看不到真實數據;但是有不法者不關心真實數據,拿到數據后直接進行惡意請求,這個時候簡單的做法可以考慮時間戳機制,在每次請求中加入當前時間,服務端會將報文中的時間與系統當前時間做比對,看是否在一個固定的時間范圍內比如5分鐘,惡意偽造的數據是沒法更改報文中時間的,超過5分鐘就可以當作非法請求了。

偽代碼如下:

  1. long interval=5*60*1000;//超時時間 
  2. long clientTime=request.getparameter("clientTime"); 
  3. long serverTime=System.currentTimeMillis(); 
  4. if(serverTime-clientTime>interval){ 
  5.     return new Response("超過處理時長"

4. AppId機制

大部分網站需要用戶名和密碼才能登陸,這其實是一種安全機制;對應的服務也可以使用這一機制,不是誰都可以調用,調用服務前必須先申請開通一個唯一的appid,提供相關的密鑰,在調用接口時需要提供appid+密鑰信息,服務端會進行驗證。

appid使用字母,數字,特殊符號等隨機生成,生成的唯一appid看系統實際要求是否需要全局唯一;不管是否全局唯一最好有以下屬性:

趨勢遞增: 這樣在保存數據庫的時候,索引的性能更好

信息安全: 隨機生成,不要是連續的,容易被發現規律

關于全局唯一Id生成的方式常見的有snowflake方式等

snowflake

Xnip2020-11-04_19-31-00

以上示意圖描述了一個序列號的二進制組成結構。

第一位不用,恒為0,即表示正整數;接下來的41位表示時間戳,精確到毫秒。為了節約空間,可以將此時間戳定義為距離某個時間點所經歷的毫秒數(Java默認是1970-01-01 00:00:00)。

再后來的10位用來標識工作機器,如果出現了跨IDC的情況,可以將這10位一分為二,一部分用于標識IDC,一部分用于標識服務器;最后12位是序列號,自增長。

snowflake的核心思想是64bit的合理分配,但不必要嚴格按照上圖所示的分法。如果在機器較少的情況下,可以適當縮短機器id的長度,留出來給序列號。

5. 黑名單機制

如果此appid進行過很多非法操作,或者說專門有一個中黑系統,經過分析之后直接將此appid列入黑名單,所有請求直接返回錯誤碼;

我們可以給每個appid設置一個狀態比如包括:初始化狀態,正常狀態,中黑狀態,關閉狀態等等;或者我們直接通過分布式配置中心,直接保存黑名單列表,每次檢查是否在列表中即可;

限流機制

常用的限流算法包括:令牌桶限流,漏桶限流,計數器限流;

  • 令牌桶限流令牌桶算法的原理是系統以一定速率向桶中放入令牌,填滿了就丟棄令牌;請求來時會先從桶中取出令牌,如果能取到令牌,則可以繼續完成請求,否則等待或者拒絕服務;令牌桶允許一定程度突發流量,只要有令牌就可以處理,支持一次拿多個令牌;
  • 漏桶限流漏桶算法的原理是按照固定常量速率流出請求,流入請求速率任意,當請求數超過桶的容量時,新的請求等待或者拒絕服務;可以看出漏桶算法可以強制限制數據的傳輸速度;
  • 計數器限流計數器是一種比較簡單粗暴的算法,主要用來限制總并發數,比如數據庫連接池、線程池、秒殺的并發數;計數器限流只要一定時間內的總請求數超過設定的閥值則進行限流;

具體基于以上算法如何實現,Guava提供了RateLimiter工具類基于基于令牌桶算法:

  1. RateLimiter rateLimiter = RateLimiter.create(5); 

以上代碼表示一秒鐘只允許處理五個并發請求,以上方式只能用在單應用的請求限流,不能進行全局限流;這個時候就需要分布式限流,可以基于redis+lua來實現;

總結

其實接口不管是設計還是開發,如果不是特別急的需求大家都可以多一點思考,這樣你的系統才會更穩定,上線和測試過程中bug更少,而且從個人提升角度來說,多思考總是一件好事。

很多時候大家都在抱怨:哎呀我公司小,我學校差這種環境得不到成長。傻瓜,很多時候高手也是這樣走過來的,不過一樣的事情每個人的態度不一樣,時間久了結果也就不一樣了。

好啦,現在大家應該都上班了,我熬夜值班還在大促現場(文章周末寫的,現在就寫個總結),我是敖丙,你知道的越多,你不知道的越多,我們下期見。

 

責任編輯:武曉燕 來源: 三太子敖丙
相關推薦

2020-11-16 09:45:23

SQL

2020-08-14 09:04:34

分布式事務

2021-04-29 08:53:49

電商流程引擎

2021-04-20 08:53:51

工廠模式電商公司設計模式

2021-11-02 08:54:35

Linux CPULinux 系統

2021-04-13 08:54:28

dubbo線程池事故排查

2020-11-12 18:20:28

接口數據分布式

2015-03-23 09:33:43

Java抽象類Java接口Java

2022-04-27 11:46:56

設計師設計目標設計方案

2023-03-21 17:06:24

樹莓派路由器

2024-05-20 08:25:55

2015-08-10 14:56:31

Google

2020-09-22 15:21:08

微信設計騰訊

2021-08-24 14:46:24

設計阿里巧思

2023-12-11 14:20:00

系統緩存本地緩存

2021-05-25 09:00:52

責任鏈模式設計模式面試經歷

2022-02-21 16:41:32

設計解決方案UI

2022-03-08 08:09:39

UI設計師體驗

2021-08-07 07:23:08

Webpack中間件模型

2016-05-18 10:04:17

技術面試
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 欧美中文字幕在线观看 | 麻豆久久久久久久久久 | 国产精品国产三级国产aⅴ原创 | 999国产精品视频 | 久久中文网 | 作爱视频免费看 | 成人在线观看免费 | 成人av一区二区三区 | 91私密视频 | 日本黄色不卡视频 | 美女张开腿露出尿口 | 欧美激情视频一区二区三区在线播放 | 伊人伊人 | 午夜精品久久久久久不卡欧美一级 | 天天艹日日干 | 成人欧美一区二区三区在线播放 | 四虎影院在线观看av | 国产精品色综合 | 99精品网站 | 精品少妇一区二区三区在线播放 | 中文字幕一区二区三区精彩视频 | 在线国产欧美 | 亚洲天堂av一区 | 成人在线视频免费观看 | 成人网av | 精品国产一区二区三区性色av | 日韩成人在线播放 | 色综合99 | 一区二区三区亚洲 | 久久一区二区精品 | 亚洲在线 | 久久这里只有 | 亚洲国产一区二区三区在线观看 | 麻豆久久| 亚洲69p | 欧美激情a∨在线视频播放 成人免费共享视频 | 国产97色| 天天看逼 | 国产一级免费视频 | 91精品国产777在线观看 | 亚洲v区 |