《荔枝架構(gòu)實(shí)踐與演進(jìn)歷程》閱讀有感

荔枝APP架構(gòu)演進(jìn)時間軸

• 2013年：單體架構(gòu)

這個時候的架構(gòu)是V1.0版,主要特點(diǎn)是APP 直連服務(wù)器，服務(wù)端是單體架構(gòu)。也就是說，一個服務(wù)，一個存儲解決所有問題。這種架構(gòu)看上去簡單、粗暴，好處是快速上線、快速響應(yīng)市場需求;但劣勢也非常明顯，APP直連服務(wù)器模式在擴(kuò)展的時候非常不靈活。項(xiàng)目上線后3個月，用戶數(shù)突破 100萬，訪問量上漲，服務(wù)器壓力增大。

• 2014年：垂直架構(gòu)

到了2014年，荔枝APP的后臺架構(gòu)演進(jìn)到V2.0版。這一版架構(gòu)的特點(diǎn)是：支持水平擴(kuò)展和功能拆分。首先，APP 與 app server 之間加入app代理層，用于分發(fā)請求給多臺 app server，分?jǐn)倝毫ΑＦ浯?#xff0c;對app server 按功能進(jìn)行拆分，數(shù)據(jù)操作及業(yè)務(wù)邏輯部分由后端服務(wù)負(fù)責(zé)，并采用 netty(http) + json 方式進(jìn)行交互。

雖然，這個時候已經(jīng)能做到相對快速交互，但是依然存在很多問題。一個是，后端服務(wù)水平擴(kuò)展時，不能動態(tài)化;另外，系統(tǒng)間采用 http 交互時，通訊效率較低，并且數(shù)據(jù)包較大;還有一個問題是，json 解析速度較慢、體積較大。所以，V3.0版采取了一系列措施，重點(diǎn)解決擴(kuò)展、交互等問題。比如：引入Linux虛擬服務(wù)器集群系統(tǒng) LVS，采用 TCP 取代 HTTP，通過定制私有協(xié)議取代json。

V3.0版使用 LVS 集群解決了分發(fā)請求，但是隨著業(yè)務(wù)的快速發(fā)展，人力資源都投入在業(yè)務(wù)開發(fā)上，對第三方產(chǎn)品了解也不夠深入，導(dǎo)致運(yùn)維成了最大挑戰(zhàn)。所以，后期考慮采用自己開發(fā)代理服務(wù)來取代 LVS。

V4.0版架構(gòu)中，我們開發(fā)了代理服務(wù)，當(dāng)時使用 VIP 與其他服務(wù)連接，取代LVS分發(fā)請求。這時候的整體架構(gòu)依然比較簡單，app server 與后端服務(wù)還是單體架構(gòu)，沒有做業(yè)務(wù)拆分，雖然能讓后端服務(wù)支持水平擴(kuò)展功能，但需要重啟代理服務(wù)。另外，還有一個挑戰(zhàn)是，隨著用戶量、訪問量的持續(xù)上漲，系統(tǒng)訪問壓力依然很大。接下來的目標(biāo)是，app server 與后端服務(wù)需要按業(yè)務(wù)垂直拆分。

演化到V5.0版架構(gòu)的時候，所有服務(wù)已經(jīng)能夠按業(yè)務(wù)拆分，可支持水平擴(kuò)展，整體架構(gòu)能抗得住一定的訪問壓力。2014年10月，用戶量曾突破 1千萬。但新的問題又來了：一個是服務(wù)的配置不能做到熱更;另外，不同業(yè)務(wù)的后端服務(wù)之間產(chǎn)生了交互需求。還有，微服務(wù)化已成為主流發(fā)展方向。所以，下一個階段的解決方案是，開發(fā)配置中心 config server實(shí)現(xiàn)配置熱更;采用開發(fā)分布式服務(wù)框架 lz-RPC，封裝遠(yuǎn)程調(diào)用功能。

• 2015年：分布式架構(gòu)

V6.0版架構(gòu)開啟了分布式架構(gòu)新征程，這時候的特點(diǎn)是app server、后端服務(wù)、代理層等，都實(shí)現(xiàn)了配置熱更，能靈活水平擴(kuò)展。到2015年9月，用戶量曾突破 5千萬。但是面臨的問題依然很多。比如：mysql、redis 操作的重復(fù)代碼太多;mysql、redis 慢操作不能及時報警;各個服務(wù)的數(shù)據(jù)源配置分散，難以管理等。另外，還涉及跨機(jī)房數(shù)據(jù)操作和數(shù)據(jù)同步問題。而分布式數(shù)據(jù)庫中間件可以很好地解決這些問題。

• 2016年：分布式數(shù)據(jù)庫中間件

從2016年開始，荔枝APP的后臺架構(gòu)走入V7.0版時代。這時，開發(fā)團(tuán)隊自研了分布式數(shù)據(jù)庫中間件data store服務(wù)。data store的特點(diǎn)是：簡單易用，可減少重復(fù)代碼。只需要在類上加上注解，就可以實(shí)現(xiàn)與數(shù)據(jù)庫的交互、數(shù)據(jù)轉(zhuǎn)換等功能，大大減少了開發(fā)的工作量。另外，data store具有自動維護(hù)緩存和數(shù)據(jù)庫表的對應(yīng)關(guān)系、自動維護(hù)緩存與數(shù)據(jù)庫數(shù)據(jù)的一致性的功能。最重要的是，屏蔽了服務(wù)對數(shù)據(jù)源的管理，便于數(shù)據(jù)庫的遷移和擴(kuò)容等操作。

總體來看，V7.0版的最大特點(diǎn)是，已形成一個比較完整的分布式架構(gòu)。data store 封裝了常見的 mysql、redis 操作，能提供慢操作監(jiān)控。后期根據(jù)業(yè)務(wù)發(fā)展，還引入了 kafka、mongoDB、zookeeper、hbase等多種第三方產(chǎn)品。

隨著應(yīng)用的增加，V7.0版架構(gòu)也逐漸暴露出了一些缺陷。一是資源監(jiān)控、業(yè)務(wù)監(jiān)控、分布式跟蹤鏈等功能不完善。另外，隨著訪問量上漲，分布式服務(wù)框架的功能也需要進(jìn)行擴(kuò)展。

• ??2017-2018年：監(jiān)控體系

進(jìn)入2017年以后，整個架構(gòu)已趨于完善，重點(diǎn)引入第三方產(chǎn)品，建立監(jiān)控體系，完善對服務(wù)器資源、業(yè)務(wù)、跟蹤鏈路等的監(jiān)控，同時也擴(kuò)展了分布式服務(wù)框架功能。也是從這個時候開始，整個架構(gòu)迎來了V8.0版。經(jīng)過完善后，業(yè)務(wù)監(jiān)控及基礎(chǔ)監(jiān)控功能已比較完整，分布式服務(wù)框架擴(kuò)展了接口緩存、熔斷、降級、過載保護(hù)等功能。

?

近兩年踩過的“坑”以及應(yīng)對措施

?

1、大主播開直播，訪問量爆漲，影響了其他直播間的直播效果，比如出現(xiàn)卡頓、進(jìn)入不了直播間、接口超時。舉個例子：李易峰晚上8點(diǎn)在荔枝APP上做直播，那么從8點(diǎn)前開始，整個系統(tǒng)的訪問量就會比平時要高出很多。有用戶就會出現(xiàn)進(jìn)入直播間慢、評論出現(xiàn)慢以及其他體驗(yàn)不好的情況出現(xiàn)。像這樣的問題，應(yīng)該如何解決呢?

第一個方案，也是最簡單的方法，是“隔離”。在 data store 中，針對 redis 存儲開發(fā)，按前綴分片的功能，對大主播的直播數(shù)據(jù)進(jìn)行隔離，避免影響其他主播的直播效果。

第二個方案是，在高訪問量期間，結(jié)合分布式服務(wù)框架中開發(fā)的熔斷、降級、過載保護(hù)等功能，采取對部分非關(guān)鍵服務(wù)做降級措施，避免服務(wù)器因訪問量過高發(fā)生雪崩。

2、在高并發(fā)環(huán)境下，Mysql 查詢性能成為瓶頸。當(dāng)數(shù)據(jù)量呈現(xiàn)爆發(fā)式增長，Mysql 查詢速度變慢。我們對分布式數(shù)據(jù)庫中間件作了擴(kuò)展，在操作mysql時，在數(shù)據(jù)庫上層加入緩存memcached后，大大提高了查詢性能,并且自動維護(hù)緩存和數(shù)據(jù)庫數(shù)據(jù)的一致性。

3、訪問量上漲，受日志文件的IO影響，服務(wù)出現(xiàn)長GC(stop the world，阻塞業(yè)務(wù)線程)。類似服務(wù)出現(xiàn)長GC的問題，很多互聯(lián)網(wǎng)公司都會遇到。在GC的整個回收過程中，會有兩個步驟涉及到IO操作。第一個操作就是寫 perf 文件;第二個是寫 gc log的時候。一臺服務(wù)器一般會部署多個服務(wù)，這些服務(wù)在運(yùn)行的過程中，會不斷輸出日志，這時容易出現(xiàn)與其他服務(wù)的GC線程發(fā)生搶占IO資源的沖突，而導(dǎo)致GC線程阻塞等待，最終導(dǎo)致整個GC過程耗時較長，影響了服務(wù)的響應(yīng)和穩(wěn)定。為了解決這些問題，采取了兩個方案來解決：第一，不生成 perf 文件，在服務(wù)啟動腳本里，加上參數(shù) -XX:+PerfDisableSharedMem就可以了;第二，將 GC日志保存到內(nèi)存盤中( tmpfs 或 ramfs )，在服務(wù)啟動腳本里加上 -Xloggc:/dev/shm/lz-app-gc.log參數(shù)就可以解決了。

4、隨著業(yè)務(wù)的發(fā)展，系統(tǒng)的整體訪問量越來越大，后端服務(wù)接口調(diào)用耗時越來越長，導(dǎo)致經(jīng)常超時。經(jīng)過分析和統(tǒng)計發(fā)現(xiàn)，整個平臺實(shí)際上以“讀多寫少”的場景居多。有沒有一個兼顧全局的解決方案呢?在分布式服務(wù)框架中開發(fā)“緩存接口”功能，解決了這個問題。其實(shí)有很多場景，我們是不需要實(shí)時看到最新數(shù)據(jù)的，即使新數(shù)據(jù)晚了30秒或者1分鐘用戶才看到，也是可以接受的。

5、系統(tǒng)間異步消息通知功能不完善。之前，是通過redis來做異步消息通知，好處是比較輕量化，但是隨著數(shù)據(jù)量增加，大數(shù)據(jù)傳輸增多，出現(xiàn)多個消費(fèi)方需要消費(fèi)相同消息的時候，redis 就不是很適用了。這時，使用 kafka可以滿足系統(tǒng)間消息通知、大數(shù)據(jù)量傳輸、多個消費(fèi)者消費(fèi)相同消息的場景。

6、當(dāng)服務(wù)框架中的各種功能都比較完善后，卻發(fā)現(xiàn)缺少一個報警功能。比如在請求失敗/超時/異常等，如果有監(jiān)控機(jī)制，就可以找到具體的問題點(diǎn)。借助監(jiān)控系統(tǒng)，我們可以看到服務(wù)器負(fù)載、物理內(nèi)存、swap、磁盤等信息，也能監(jiān)控到GC信息的回收時間、次數(shù)以及JVM堆信息等，還可以對異常請求進(jìn)行統(tǒng)計。

7、隨著服務(wù)的增多，每個服務(wù)都有很多實(shí)例，導(dǎo)致整個架構(gòu)的調(diào)用鏈路不清晰，也不能預(yù)知整體架構(gòu)存在的瓶頸。引入skywalking 實(shí)現(xiàn)調(diào)用鏈跟蹤功能后，能快速定位到線上故障和整個架構(gòu)的性能瓶頸。

8、主要是更新服務(wù)的問題，上線/重啟服務(wù)操作很原始，之前都是人工在本地打包，再上傳到服務(wù)器。服務(wù)不多的時候還能支撐，但是服務(wù)實(shí)例數(shù)量開始增多的情況下，這種方式就需要改進(jìn)。荔枝的做法是開發(fā)一個自動發(fā)布平臺，一鍵式操作。另外，就是通過jenkins + gitlab，接入自動發(fā)布平臺，實(shí)現(xiàn)自動打包、一鍵發(fā)布。

9、服務(wù)發(fā)布流程不夠規(guī)范。過去的部署流程很簡單，先是在本地測試，測試通過后，打包部署到線上，再觀察服務(wù)的運(yùn)行日志。但是隨著團(tuán)隊人員和系統(tǒng)越來越多后，這種做法是不合適的。要想保證整個業(yè)務(wù)順利上線，必須把服務(wù)發(fā)布流程規(guī)范化。從預(yù)發(fā)布測試到影響評估，到回滾步驟，再到灰度發(fā)布、線上驗(yàn)證，每一個環(huán)節(jié)都要標(biāo)準(zhǔn)化。預(yù)發(fā)布測試包含業(yè)務(wù)流程測試、新功能測試、SQL 驗(yàn)證、代碼審查;影響評估包含對業(yè)務(wù)系統(tǒng)的影響和對交互系統(tǒng)的影響;回滾方案包含回滾步驟和回滾版本號，灰度發(fā)布則要按照按流量百分比、按設(shè)備類型和按 app 版本號等來操作;線上驗(yàn)證要做功能回歸測試，以及觀察異常日志、報警信息等。

10、研發(fā)規(guī)范不夠標(biāo)準(zhǔn)。一個技術(shù)團(tuán)隊從10幾個人發(fā)展到幾百人甚至上千人的時候，規(guī)范很重要。為了提高效率，公司制定了各種標(biāo)準(zhǔn)的開發(fā)/操作規(guī)范，包括客戶端開發(fā)規(guī)范、服務(wù)端開發(fā)規(guī)范、測試規(guī)范、運(yùn)維規(guī)范、mysql、redis、kafka、mongoDB 等的使用規(guī)范。

未來對整個架構(gòu)會有多個優(yōu)化的目標(biāo)，例如通過“微服務(wù)+容器化”實(shí)現(xiàn)服務(wù)實(shí)例的動態(tài)擴(kuò)容與縮容、Service Mesh架構(gòu)改造、業(yè)務(wù)級別的調(diào)用鏈跟蹤功能等等。

最后，引用大家常說的一句話：好的系統(tǒng)不是設(shè)計出來的，而是演進(jìn)出來的。未來，荔枝的系統(tǒng)架構(gòu)會更加完善，在不斷探索中更加精進(jìn)。

參考：https://mp.weixin.qq.com/s?__biz=MzA5MDc1ODQxMw==&mid=2653325500&idx=1&sn=efa02d6e6010f6e1a942e949d13cd075&chksm=8bd4e4debca36dc82e8bf757f829747a128c428f4c62c87388d8f17887519075dd957d727045&scene=21#wechat_redirect

?

轉(zhuǎn)載于:https://www.cnblogs.com/w-honey/p/11111164.html

總結(jié)

以上是生活随笔為你收集整理的《荔枝架构实践与演进历程》阅读有感的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。