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

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

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

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

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

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

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

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

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

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

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

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

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

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

總體來(lái)看，V7.0版的最大特點(diǎn)是，已形成一個(gè)比較完整的分布式架構(gòu)。data store 封裝了常見(jiàn)的 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)控、分布式跟蹤鏈等功能不完善。另外，隨著訪(fǎng)問(wèn)量上漲，分布式服務(wù)框架的功能也需要進(jìn)行擴(kuò)展。

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

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

?

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

最后，引用大家常說(shuō)的一句話(huà)：好的系統(tǒng)不是設(shè)計(jì)出來(lái)的，而是演進(jìn)出來(lái)的。未來(lái)，荔枝的系統(tǒng)架構(gòu)會(huì)更加完善，在不斷探索中更加精進(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é)

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

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