小紅書推廣

                        小紅書基礎架構演進歷程

                        來源:未知日期:2022/05/31 15:20 瀏覽:
                        早年間云計算剛起步的時候,Infrastructure as a Service 概念興起,基礎設施即服務,各大云計算服務來支撐各個企業的業務發展。同樣的道理,基礎架構在公司內部相當于技術底座,對各個業務進行賦能,其重要性不言而喻。

                        賀晉如博士在回國之前,曾在 Facebook,Pinterest 工作過,后回國加入茄子快傳,小紅書。在國外的工作經歷中有些收獲對于現在的工作很有幫助的。用賀晉如自己的話說,分為兩方面,第一方面是技術上,他曾經非常有幸和一些世界上很優秀的工程師一起工作,一起從 0 搭建大規模的分布式系統。這里的收獲不僅僅是如何搭建各種系統,更多是跟這些大師學到的搭建復雜系統的思維體系,比如:如何在設計復雜系統時做各種架構上的取舍:如何寫高質量的代碼;如何有效的定位線上故障并及時排障。這些收獲是讓他在后面很長時間都有所收益。

                        第二方面是在工程師文化上,在 Facebook 的時候,公司鼓勵工程師去不斷嘗試,不設限的去參與解決各種問題。

                        這些技術上和文化上的收獲其實都在回國后的工作里起到了比較大的幫助,這些幫助也潛移默化的影響著他的工作。目前,賀晉如是小紅書基礎架構負責人,負責公司的云原生架構,高可用的服務架構,數據庫,緩存和 NoSQL 存儲系統。以下是對賀晉如的采訪整理。

                        InfoQ:您的工作內容基本上是圍繞基礎架構領域,可以介紹一下您現在在小紅書帶領基礎架構部門具體做哪些事情么?
                        賀晉如: 小紅書推廣的基礎架構主要包括數據庫緩存,存儲,中間件,Kubernetes 云原生計算等相關內容。

                        中間件系統的完整是隨著業務的需要而慢慢建立起來的,當這些系統成體系,完善后,威力巨大。也許這就是堅持長期主義,相信技術的力量,允許犯錯,提供平臺的結果。

                        我們之前在中間件的迭代上碰到過很多問題,總的來說,最核心的點在于如何讓中間件的升級迭代成本變低。舉個例子,我們曾經對中間件版本做了一次比較大的升級操作,對流量進行精細化的控制。出發點是好的,要求業務方去設置這些參數,讓服務更加的高可用。但事實上,在我們推動升級的過程中,一部分用戶其實并不關注這些配置項,另外一些用戶關注但不知道如何配置。業務方不愿意升級,得一個一個業務去做宣傳或者幫他們升級。

                        拿到這些反饋后,我們意識到,需要做到讓業務方的改動盡量的少,才能使推廣新版本的成本足夠的低。所以我們在后續的中間件迭代里就秉持了一個理念:中間件的升級需要盡量做到業務無感知,讓業務方接入成本足夠的低;任何一次版本的變動都需要做到足夠的向下兼容。 為此,我們開始在后續的版本著手施行無感知升級的方案,這樣中間件的升級迭代的成本就下來了。

                        InfoQ:你們在招聘網站上對存儲方面的候選人要求,對 Redis、MySQL 等數據庫相關產品內核優化;緩存、數據庫中間件性能優化、功能迭代;其他分布式數據庫解決方案預研。想了解,你們現在的數據存儲方案有哪些?對于存儲有怎樣的特殊需求?有哪些解決方案?
                        賀晉如: 我們現在數據大部分都存放在自建的 MySQL 和 MongoDB 里,同時緩存使用的是自建的 Redis。這里值得一提的是,小紅書的 Redis 集群在 2018 年就已經實現全部容器化在 Kubernetes 上部署了,應該算業界比較早嘗試做存儲容器化的公司。4 月份的 ArchSummit 全球架構師峰會上, 我們緩存團隊的同學也會和大家分享這方面的經驗。在存儲方面,我們自建了高性能的 KV 存儲,這部分在去年的 QCon 已經做了分享。

                        隨著小紅書業務的不斷成長,緩存集群的規模也在擴大,現有的集群方案已經不能滿足要求了。我們目前正在進行緩存架構上的迭代,包括對緩存內核的優化,對節點探活機制的改進等等,力求滿足超大規模緩存集群的要求。

                        目前存儲的拼圖還相對比較薄弱:除了 KV 存儲以外,我們還有類似于 Facebook TAO 的一跳圖查詢引擎。但其實業務對我們的需求是很多的:包括支持復雜圖查詢的圖數據庫;表格存儲;強一致的 KV 存儲,時序數據的存儲引擎;對象存儲和塊存儲。這些都需要我們慢慢補齊。此外,隨著業務的增長,我們也在探索基于持久化內存的 KV 存儲。

                        InfoQ:MySQL、MongoDB、TiDB 等數據庫產品在你們內部的選用,有哪些考量因素?如何配合業務需求?
                        賀晉如: 主要考量因素是業務的需求和可擴展性,以及我們目前數據庫團隊的規模。我們會更傾向于使用更加主流的產品來作為我們存儲核心數據的方案。因為 MySQL 在高可用,數據復制方面都有比 MongoDB 更加成熟的方案,也更容易運維。

                        InfoQ:異地多活等高可用建設上,具體是怎么做的,技術上攻克了哪些難點?現在處于什么階段?
                        賀晉如: 我們目前正在從單云架構向著多云架構演進。多云架構和傳統的單云架構一個很大不同點是,在多云的環境里,我們讓自己的技術棧做到云獨立,同樣的業務代碼在任何一朵云上都可以跑得通。

                        這里主要的難點就是,服務間在跨云環境里的上下游調用,根據業務需求的不同,有的服務調用可以跨云,有的服務調用是需要做到嚴格限制在單元內的。新的服務發現邏輯如何做到在所有中間件版本和 mesh 數據面上都能適用,是我們當時在做多活時候的一個難點。

                        做多云多機房架構的本質是服務的高可用能力,在一個機房的服務發生故障時迅速將流量切走。這是我們面臨的另一個難點。

                        目前小紅書主要的技術改造集中在微服務訪問的單元化改造,數據庫存儲層的異地多活改造,南北流量接入層網關改造。我相信這些都是做異地多活的團隊都碰到并且需要去解決的一些問題。

                        在流量控制方面,我覺得很重要一點是在某個機房的下游服務發生故障時,故障的爆炸半徑要做到足夠的小,盡可能的控制在單機房內。

                        舉一個在實際生產中碰到的例子,在我們 SDK 設計里,流量控制參考了 mesh 的實現:默認上下游服務調用都在單機房內完成。在同機房下游服務健康實例不足的時候會自動 failover 一部分流量到另一個機房。這個設計的初衷是,在同機房下游服務出現容量不足時,能自動的把一部分流量切到另一個機房來保證上下游服務調用的正常??瓷先ナ呛芎侠淼?,但是在實際中碰到的情況是:上游服務因為流量過載把同機房內的下游服務實例打垮,上游流量會自動的 failover 到另外機房的下游服務,另一個機房的下游服務由于短時間內承接了之前 2X 的流量,很快也掛了,導致我們整條鏈路宕機。如果沒有自動的跨機房流量跳轉,我們是可以把故障控制在單機房內。從而保證另外一個機房的流量是正常的。

                        InfoQ:對于先進的架構和理念選擇上,你們有哪些考量和標準?
                        賀晉如: 我覺得核心考量的標準是這些新的架構和理念是否能夠為我們的業務賦能,是否能為我們的研發工程師提效降本,是否能提高我們整體架構的穩定性。任何脫離了實際業務來談架構和理念都是沒有意義的。

                        在這個基礎上,架構的通用性和普適性也是我們考慮的因素。這套架構是否已經在相同規?;蛘吒笠幠5幕ヂ摼W公司落地。是否已經帶來了好的收益。同時一套通用的架構也更容易讓我們在市場上招到匹配的人才。

                        架構的靈活性能給我們足夠的可擴展空間進行二次開發來滿足業務的需求。我們的業務是一直在高速發展的,如果一套架構不具有可擴展性,那么有可能會在某個階段成為業務進一步發展的卡點。

                        InfoQ:在架構上,不管是設計層面,還是應用層面,您這兩年有哪些發現,或者觀察?對軟件架構的發展,有哪些預測,或者期待?
                        賀晉如: 微服務的 Serverless 化,由架構團隊來負責容器,云等底層資源管理,屏蔽底層資源差異性,向業務提供可靠、穩定、可彈性的運行環境,讓業務技術團隊能聚焦業務需求的快速迭代。

                        另外,把有狀態服務容器化上 Kubernetes。數據庫,存儲容器化后,有進一步的空間可以提升存儲集群的資源利用率。并且也可以減少運維人員的一些重復性工作。

                        嘉賓介紹:賀晉如 博士

                        小紅書基礎架構負責人,擁有十余年高性能分布式系統,微服務高可用架構工作經驗,先后在 Facebook,Pinterest 參與和主導大規模分布式圖數據庫,NoSQL 存儲系統,機器學習推理平臺等項目的設計和研發。目前在小紅書負責公司的云原生架構,高可用的服務架構,數據庫,緩存和 NoSQL 存儲系統。
                        首頁
                        電話
                        短信
                        聯系
                        抚着太后娇乳撞击娇喘