13518219792
軟件開發中，安全是永恒的話題，FastAPI作為一個優秀的Python Web開發框架，為用戶提供了多種工具，幫助用戶以標準的方式輕松快速地解決軟件開發中的安全性。
創新互聯是一家專業提供蕉城企業網站建設,專注與網站設計、成都網站建設、H5網站設計、小程序制作等業務。10年已為蕉城眾多企業、政府機構等服務。創新互聯專業網站制作公司優惠進行中。
FastAPI 的 fastapi.security 模塊中為各種安全方案提供了一些工具，這些工具簡化了這些安全機制的使用方法。
FastAPI提供的OAuth2PasswordBearer是使用 OAuth2的密碼授權模式的Bearer Token(不記名 token) 。創建OAuth2PasswordBearer 實例需要接收URL作為參數。
客戶端會向該 URL 通過表單的格式發送 username 和 password 參數，然后得到一個 token 值；OAuth2PasswordBearer 并不會創建相應的 URL 路徑操作，只是指明了客戶端用來獲取 token 的目標 URL。
代碼示例：
在上面的代碼中， tokenUrl="token"指的token是相對 URL 。
此時訪問，其返回結果：
上面的結果表明：訪問的內容以及被保護，必須經過授權后才可以訪問。
當獲取到表單數據后，需要進行密碼校驗，一般情況下，我們都會考慮使用哈希密碼，PassLib 是一個用于處理哈希密碼的非常好的 Python 包，它支持許多安全哈希算法以及配合算法使用的實用程序。
具體passlib的使用方法可以查看其文檔
下面的代碼示例在上面代碼的基礎上增加用戶登錄及Token驗證
啟動應用并執行請求：
測試無效登錄：
測試正常登錄：
返回token，在Headers中使用token訪問：
修改token后請求：
上面的代碼如果去掉 await verify_token(token) 行，則：
curl -H "Authorization:Bearer u000010007" -i
會得到返回結果，原因是默認情況下，OAuth2PasswordBearer只負責請求頭中是否具有Authorization:Bearer，如果有就會執行相應的請求，所以，為了驗證Token的正確性，需要每個方法都執行相應的驗證代碼。
本例只作為例子，在實際開發中不會直接拿用戶ID作為Token，為了提高系統的安全性，需要使用 JWT。下面我們就介紹 JWT。
JWT是一個將 JSON 對象編碼為密集且沒有空格的長字符串的標準。 具體學習和了解 JWT，請參考 。
需要提到的主要是 JWT中的sub，JWT 的規范中有一個 sub 鍵，值為該令牌的主題。使用它并不是必須的，但這是我們放置用戶標識的地方，所以一般情況下，我們在sub中存放用戶ID， 為了避免 ID 沖突，當為創建 JWT 令牌時，可以在 sub 鍵的值前加上前綴，例如 username:、userid:等。
在 Python 中生成和校驗 JWT 令牌 ，可以使用PyJWT，也可以使用 python-jose 。我們在本例中使用 python-jose 來編寫代碼。
使用：
使用 JWT，需要在系統中添加一個SECRET_KEY變量，用于生成令牌，如：
以下代碼在上面代碼的基礎上使用 JWT 令牌。
與前面的代碼差別之處：
1.生成Token的函數：build_access_token
2.校驗Token的函數：verify_token
3.登錄函數：login
請求測試：
登錄：
令牌訪問：
錯誤的令牌訪問：
在大部分應用程序中，當用戶訪問某個接口API的時候，都需要明確訪問者的身份，所以在應用程序中需要隨時獲取當前用戶，由于在 JWT 令牌的 sub 字段中已經保存了用戶信息，所以獲取當前用戶只需要對令牌解碼即可。
在上面的代碼的基礎上，增加兩個函數，代碼如下：
請求測試：
以上，我們完成了一個簡單的安全性示例，FastAPI提供的安全性框架幫助我們節約了很多代碼，但在實際開發中，我們常常使用微服務的方式來開發，對于鑒權最好設計獨立的微服務進行處理。后面我們會展示一個采用FastAPI開發的鑒權微服務，以便在此基礎上進行業務系統的開發。
打開企業管理器,打開SQLServer組,下面有個安全性,里面有個登錄,登錄里面就是數據庫的賬號管理了.
對于增強WiFi的安全性，我們需要注意下面幾點。
采用WPA/WPA2J加密方式，省心又安全。
設置隱藏SSID，讓壞人不容易發現家庭WiFi。
及時修改路由器后臺賬號密碼。
及時修改WiFi接入密碼，密碼盡可能復雜一些。
啟用mac地址過濾功能，綁定經常使用的設備。
在手機端和電腦端安裝安全軟件。
做到這些，WiFi的安全性已經比較高了。
微服務1架構的目標是幫助工程團隊更快，更安全，更高質量地交付產品。解耦服務允許團隊快速迭代，對系統的其余部分影響最小。
在Medium，我們的技術堆棧始于2012年的單片Node.js應用程序。我們已經構建了幾個衛星服務，但我們還沒有制定一個系統地采用微服務架構的策略。隨著系統變得越來越復雜并且團隊不斷發展，我們在2018年初轉向了微服務架構。在這篇文章中，我們希望分享我們有效地做到這一點并避免微服務綜合癥的經驗。
首先，讓我們花一點時間來思考微服務架構是什么，不是什么。 “微服務”是那些過載和混亂的軟件工程趨勢之一。這就是我們在Medium認為它是什么：
該定義包括三個微服務設計原則：
Three Principles of Modeling Microservices
當我們對微服務進行建模時，我們應該遵守所有三個設計原則。這是實現微服務架構全部潛力的唯一途徑。錯過任何一個都會成為反模式。
沒有一個目的，每個微服務最終會做太多事情，成長為多個“單片”服務。我們不會從微服務架構中獲得全部好處，我們也會支付運營成本。
如果沒有松散耦合，對一個服務的更改會影響其他服務，因此我們無法快速安全地發布更改，這是微服務架構的核心優勢。更重要的是，緊密耦合引起的問題可能是災難性的，例如數據不一致甚至數據丟失。
如果沒有高凝聚力，我們將最終得到一個分布式單片系統 - 一組混亂的服務，必須同時進行更改和部署才能構建單一功能。由于多個服務協調的復雜性和成本（有時跨多個團隊），分布式單片系統通常比集中式單片系統差得多。
與此同時，了解 微服務不是什么 很重要：
在Medium，我們總是在做出重大產品或工程決策時會問“為什么現在？”這個問題。 “為什么？”是一個顯而易見的問題，但它假設我們擁有無限的人，時間和資源，這是一個危險的假設。當你想到“為什么現在？”時，你突然有了更多的限制 - 對當前工作的影響，機會成本，分心的開銷等等。這個問題有助于我們更好地優先考慮。
我們現在需要采用微服務的原因是我們的Node.js單片應用程序已經成為多個方面的瓶頸。
首先，最緊迫和最重要的瓶頸是其性能。
某些計算量很大且I / O很重的任務不適合Node.js.我們一直在逐步改進整體應用程序，但事實證明它是無效的。它的低劣性能使我們無法提供更好的產品而不會使已經非常慢的應用程序變慢。
其次，整體應用程序的一個重要且有點緊迫的瓶頸是它會減慢產品開發速度。
由于所有工程師都在單個應用程序中構建功能，因此它們通常緊密耦合。我們無法靈活地改變系統的一部分，因為它也可能影響其他部分。我們也害怕做出重大改變，因為影響太大，有時難以預測。整個應用程序作為一個整體進行部署，因此如果由于一次錯誤提交導致部署停滯，那么所有其他更改（即使它們完全正常工作）也無法完成。相比之下，微服務架構允許團隊更快地發貨，學習和迭代。他們可以專注于他們正在構建的功能，這些功能與復雜系統的其余部分分離。更改可以更快地進入生產。他們可以靈活地安全地嘗試重大變革。
在我們新的微服務架構中，更改會在一小時內完成生產，工程師不必擔心它會如何影響系統的其他部分。該團隊還 探索 了在開發中安全使用生產數據的方法2多年來一直是白日夢。隨著我們的工程團隊的發展，所有這些都非常重要。
第三，單一應用程序使得難以為特定任務擴展系統或隔離不同類型任務的資源問題。
使用單一的單一應用程序，我們必須擴展和縮小整個系統，以滿足更多資源需求的任務，即使這意味著系統過度配置用于其他更簡單的任務。為了緩解這些問題，我們對不同類型的請求進行分片，以分離Node.js進程。它們在一定程度上起作用，但不會擴展，因為這些微單一版本的單片服務是緊密耦合的。
最后但同樣重要的是，一個重要且即將成為緊迫的瓶頸是它阻止我們嘗試新技術。微服務架構的一個主要優點是每個服務都可以使用不同的技術堆棧構建，并與不同的技術集成。這使我們能夠選擇最適合工作的工具，更重要的是，我們可以快速安全地完成工作。
采用微服務架構并非易事。它可能會出錯，實際上會損害工程生產力。在本節中，我們將分享七個在采用早期階段幫助我們的策略：
有人可能會認為采用新的服務器架構意味著產品開發的長時間停頓以及對所有內容的大量重寫。這是錯誤的做法。我們永遠不應該為了建立新的服務而建立新的服務。每次我們建立新服務或采用新技術時，都必須具有明確的產品價值和/或工程價值。
產品價值應以我們可以為用戶提供的利益為代表。與在單片Node.js應用程序中構建值相比，需要一項新服務來提供值或使其更快地交付值。工程價值應該使工程團隊更好，更快。
如果構建新服務沒有產品價值或工程價值，我們將其留在單一的應用程序中。如果十年內Medium仍然有一個支持某些表面的單片Node.js應用程序，那就完全沒了問題。從單一應用程序開始實際上有助于我們戰略性地對微服務進行建模。
建立具有明確價值的新服務
有人可能會認為采用新的服務器架構意味著產品開發的長時間停頓以及對所有內容的大量重寫。這是錯誤的做法。我們永遠不應該為了建立新的服務而建立新的服務。每次我們建立新服務或采用新技術時，都必須具有明確的產品價值和/或工程價值。
產品價值應以我們可以為用戶提供的利益為代表。與在單片Node.js應用程序中構建值相比，需要一項新服務來提供值或使其更快地交付值。工程價值應該使工程團隊更好，更快。
如果構建新服務沒有產品價值或工程價值，我們將其留在單一的應用程序中。如果十年內Medium仍然有一個支持某些表面的單片Node.js應用程序，那就完全沒了問題。從單一應用程序開始實際上有助于我們戰略性地對微服務進行建模。
單片持久存儲被認為是有害的
建模微服務的很大一部分是對其持久數據存儲（例如，數據庫）進行建模。跨服務共享持久數據存儲通常似乎是將微服務集成在一起的最簡單方法，然而，它實際上是有害的，我們應該不惜一切代價避免它。這就是原因。
首先，持久數據存儲是關于實現細節的。 跨服務共享數據存儲會將一個服務的實現細節暴露給整個系統。如果該服務更改了數據的格式，或者添加了緩存層，或者切換到不同類型的數據庫，則還必須相應地更改許多其他服務。 這違反了松散耦合的原則。
其次，持久數據存儲不是服務行為，即如何修改，解釋和使用數據 。如果我們跨服務共享數據存儲，則意味著其他服務也必須復制服務行為。 這違反了高內聚的原則 - 給定域中的行為泄露給多個服務。如果我們修改一個行為，我們將不得不一起修改所有這些服務。
在微服務架構中，只有一個服務應該負責特定類型的數據。所有其他服務應該通過負責服務的API請求數據，或者保留數據的 只讀非規范（可能具體化）副本 。
這可能聽起來很抽象，所以這是一個具體的例子。假設我們正在構建一個新的推薦服務，它需要來自規范帖子表的一些數據，目前在AWS DynamoDB中。我們可以通過兩種方式之一為新推薦服務提供發布數據。
在單片存儲模型中，推薦服務可以直接訪問單片應用程序所執行的相同持久存儲。這是一個壞主意，因為：
緩存可能很棘手。 如果推薦服務與單一應用程序共享相同的緩存，我們也必須在推薦服務中復制緩存實現細節;如果推薦服務使用自己的緩存，當單片應用更新帖子數據時，我們將不知道何時使其緩存無效。
如果單片應用程序決定更改為使用RDS而不是DynamoDB來存儲帖子數據，我們將不得不重新實現推薦服務中的邏輯以及訪問帖子數據的所有其他服務。
單片應用程序具有解釋帖子數據的復雜邏輯 ，例如，如何確定帖子是否應該對給定用戶不可見。我們必須在推薦服務中重新實現這些邏輯。一旦整體應用程序更改或添加新邏輯，我們也需要在任何地方進行相同的更改。
即使推薦服務是自己的數據訪問模式的錯誤選項，推薦服務仍然停留在DynamoDB上。
在解耦存儲模型中，推薦服務不能直接訪問發布數據，也不能直接訪問任何其他新服務。發布數據的實現細節僅保留在一個服務中。有不同的方法來實現這一目標。
Option A 理想情況下，應該有一個擁有帖子數據的Post服務，其他服務只能通過Post服務的API訪問郵政數據。但是，為所有核心數據模型構建新服務可能是一項昂貴的前期投資。
當人員配置有限時，還有一些更實用的方法。根據數據訪問模式，它們實際上可能是更好的方式。
在 選項B 中，單一應用程序可讓推薦服務知道何時更新相關的帖子數據。通常，這不必立即發生，因此我們可以將其卸載到排隊系統。
在 選項C 中，ETL管道生成推薦服務的發布數據的只讀副本，以及可能對推薦有用的其他數據。在這兩個選項中，推薦服務完全擁有其數據，因此它可以靈活地緩存數據或使用最適合的數據庫技術。
解耦“建立服務”和“運行服務”
如果構建微服務很難，那么運行服務往往更難。 當運行服務與構建每個服務相結合時，它會減慢工程團隊的速度，團隊必須不斷重新發明這樣做。我們希望讓每項服務都專注于自己的工作而不用擔心如何運行服務的復雜問題，包括網絡，通信協議，部署，可觀察性等。服務管理應該與每個服務的實現完全分離。
由于最近在 容器化，容器編排，服務網格，應用程序性能監 控等方面的技術進步，“運行服務”的解耦變得比以往更容易實現。
網絡。 網絡（例如，服務發現，路由，負載平衡，流量路由等）是運行服務的關鍵部分。傳統方法是為每種平臺/語言提供庫。它工作但不理想，因為應用程序仍然需要非常繁瑣的工作來集成和維護庫。通常，應用程序仍然需要單獨實現某些邏輯。現代解決方案是在Service Mesh中運行服務。在Medium，我們使用 Istio和Envoy作為邊車代理 。構建服務的應用工程師根本不需要擔心網絡問題。
通信協議 。無論您選擇哪種技術堆棧或語言來構建微服務，從一個高效，類型化，跨平臺且需要最少開發開銷的成熟RPC解決方案開始是非常重要的。支持向后兼容性的RPC解決方案也使部署服務更加安全，即使它們之間存在依賴關系。在Medium，我們選擇了gRPC。
一種常見的替代方案是基于HTTP的REST + JSON，它長期以來一直是服務器通信的福音解決方案。但是，盡管該堆棧非常適合瀏覽器與服務器通信，但它對于服務器到服務器的 通信效率很低 ，尤其是當我們需要發送大量請求時。如果沒有自動生成的 存根和樣板代碼 ，我們將不得不手動實現服務器/客戶端代碼。可靠的RPC實現不僅僅包裝網絡客戶端。另外，REST是“自以為是”，但總是讓每個人都對每個細節都達成一致很困難，例如，這個調用真的是REST，還是只是一個RPC？這是一種資源還是一種操作？等等
部署。 擁有一致的方法來構建，測試，打包，部署和管理服務非常重要。所有Medium的微服務都在容器中運行。目前，我們的編排系統是AWS ECS和Kubernetes的混合體，但僅限于Kubernetes。
我們構建了自己的系統來 構建，測試，打包和部署 服務，稱為BBFD。它在一致地跨服務工作和為個人服務提供采用不同技術堆棧的靈活性之間取得平衡。它的工作方式是讓每個服務提供基本信息，例如，要監聽的端口，構建/測試/啟動服務的命令等，BBFD將負責其余的工作。
徹底和一致的可觀察性
可觀察性包括允許我們了解系統如何工作的過程，約定和工具，以及在不工作時對問題進行分類。可觀察性包括日志記錄，性能跟蹤，指標，儀表板，警報，并且對于微服務架構的成功至關重要。
當我們從單個服務遷移到具有許多服務的分布式系統時，可能會發生兩件事：
我們失去了可觀察性，因為它變得更難或更容易被忽視。
不同的團隊重新發明了輪子，我們最終得到了零碎的可觀察性，這實際上是低可觀察性 ，因為很難使用碎片數據連接點或分類任何問題。
從一開始就具有良好且一致的可觀察性非常重要，因此我們的DevOps團隊提出了一致的可觀察性策略，并構建了支持實現這一目標的工具。每項服務都會自動獲取詳細的DataDog儀表板，警報和日志搜索，這些服務在所有服務中也是一致的。我們還大量使用LightStep來了解系統的性能。
并非每一項新服務都需要從零開始構建
在微服務架構中，每個服務都做一件事并且做得非常好。請注意，它與如何構建服務無關。如果您從單一服務遷移，請記住，如果您可以從單片應用程序中剝離微服務并不總是必須從頭開始構建。
在這里，我們采取務實的態度。我們是否應該從頭開始構建服務取決于兩個因素：（1）Node.js適合該任務的程度如何;（2）在不同的技術堆棧中重新實現的成本是多少。
如果Node.js是一個很好的技術選項并且現有的實現很好，我們將代碼從單片應用程序中刪除，并用它創建一個微服務。即使采用相同的實現，我們仍將獲得微服務架構的所有好處。
我們的單片Node.js單片應用程序的架構使我們可以相對輕松地使用現有實現構建單獨的服務。我們將在本文稍后討論如何正確構建單片。
尊重失敗，因為他們會發生
在分布式環境中，更多的東西可能會失敗，而且它們會失敗。如果處理不當，任務關鍵型服務的失敗可能是災難性的。我們應該始終考慮如何測試故障并優雅地處理故障。
從第一天起避免使用微服務綜合癥
微服務不是靈丹妙藥 - 它解決了一些問題，但創造了一些其他問題，我們將其稱為“微服務綜合癥”。如果我們從第一天開始就不去考慮它們，那么事情會變得很快，如果我們以后再照顧它們會花費更多。以下是一些常見癥狀。
隨著最近的技術創新，采用微服務架構要容易得多。這是否意味著我們都應該停止構建單一服務？
雖然新技術支持得更好，但微服務架構仍然存在高度復雜性和復雜性。 對于小型團隊來說，單一的應用程序通常仍然是更好的選擇。但是，請花些時間來構建單片應用程序，以便以后在系統和團隊成長時更容易遷移到微服務架構。
在Medium，我們在早期的單片應用程序中做出了一些很好的架構決策。
我們的單片應用程序由組件高度模塊化，即使它已經發展成為一個非常復雜的應用程序，包括Web服務器，后端服務和離線事件處理器。脫機事件處理器單獨運行，但使用完全相同的代碼。這使得將一大塊業務邏輯剝離到單獨的服務相對容易，只要新服務提供與原始實現相同（高級）的接口即可。
我們的整體應用程序在較低級別封裝了數據存儲詳細信息。每種數據類型（例如，數據庫表）具有兩層實現：數據層和服務層。
這有助于我們采用微服務架構，因為一種類型數據的實現細節完全隱藏在代碼庫的其余部分。創建新服務來處理某些類型的數據相對容易且安全。
單片應用程序還可以幫助我們對微服務進行建模，并使我們能夠靈活地專注于系統中最重要的部分，而不是從頭開始為所有微服務建模。
單片Node.js應用程序為我們服務了好幾年，但它開始減慢我們從運送偉大的項目和快速迭代。我們開始系統地和戰略性地采用微服務架構。我們仍處于這一旅程的早期階段，但我們已經看到了它的優勢和潛力 - 它大大提高了開發效率，使我們能夠大膽地思考并實現大量的產品改進，并解鎖了工程團隊以安全地測試新技術。
加入Medium的工程團隊是一個激動人心的時刻。如果這聽起來很有趣，請查看我們的工作頁面 - 在Medium工作。如果您對微服務架構特別感興趣，您可能需要先了解這兩個開頭：高級全棧工程師和高級平臺工程師。
原文 :
討論: 請加入知識星球【首席架構師圈】
