架構的深刻思考 From FunData

內容來源：以前做者寫了一篇《FunData — 電競大數據系統架構演進》的文章，傳送門：http://t.cn/RdgKWGW 以爲沒有深刻寫出一些深層次的東西。糾結了幾個晚上決定重寫一篇不同的文章。本文由IT大咖說（微信id：itdakashuo）整理，經投稿者與嘉賓審閱受權發佈。

閱讀字數：3497 | 9分鐘閱讀

摘要

本文與上一篇徹底不一樣，從另外一個角度來闡述爲何FunData的系統須要優化，整理出怎麼優化架構的一些思路吧，但願能爲各位看官帶來一些靈感和思考。

咱們仍是先從FunData的兩張架構圖開始吧。

圖1 ETL 架構圖1.0

圖2 ETL總架構圖2.0

架構1.0和2.0都屬於微服務架構，架構2.0在原有的基礎上對數據傳輸的模型，數據存儲與渲染的方式及服務治理等方面作了更多的改進。

數據傳輸模型

1.0架構咱們選擇的主語言是Python，系統模型是Master-Slave，經過Python自帶的MQ庫構建數據傳輸的模型。處理的邏輯即從STEAM公開接口拉取比賽數據，將比賽任務分配給各個Slave節點處理，處理記錄元數據和處理的數據落地MySQL。

InMemory的隊列模式，對咱們系統維護上帶來許多不方便。Slave節點的更新重啓，由於沒有註冊服務保證任務執行完後節點的正常下線，重啓時很隨機，沒法保證在節點內的任務正常執行完；Master的節點更新重啓，須要全部Slave節點所有重啓一次，創建新鏈接，固然這裏能夠用重連機制（這個以後會結合service mesh討論）。

所以架構2.0使用MQ服務將上下游的系統解耦開，並採用消息總線的方式推送消息，從原來的Master-Slave的方式轉成Controller-Worker的方式，這樣的好處是一方面系統更新沒有依賴，亦不須要重啓整個系統；另外一方面，更加細化的worker可讓咱們的針對不一樣數據要求編寫worker，使得數據處理變得更可控(可插拔的方式)，有針對性的作worker擴容，資源使用率更加精準。

數據落地方式

早期咱們使用的是主備模式的MySQL，容量上限爲2T，存儲上很容易出現瓶頸，當時沒有分佈式MySQL和讀寫分離模式，達到容量瓶頸後，只能新增一個主備MySQL，在ETL和API層多配置一個DB入口作數據存儲和聚合處理，着實很麻煩，另外配置要維護的很準確；另外團隊數據點的需求一直在變化，結構化的存儲很不利於數據點的擴展。

2.0裏咱們果斷選擇NoSQL且分佈式存儲的方式，具體請參考FunData電競大數據系統裏對數據存儲的設計和思考。

服務治理

1.0的系統屬於快速迭代上線的產物，旁路系統的建設幾乎爲0，系統在線上經常是「裸奔」的狀態。爲了保證服務的穩定性，咱們引入了不少旁路建設。

• K8S - 減小服務運維壓力，增長系統的擴展性。

• 日誌系統 - 系統處理異常可追蹤

• 灰度系統與負載均衡 - 接口更新及請求流量可控

• Harbor + Registry - 鏡像倉庫統一管理，代碼分版本

• CI/CD - 快速上線，統一部署與測試

• Serverless - 將耗資源的算法，分配到serverless服務，不獨立維護系統，pay-as-you-go

……

咱們在FunData的微服務架構上還在持續優化，經過更好的架構和計算模型處理更多的數據，處理更多的電競遊戲數據。

看了FunData的架構優化後，可能你們有疑問說咱們在系統的架構設計上爲何不能一步到位呢？微服務架構是"萬金油"麼？

我的認爲系統設計是沒有統一公式的，關鍵在於在系統迭代的過程當中，經過合理的分層與組合獲得符合業務發展的架構形態。在系統架構設計上有以下一些思路，供你們參考。

單點系統

項目早期或者demo階段，單點服務設計的方式會更加適合。一方面快速驗證想法，另外一方面沒有太多成本上的壓力，不要考慮HA/AZ容災之類，功能實現和業務邏輯的自證纔是核心。

單點系統

對於小團隊，單點服務使用一個repo維護代碼已經足夠，也只須要一臺服務器跑起服務便可。

微服務

微服務架構的使用，能夠從如下幾點考慮

• 團隊變大，單個repo的代碼變得臃腫，包含10幾種的業務功能，好比商城的登陸、用戶體系、購物車、支付等等。這種一個panic就搞垮整個商城的設計已經沒法知足業務發展。

• 資源使用率良莠不齊，能夠考慮把邏輯拆分出來，對更細化的系統作合理的擴展，也不容易遇到一個業務瓶頸拖垮整個網站的狀況。

• 系統須要分層和抽象時，好比拆分部分邏輯後，再整個系統須要一個統一的接入層作請求的調度，再好比數據量增大時，須要有獨立的數據代理層來處理數據的聚合和batch insert的操做。

微服務架構參考

設計微服務架構時，通常是分層的設計思路，主邏輯鏈路上通常能夠分爲接入層、邏輯層、存儲層，各旁路系統則是服務於各個主鏈路層的各類服務。

例如：接入層引入負載均衡和灰度系統，實現流量控制，限速限流，高峯降級等；邏輯層接入註冊服務和調度服務，幫助處理內部RPC的合理分配和高可用；存儲層使用存儲代理，負責讀寫分離，批量寫入及數據聚合等工做。

像日誌服務、監控服務和底層的應用管理平臺、雲平臺做爲任何形態的系統都必不可少的模塊，服務於整個系統。

FunData監控

FunData日誌分析

除了使用旁路系統爲整個系統保駕護航，代碼層面上也有很多工做，好比爲提高內部系統通訊的成功率和穩定性，咱們須要增長重試的機制；對於內部使用的隊列、對象存儲和註冊服務等封裝了統一的SDK，提供鏈接池、定時更新服務列表及註冊搶主等機制。

到目前爲止，微服務架構已經被不斷的實踐，圍繞微服務架構的技術棧也層出不窮，例如Spring Cloud系列的微服務框架（以下圖），傳統的ELK日誌服務，Prometheus/Falcon監控系統，Etcd分佈式存儲，kubernetes容器服務等。

然而，微服務的架構不是萬能的，隨着系統的增多，對系統的管理成本會逐漸增長，服務之間的依賴關係也更加複雜。對於一個大型微服務系統(上百個節點的那種)，工程師須要花大量時間去理解裏面的調用依賴。另一點也是個人切身體會，在開發業務邏輯時，對於上述提到的重試機制、智能RPC調度及限速限流等功能，有時並非我最關心的，業務邏輯纔是核心，可是在微服務架構中不得不注入更多的保護代碼，或者引用個龐大的通用SDK來完成這些功能。爲此，2017年左右，業界提出了Service Mesh的概念。

借大佬的話「Service Mesh一般用於描述構成這些應用程序的微服務網絡以及它們之間的交互。隨着規模和複雜性的增加，服務網格愈來愈難以理解和管理。它的需求包括服務發現、負載均衡、故障恢復、指標收集和監控以及一般更加複雜的運維需求，例如A/B測試、金絲雀發佈、限流、訪問控制和端到端認證等」。

傳送門

https://www.nginx.com/blog/what-is-a-service-mesh/

Service Mesh不是一個新的架構體系，而是做爲微服務架構的一次升級，將服務發現、負載均衡、故障恢復等在架構設計中系統層面的優化抽象出來，做爲一層基礎設施，用於搭載各個業務邏輯。高大上的說法就是，讓算法專一於算法，業務服務於業務。經過Service Mesh將系統Robust的各中優化與保護脫離於業務開發，可能將來就是系統工程師和業務開發工程師的區別了。

Serverless

最後的最後，Serverless的架構也是你們能夠考慮和選擇的。咱們在內部也有Serverless系統的實踐。

《Serverless的概念與系統架構設計》傳送門：https://myslide.cn/slides/8295

在考慮serverless架構時，主要有如下幾個考量

• 成本 - Serverless做爲更碎片化的一種架構模式，這類服務通常只對使用多少核小時進行計費，不須要關心服務器部署

• 耗時計算或流量不穩定的計算 - Serverless系統通常搭載大量機器提供10萬級以上的核數，若是業務上有一些算法消耗計算時間或者存在大量併發的突發狀況，能夠考慮將業務邏輯和算法接入Serverless作處理，減小運維壓力。

• 事件觸發的Pipeline - 舉個栗子，咱們會把圖片、視頻等靜態資源上傳到對象存儲， 單張圖片可能就有多種使用場景，例如須要裁剪、轉格式或者加強之類，這時可使用Serverless服務，即在有圖片上傳時觸發各類圖片處理的算法。

傳送門關閉~~~搓爐石回城