官方承諾：K60至尊版將會首批升級MIUI 15
全新的MIUI 15今天也有了消息，在官宣了K60至尊版將會搭載天璣9200+處理器和獨顯芯片X7的同時，Redmi給出了官方承諾，K60至尊重大更新首批升級，會首批推送MIUI 15。也就是說雖然
Scai，攜程高級研發經理，多年深耕于賬號中臺，持續推進中臺的技術架構演進及性能優化。
在互聯網早期時代，賬號系統的功能非常廣泛，包括賬號管理、登錄認證相關能力以及維護各類用戶信息，比如頭像、昵稱、積分、等級等。隨著業務的發展，每個功能逐漸分化出自己的需求和架構側重點，獨立出各自的領域服務也成了業界共識。
本文分享的賬號系統，指的是提供用戶賬號管理、登錄認證相關能力的系統。介紹了攜程在不斷發展的過程中，賬號系統在領域化、中臺化和多Region化方向上的演進、探索和一些思考。
微服務迅猛發展階段，賬號系統分裂出了很多應用。比如，專門支持三方登錄的應用，專門保存賬號實名信息的應用，針對不同平臺的接入應用。一開始確實可以滿足迅速開發上線的需求，當應用裂變到幾十個的時候，應用分層不合理，領域邏輯不內聚帶來的問題逐漸顯現出來：
1）用戶請求會經歷多個應用之間的RPC調用，性能和穩定性受影響。
2）操作無法原子性，易出現臟數據。
3）應用過多，開發、運維、測試范圍大，影響效率。
領域化是對賬號系統的全面重構，有以下兩個目標：
1）合理劃分領域，邏輯內聚。
2）改造需要對業務透明。
圖片
賬號系統功能主要分為3個類型：
1）核心功能：負責管理和維護賬號系統的核心功能和數據。由于涉及到用戶的核心數據，相關插入、變更接口只可暴露給業務BFF層。
賬號領域：包括賬號信息查詢；賬號注冊/注銷；手機、郵箱、三方等數據的綁定/解綁；openid的生成；密碼的管理和認證等功能。
登錄態領域：負責登錄態生成、驗證、續期、踢出、過期刪除等功能。
日志監控領域：負責記錄賬號相關業務埋點和日志。
2）輔助功能：不僅可以被賬號相關業務依賴，也可以開放出去供類似業務場景的接入。
Token（臨時憑證）領域：負責Token的生成、驗證、過期刪除等功能。
驗證碼領域：負責驗證碼生成、發送、驗證等功能。
3）接入功能：負責賬號相關的業務功能接入，包括端上接入和內網服務接入。
BFF層：主要負責各類業務邏輯的組合（注冊、登錄、改綁手機等）以及接入方權限的控制。
前端UI、SDK：前端顯示UI以及提供出去供業務接入的SDK。直接對接BFF層。
其他一些業務中必須依賴的模塊，如風控模塊，依賴公司相應團隊提供的能力即可。
賬號系統非常核心，上游是公司的各類業務，依賴方非常多，牽一發而動全身。同時，業務也在急速發展，不會停下來等待系統的改造。對賬號系統的改造無疑是在快速開動的汽車上更換輪胎。因此，對賬號系統的改造需要一套完整的比對流程，需要滿足兩個條件：
1）完整性。比對需要覆蓋100%的場景，避免場景遺漏。
2）隔離性。比對需要在離線集群和存儲上進行，避免對在線系統造成影響。同時，需要屏蔽掉離線集群不必要的對外請求，以免對下游造成影響（包括RPC調用，消息，監控數據等）。
在此基礎上，完成了賬號系統的讀寫比對流程：
讀對比：轉發-比對。利用鏡像流量的能力，將鏡像流量導入離線Old代碼集群。Old代碼集群在處理流量的同時，會轉發到離線New代碼集群，完成接口返回數據比對。
圖片
寫比對：錄制-回放-比對。提前錄制生產環境的流量，記錄輸入、輸出和發出的消息等數據；分別部署New/Old代碼離線集群和兩套相同的離線DB（里面數據為同一時間點的Snapshot）；將錄制好的流量（DB Snapshot時間點后）回放到兩套集群上，比對輸出、存儲、發出來的消息等數據，確保New/Old集群和錄制的結果三方一致。
圖片
完成了領域化改造后，核心數據的變更沉淀到對應的領域服務中，相關操作可以滿足原子性，避免臟數據的產生；應用減少以及引入BFF層，減少了應用間，用戶端和服務端的交互次數，提升了系統穩定性，提升了開發、運維、測試的效率。
和大部分互聯網公司一樣，隨著集團的發展，會出現不同的品牌，需要一套獨立的賬號體系。也有業務團隊會將自己研發的賬號系統交給賬號團隊統一管理。如果賬號系統沒有做好中臺化的準備，勢必會在接入的過程中手忙腳亂。不僅代碼中會存在大量的判斷邏輯，接入時間也會很長，甚至可能無法滿足業務的需求。中臺化的改造需要考慮以下三點：
1）降低改造復雜度
減少系統的架構改造復雜度
降低業務接入的復雜度
2）配置化
將需求抽象為功能，減少對業務需求的定制化開發
簡單配置即可快速接入
3）提供多樣化的接入方式，以滿足不同業務方的接入需求
中臺化改造過程中，賬號體系ID是最核心的概念。
因此，對于賬號相關查詢請求，如果不知道賬號所在的體系ID，就無法找到對應的存儲。要么進行全存儲查詢，要么需要一個大表存儲UID到體系ID的映射關系，這會引入額外的依賴，提高成本的同時，也會使得系統變得復雜。
另外，要求所有上游新增一個參數需花費大量的資源推動。
圖片
UID全局唯一，并且通過編碼區分不同的體系ID，可以大大降低改造和接入的復雜度。
新接入的賬號體系，通過UID的編碼可以快速判斷賬號體系ID。
對于存量UID，默認屬于最早的賬號體系。
同時，UID全局唯一也可以提高排障和TS時的效率（不用反復確認某一個UID屬于哪個賬號體系）。
當然，一些不通過UID進行的查詢接口，如通過手機號查詢賬號的場景，還是需要業務方傳遞體系ID，但通過這樣的設計已極大的縮小了需要改造的范圍。
賬號中臺化后主要提供以下能力：
1）賬號管理：管理賬號的完整生命周期，包括注冊，驗證，注銷。支持賬號綁定手機號，郵箱，第三方賬號，以及對應屬性的變更、解綁操作。管理賬號密碼，支持多種加密邏輯。管理Oauth相關數據。
2）多樣化登錄方式：包括賬號密碼登錄，手機驗證碼登錄，手機一鍵登錄，掃碼登錄，社交賬號登錄等登錄方式。特別的，在社交賬號登錄方式中，賬號系統已完成了與多個平臺的對接，常見的比如微信、支付寶、QQ、微博、華為等。
3）登錄態管理：包括登錄態的生成、驗證，登錄態信息維護，按需續期、踢出等功能。
4）安全&監控體系：賬號中臺具有完善的日志體系，并已完成對接前端滑塊和后端實時風控。
在中臺化建設的過程中，雖然已經全量梳理了中臺應該提供的能力，仍然會有新的需求需要支持。在接到新的需求，而現有的功能無法支持的時候，不要急于解決本次需求，需要思考本次需求涉及的具體功能，從而在實現的過程中避免定制化邏輯，沉淀為中臺的新能力。
比如，某次需求為：一個賬號體系全平臺需要保證登錄態是唯一的，即新的登錄產生后，會踢出之前的登錄態?？梢猿橄鬄樾枰信_提供對某一個賬號體系的登錄態數量進行控制。進一步的，可以按照平臺（App、小程序、H5等）分別進行控制。
圖片
中臺化建設完成后，不同的功能都可以通過配置進行控制，也可以對每一個功能進行細節上的調整。同一體系的配置放置在同一配置文件中，便于維護。如果沒有特別的需求，直接使用默認配置接入即可。
圖片
為了適應業務多樣化的接入需求，中臺提供了3種接入方式：
1）UI接入：在攜程的主Web站點、App和小程序，統一使用中臺開發的前端界面，業務方按需拉起。
2）前端SDK接入：有少量定制需求，如顯示的LOGO需要調整，協議需要變更等，可以使用中臺的前端SDK接入。此SDK已包含所有的流程邏輯，接入時僅需替換掉對應的元素。
3）后端對接：若業務方有過多的與業務藕合的邏輯，則不適合將邏輯放在中臺。此時，業務方可以自行開發一層BFF，利用中臺BFF層和輔助系統（驗證碼、Token）提供的能力，組合出合適的業務邏輯。
中臺化改造完成后，新賬號體系需要申請接入時，僅需選擇需要的能力，中臺通過調整配置，小時級即可完成接入。大大減少了新增一套賬號體系的支持成本。
兩地三中心是近期比較熱門的部署方案，一方面可以更好的應對城市級別的故障，另一方面可以更好的服務當地用戶（例如，一個產品定位于服務西部用戶，相應的應用和數據部署在西部城市可以提供更好的用戶體驗）。賬號作為業務的基石，需要第一時間完成多Region部署，為各業務的部署做好準備。
多Region部署，賬號中臺制定了兩個目標：
1）數據支持多Region部署，請求正確路由。結合業務需求，賬號中臺的應用和數據按需部署到指定的Region中，相應的用戶請求需要準確的落到對應的Region。
2）架構需要同構部署，不能因為多Region部署引入開發和維護上的額外成本。
為了滿足數據不同Region部署的需求，需要對用戶數據進行識別并打標，利用公司DB數據同步組件（DRC）進行帶過濾的雙向同步（有的數據僅需要本Region使用，會過濾不進行同步），將數據部署到需要的Region上。后續的更新也由DRC進行同步。
圖片
在數據部署完成后，如何保證用戶的請求落到了正確的Region。
方案一：每次請求經過網關的時候，網關進行一次用戶到Region的映射查詢，再將請求正確的路由到數據所在Region。這樣的做法不僅會對請求引入一次額外的查詢，還會使得網關這一及其關鍵的節點引入一個依賴，會影響整個網站的穩定性。
方案二：基于用戶的數據一定完整的存在某一個Region的前提，在用戶登錄的時候，將之前識別時打上的標識下發到端上。請求的時候，網關只需對標識進行簡單的路由配置，即可正確的路由到對應的Region。
圖片
在多Region的部署中，賬號中臺實現了同構部署。
1）網關層。利用網關根據用戶登錄下發的標識，將請求路由到正確的Region。
2）內網服務。通過完整的部署，內網請求在同一Region內完成，實現Region閉環，提高服務性能。同時也避免了DB多Region寫入引起數據沖突的問題。
3）數據層。
DB數據。DB表結構完全一致，通過DRC根據用戶標識進行帶過濾的多向復制。
Redis緩存數據。本地使用，不需要同步。當一個Region的數據有變更的時候，其他Region接受DRC的同步消息，對本Region的Redis進行刪除。
圖片
在這樣的多Region部署架構下，可以根據業務的使用場景和數據部署需求，實現用戶數據的單Region或多Region存儲。
賬號系統從最開始的巨大單體應用中剝離出來，經歷了若干年的演進，變成了現在支持多Region部署的賬號中臺，這是業務發展和互聯網技術進步的一種體現和必然趨勢。
當然，這種趨勢也不會停止于此，賬號系統的功能和架構必將繼續演進，其他系統也同樣如此?；赝^去，基于現在，展望未來，敢為人先，為各業務的發展打好基石，這正是賬號等基礎系統的意義所在，技術團隊的價值也存在于此。
本文鏈接：http://m.www897cc.com/showinfo-26-90504-0.html領域化、中臺化和多Region化，攜程賬號系統演進之路
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 很強！五個 python 高級技巧
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號