跳到主要內容

黃金級贊助商 - 蝦皮購物:擁抱開源技術,推進架構演進

蝦皮購物是一家服務臺灣、印尼、越南等7個東南亞市場的電商平臺,涵蓋了從C2C拍賣、B2C購物到B2B2C商城等多種業務。從2015年開始上線到如今成為區域性的最大電商平臺,蝦皮的系統架構在這段期間承受住了使用者和訂單火箭般地飛速成長,也伴隨著很多痛並快樂的煩惱。而這些煩惱中,有相當一部分就與蝦皮使用的各種各樣的開源軟體相關。

開源軟體還是商業產品?

很多開源軟體都有對應的商業產品,蝦皮從誕生的第一天起,就經常面臨是使用開源軟體方案還是商業產品方案的選擇。舉個例子來說,像大家開啟蝦皮的時候,所有的請求流量會發到蝦皮的負載均衡器,負載均衡器會做按照預先定義的規則做各種各樣的處理,包括服務發現、動態路由、健康檢查、熔斷、故障轉移等等。大家可以想下,因為所有流量都會經過這樣的一個負載均衡的系統,所以我們對它的效能、可用性、可拓展性的要求就非常高。

在負載均衡器領域,F5、A10和AWS的ELB就是非常出名的商業產品。F5和A10都是基於硬體提供的負載均衡,AWS的ELB則是基於軟體。對於F5和A10這種硬體產品來說,一般採購它們的產品的時候是有一定規格和處理能力上限的,且1Gbps和10Gbps有不同的價格,而蝦皮的流量增長又特別快,假設我們這個月買了一臺1Gbps的F5或A10,過不了多久就會因為當前的F5或A10撐不住而要買另一臺更高規格的來進行升級。而且更麻煩的是,像這些硬體負載均衡器的升級只能是替換成更高階的裝置,且升級的過程會造成相當長的一段時間無法訪問網站。而像某些雲服務提供商的負載均衡方案,我們使用它的時候就完全無法撐住蝦皮的海量請求,當雲服務發生問題時我們完全束手無策。這些雲服務對我們來說是一個黑盒子,裡面程式碼到底是如何執行的,我們完全不瞭解,當遇到問題需要解決的時候,我們需要提ticket,來回溝通的週期特別長,至少都要好幾個星期,而我們對服務的可用性要求有特別高,任何時候有問題,都需要第一時間立刻恢復服務,使用商業產品對我們來說,就不得不面對這樣那樣的矛盾。

所以我們最終是基於LVS和Nginx這樣的開源軟體開發了我們自己的負載均衡系統,相比商業產品,開源軟體的程式碼開放,社群使用者參與活躍,我們參與到其中去,一方面可以基於開源軟體開發出更符合蝦皮業務場景的系統並快速定位和修復問題,另一方面也能在向上遊報BUG,修復BUG的過程中和開源社群一起成長,從而更好地支撐業務的發展,保障蝦皮的使用者體驗。

使用開源軟體 A 還是使用開源軟體 B?

對開源軟體來說,即使是同一類別,可能也會有很多不同的選擇。比方說Cache,常見的就有Memcached和Redis。在蝦皮早期的時候,我們就經常遇到Redis CPU跑滿的問題。我們使用profiling工具一查,發現當用戶請求湧進來的時候,我們的服務短時間建立了大量地連線到Redis,而Redis是單執行緒,只能使用一個CPU Core,導致Redis都在處理連線的建立和斷開,正常的Cache讀寫都無法處理,最終導致服務處理請求時大量超時報錯。那時我們為了避免Redis的CPU跑滿的問題,就換用成是多執行緒模型的Memcached。換了Memcached後效果立竿見影,CPU使用都均攤到了每個CPU Core,非常均衡。當然換成Memcached也帶來了一些不方便的地方,因為Memcached不像Redis一樣支援豐富的不同的資料結構和讀寫命令,中間對系統的改造確實是一個相當痛苦的過程。

從今天來看,我們再看看蝦皮到底是使用了Redis還是使用了Memcached。答案是我們都用。蝦皮是由很多不同的分散式系統和服務組成,有不同的場景和業務要求,有些場景用Redis非常合適,直接使用一個Redis自帶的命令就可以解決;有些場景用Memcached就更合適,比方說上面提到的那個例子;有些場景則可以直接上Redis Cluster的方式來繞過Redis單Instance時只能用一個CPU的限制。

在蝦皮的各種不同系統中,從前端到後臺,從資料庫到作業系統,我們使用了大量不同的開源軟體。很多時候並不是非此即彼,用了A就不用B,用了B就不用A。每種開源軟體都有其適合的場景,也有其相對應的優缺點。只要能解決問題,都值得使用嘗試和使用。像Redis和Memcached一樣,他們都是非常優秀的Cache,又有各自適合的場景,對我們來說,都值得使用和學習。

如何正確使用開源軟體和參與開源社群?

在蝦皮,我們使用開源軟體都是當成白盒子來使用。使用開源軟體,意味著也要承擔開源軟體中存在的BUG帶來的風險。在最開始的選型時,我們會去提前瞭解每個開源軟體的內部實現和評估潛在的問題,從而避免使用了不合適的開源軟體,最終折返重頭開始的情況。在使用過程中,遇到問題時和社群保持溝通,修復BUG並回饋patch給社群。

對我們來說,如果使用一個開源軟體,而我們卻不瞭解它內部是如何工作,出問題毫無解決頭緒,無法基於已有的開原始碼做二次修改的話,還不如直接使用相應的商業解決方案,至少商業解決方案有專業支援。比方說Ceph這個分散式檔案儲存系統,蝦皮在使用的過程中,就經常因為各種各樣的原因踩到Ceph的坑,但是Ceph這個分散式的檔案儲存對我們而言又非常重要,每次Ceph出問題都會導致我們的系統當機很長時間,客服人員電話會被海量的使用者投訴打爆,造成非常嚴重的後續影響。這逼著我們不斷地閱讀和熟悉Ceph的各個元件和程式碼,逐漸地糾正之前使用Ceph的錯誤方式,patch相關的地方以便故障時能快速恢復。

而隨著蝦皮使用者量和業務量的不斷增長,很多之前可能是正常工作的開源軟體到了某個瓶頸之後就無法再正常工作。這也讓我們對了解開源軟體的程式碼和內部實現有了更高要求,需要我們能即時定位到效能瓶頸。比方說我們使用Nginx,在過去三年中一直執行的非常穩定,突然前幾天就出現把所有CPU Core跑滿的問題。所幸在過去幾年中,我們基於Nginx的原始碼做了大量工作,對Nginx的程式碼比較熟悉,這次就很快定位到了是一處shared memory lock競爭導致的效能衰退。

蝦皮對這些開源軟體的修改,我們一般會根據實際情況把這些patch提交回上游merge。像Linux Kernel、Docker、Tensorflow等等開源專案中都有蝦皮工程師提交的patch。當然也存在這樣的情況,改動的地方上游覺得不夠好,或者有其他解決方案拒絕或者推遲了我們的patch,或者merge和review的速度非常慢。這個時候可以fork出一個版本,當然也保持開源,這樣其他人如果遇到了和我們一樣的問題的時候,參考我們的改動,也會對他們帶來一定啟發。參與開源社群有很多中方式,不一定提交patch並merge才算,報BUG是一種方式,改進使用說明資料是一種方式,fork出另外的分支也是一種方式,最終都能在開源社群相互交流,共同進步。

蝦皮自研軟體和開源的關係?

在蝦皮,我們廣泛使用了各種各樣的開源專案,但我們也有非常多的核心元件是自行研發。對蝦皮來說,自研和開源並不是對立的,並不是蝦皮自己喜歡重新發明輪子。我們知道,就算是輪子,也分很多種,比方說自行車的輪子和跑車的輪子要求就不一樣,而飛機的輪子又和跑車的輪子要求不同。有些時候,開源社群可能只能找到自行車的輪子,那假設蝦皮要開始造飛機了,在開源社群裡面找不到飛機輪子的實現,那麼沒辦法,我們只能自行研發。

同樣的,在考量解決方案的時候,我們會先看看是否已有開源的方案能解決我們的需求,如果有的話,已有的開源方案是否足夠成功,設計足夠好,執行是否足夠穩定,如果不成熟的話,我們是否可以在這個基礎上,在上面再開發改進。如果整個開源軟體設計優秀,很容易擴充套件和改進,和我們期望的解決方案比較匹配,那麼我們就會採用,一方面節約了資源的投入,同時又能少走一些彎路,而且開源社群不止蝦皮,很多組織都在參與,在整個生態系統中,每個參與的團體做的改進其他團體都能受益。

但也存在開源社群中我們無法找到相對應的實現或者滿足我們要求的實現的情況,這個時候我們會自行研發解決方案。大家知道像蝦皮支援的業務型別非常多,對核心系統和元件有各種各樣的業務要求以及效能上的考量,在廣泛使用開源軟體的同時,蝦皮也有大量自行研發的元件,共同支撐了業務的飛速成長。

蝦皮成立三年來業務飛速成長,離不開各種優秀的開源專案,也在不斷地回饋開源社群,如果你熱愛開源,熱愛Coding,就快快加入我們一起共同成長吧。心動不如馬上行動,火速開啟 https://careers.shopee.com/ 投遞簡歷吧!

留言

這個網誌中的熱門文章

COC 通報處理說明公告 - 20240811 通報事件

各位好, COSCUP COC 服務小組於 2024 年 8 月 11 日接獲一件通報,內容涉及在會期干擾議程進行;並於會後持續發送私訊予會中結識的講者;同時,該行為人亦被紀錄於活動當日干擾志工執行勤務。 有關此事件的處理過程,詳如下述: COC 服務小組接到通報後,於 8 月 15 日正式成立專案小組進行討論與檢視相關資料。經查,通報內容與 COC 條款「持續干擾議程或活動的正常進行,無視工作人員或與會者的制止」相符。同一行為人於大會期間,另有兩位會眾通報類似事件,COC 服務小組皆已明確指正其行為並重申 COC 規範和界線。綜合此次會後通報,行為人經提醒仍多次抵觸 COC 條例。 有鑒於上述行徑已明確影響 COSCUP 其他會眾之權益,COC 服務小組將依照 COSCUP COC 之辦法記錄事件處理過程及結果、行為人資料等,於籌備團隊組長群資料夾建立文件,以俾後續籌備團隊審慎思量該名行為人未來的參與形式與程度。 在此,感謝會眾願意信任 COC 和 COSCUP 團隊並且將其所遇到的事件於會後彙整提供予我們。另本次通報中,通報人所提及之部分事項,因非屬 COSCUP 大會參與期間和相關行為,已建議通報人另行循其他正規途徑處理。在此聲明, COSCUP 的 COC 落實並非要拒任何人於門外,而是希冀透過針對行為本身的評估,為無論志工、社群協調人、講者、廠商與所有會眾營造舒適與安全的交流環境。 我們在乎所有人於 COSCUP 大會的各種參與體驗與感受,如果您在大會和籌組期間有相關困擾,籌備團隊志工將會竭力協助釐清,希望一同打造友善的 COSCUP 與會環境。 COSCUP 2024 COC 服務小組

利用 Jitsi 建立個人化的視訊會議平台

  近期因為疫情的關係,越來越多企業開始實施分流或在家工作,視訊會議的需求也日益增加。 在商用解決方案選擇上,有不少企業會選擇知名品牌的產品,例如  Cisco Webex 、 Google Meet 、 Microsoft Teams 、 Zoom  都是很不錯的方案。 KKBOX 集團在去年便試行及做好充分 work from home 的準備,今年五月也因應疫情升溫,全員 work from home 至今兩個月有餘。 當然,取之 Open Source,也要對社群有些貢獻。在這一屆 COSCUP,我們要來介紹 Open Source 圈中也很知名,效果也很不錯的一套視訊會議平台: Jitsi 。 除了基本的視訊會議功能外,在最後我們也會示範如何透過 Jitsi 畫面輸出到 YouTube/Twitch 或其他支援 RTMP 的平台進行直播。 由於篇幅有限,且 Jitsi 可以調整的細節非常多。今天我們純粹很快速的示範,如何簡單的建置出一個 Jitsi 環境,並提供單場會議內容錄影或直播。 Jitsi 的文件可以在 這裡 找到。 今天透過 AWS Lightsail 的 $10/month instance(1 core CPU + 2GB RAM + 60GB SSD),作業系統則是 Ubuntu 20.04 來示範。當然,使用其他 VPS 亦可,大同小異,這邊直接跳過 VPS 相關的建置過程。 *firewall 相關資料參考 這裡 及 這裡 。 針對系統做必要的更新 基本的 apt repository 更新: $ sudo apt update 因為後面要示範的會議錄影及直播需要使用 ALSA loopback device,如果是 EC2 or Lightsail 則需要額外安裝 generic kernel( 註 ): $ sudo apt install linux-image-generic linux-headers-generic linux-image-extra- virtual 接著做系統套件們的更新: $ sudo apt dist-upgrade $ sudo apt autoremove 如果是 AWS EC2 or Lightsail 則需要另外再將預設的 AWS optimized kernel...

你所不知道的 foodpanda

  2020 左右,隨著新冠疫情流行,台灣也逐漸流行起一股懶人旋風。懶懶躺在沙發上,動動手指滑滑螢幕,生鮮或美食就能快速又安全地由可愛的粉紅色熊貓外送員送達您門口。多數人知道 foodpanda 是台灣最大生鮮美食外送平台,也不少人知道 foodpanda 在台灣不斷擴張業務範圍,但 foodpanda 也有許多台灣科技圈所不知道的事。 例如,foodpanda 其實並非台灣本土廠商,也非只專注在亞洲區域。foodpanda 隸屬於德國 Delivery Hero 集團,業務橫跨歐洲、亞洲、美洲及北非,旗下更有十多個生鮮美食外送品牌。除此之外,foodpanda 於 2021 年時也在台灣正式成立全球第三個 Tech Hub。做為四大產品 RD 研發中心之一,台灣與德國柏林、新加坡及土耳其伊斯坦堡的人才緊密地合作,專注於打造 end-to-end 的顧客體驗。諸如月費方案 Panda Pro、外帶自取、餐廳內用 (目前仍未在台灣上市) 等功能。期待能持續吸收優秀人才、與其它三個跨國研發中心合作,打造後疫情時代新的成長引擎。 事實上,台灣的 foodpanda 研發團隊並不僅止於打造台灣本土產品。反之,我們所建立的平台及產品,已成功於近 20 個國家、10 個品牌上市。要在快速的步調下,打造持續進步且符合不同國家文化客戶需求的產品,我們依靠的是 專案團隊成員一條龍組合 從 Product Manager、Engineering Manager、iOS/Android/Web/Backend developer、QA、Product Designer、Product Analyst 全都在同一個 product line squad。讓相同產品的團隊成員能緊密合作、第一手快速了解市場、滿足需求。 國際專業團隊緊密合作 foodpanda 的 iOS/Android/Web/Backend 等專業工程師,都各自設有其跨 squad 的 chapter 組織。讓工程師能在專案團隊以外,有跨國跨團隊專業能力交流的機會。在 chapter 中,相同技術域領的專家們,會一起制定共同的實作標準、分享在專案中遇到類似的挑戰,並且找出可能的應對方案。因此,在 foodpanda 我們不只打產品專案團隊的速度戰、還打整個集團的整合能力團體戰,讓德國、新加坡、台灣、伊斯坦堡的工程師...