架構(gòu)的演進(jìn)經(jīng)歷了4個大的階段:1.MVC2.服務(wù)拆分3.微服務(wù)架構(gòu)4.領(lǐng)域驅(qū)動設(shè)計.

1.MVC

項目剛開始的時候,后端同事不超過5個,這個階段主要的工作是實現(xiàn)產(chǎn)品的原型,沒有太多的考慮架構(gòu),使用Django來快速實現(xiàn)功能,DB的表結(jié)構(gòu)設(shè)計好之后,抽象出功能View,由于產(chǎn)品設(shè)計也很不完善,后端需要很多的預(yù)留設(shè)計,避免產(chǎn)品邏輯的變更帶來整個表結(jié)構(gòu)的變動,在這個階段代碼上最重要的是確定適合團隊的代碼規(guī)范,代碼檢查規(guī)則.

整體上架構(gòu)如上圖,Nginx負(fù)責(zé)負(fù)載均衡,分發(fā)流量到多個Django服務(wù),Django處理邏輯,需要異步任務(wù)就交給Celery,然后數(shù)據(jù)量比較大的地方使用Redis做緩存.同時還有實時消息通知的需要使用了NginxPushModule.

問題與優(yōu)化方式:

Django并發(fā)性能差使用uWSGIMaster+Worker配合gevent攜程支持高并發(fā)

Redis連接數(shù)過多使用redis-py自帶的連接池來實現(xiàn)連接復(fù)用

MySQL連接數(shù)過多使用djorm-ext-pool連接池復(fù)用連接

Celery配置gevent支持并發(fā)任務(wù)

隨著開發(fā)的功能越來越多,Django下的app也越來越多,這就帶了發(fā)布上的不方便,每次發(fā)布版本都需要重啟所有的Django服務(wù),如果發(fā)布遇到問題,只能加班解決了.而且單個Django工程下的代碼量也越來越多,不好維護(hù).

2.服務(wù)拆分

隨著后端團隊的壯大,分給每個同事的需求也越來越細(xì),如果繼續(xù)在一個工程里面開發(fā)所有的代碼,維護(hù)起來的代價太高,而我們的上一個架構(gòu)中在Django里面已經(jīng)按模塊劃分了一個個app,app內(nèi)高類聚,app之間低耦合,這就為服務(wù)的拆分帶來了便利.拆分的過程沒有遇到太大的問題,初期的拆分只是代碼的分離,把公用的代碼抽離出來實現(xiàn)一個公用的Python庫,數(shù)據(jù)庫,Redis還是共用,隨著負(fù)載的增加,數(shù)據(jù)庫也做了多實例.

如上圖,服務(wù)之間盡量避免相互調(diào)用,需要交互的地方采用http請求的方式,內(nèi)網(wǎng)的調(diào)用使用hosts指向內(nèi)網(wǎng)地址.

問題與優(yōu)化方式:

NginxPushModule由于長時間沒有維護(hù),長連接最大數(shù)量不夠,使用Tornado+ZeroMQ實現(xiàn)了tormq服務(wù)來支撐消息通知

服務(wù)之間的調(diào)用采用http的方式,并且要求有依賴的服務(wù)主機配置hosts指向被調(diào)用的地址,這樣帶來的維護(hù)上的不方便.以及在調(diào)用鏈的過程中沒有重試,錯誤處理,限流等等的策略,導(dǎo)致服務(wù)可用性差.隨著業(yè)務(wù)拆分,繼續(xù)使用Nginx維護(hù)配置非常麻煩,經(jīng)常因為修改Nginx的配置引發(fā)調(diào)用錯誤.每一個服務(wù)都有一個完整的認(rèn)證過程,認(rèn)證又依賴于用戶中心的數(shù)據(jù)庫,修改認(rèn)證時需要重新發(fā)布多個服務(wù).

3.微服務(wù)架構(gòu)

首先是在接入層引入了基于OpenResty的KongAPIGateway,定制實現(xiàn)了認(rèn)證,限流等插件.在接入層承接并剝離了應(yīng)用層公共的認(rèn)證,限流等功能.在發(fā)布新的服務(wù)時,發(fā)布腳本中調(diào)用Kongadminapi注冊服務(wù)地址到Kong,并加載api需要使用插件.

為了解決相互調(diào)用的問題,維護(hù)了一個基于gevent+msgpack的RPC服務(wù)框架doge,借助于etcd做服務(wù)治理,并在rpc客戶端實現(xiàn)了限流,高可用,負(fù)載均衡這些功能.

在這個階段最難的技術(shù)選型,開源的API網(wǎng)關(guān)大多用Golang與OpenResty(lua)實現(xiàn),為了應(yīng)對我們業(yè)務(wù)的需要還要做定制.前期花了1個月時間學(xué)習(xí)OpenResty與Golang,并使用OpenResty實現(xiàn)了一個短網(wǎng)址服務(wù)shorturl用在業(yè)務(wù)中.最終選擇Kong是基于Lua發(fā)布的便利性,Kong的開箱即用以及插件開發(fā)比較容易.性能的考量倒不是最重要的,為了支撐更多的并發(fā),還使用了云平臺提供的LB服務(wù)分發(fā)流量到2臺Kong服務(wù)器組成的集群.集群之間自動同步配置.

餓了么維護(hù)一個純Python實現(xiàn)的thrift協(xié)議框架thriftpy,并提供很多配套的工具,如果團隊足夠大,這一套RPC方案其實是合適的,但是我們的團隊人手不足,水平參差不齊,很難推廣這一整套學(xué)習(xí)成本高昂的方案.最終我們開發(fā)了類Duboo的RPC框架doge,代碼主要參考了weibo開源的motan.

4.領(lǐng)域驅(qū)動設(shè)計

在這一架構(gòu)中我們嘗試從應(yīng)用服務(wù)中抽離出數(shù)據(jù)服務(wù)層,每一個數(shù)據(jù)服務(wù)包含一個或多個界限上下文,界限上下文類只有一個聚合根來暴露出RPC調(diào)用的方法.數(shù)據(jù)服務(wù)不依賴于應(yīng)用服務(wù),應(yīng)用服務(wù)可以依賴多個數(shù)據(jù)服務(wù).有了數(shù)據(jù)服務(wù)層,應(yīng)用就解耦了相互之間的依賴,高層服務(wù)只依賴于底層服務(wù).

在我離職時領(lǐng)域驅(qū)動設(shè)計還在學(xué)習(xí)設(shè)計階段,還沒有落地,但是我相信前公司的后端架構(gòu)一定會往這個方向繼續(xù)演進(jìn).

總結(jié)

架構(gòu)的設(shè)計,技術(shù)的選型,不能完全按照流行的技術(shù)走,最終還是服務(wù)于產(chǎn)品,服務(wù)于客戶的需求.設(shè)計過程中由于團隊,人員的結(jié)構(gòu)問題,有很多的妥協(xié)之處,如何在妥協(xié)中找到最優(yōu)解才是最大的挑戰(zhàn).

以上內(nèi)容為大家介紹了Python的后端架構(gòu)演進(jìn)過程，希望對大家有所幫助，如果想要了解更多Python相關(guān)知識，請關(guān)注IT培訓(xùn)機構(gòu):千鋒教育。http://www.kei0345678.cn/