產(chǎn)品是一款服務于人力資源的SaaS在線服務,面向HR有Web Android/iOS 小程序多個客戶端
后端采用RESTful風格API來提供服務。主要使用Python語言,方便快速迭代。
架構的演進經(jīng)歷了4個大的階段:
項目剛開始的時候,后端同事不超過5個,這個階段主要的工作是實現(xiàn)產(chǎn)品的原型,沒有太多的考慮架構
使用Django來快速實現(xiàn)功能,DB的表結構設計好之后,抽象出功能View
由于產(chǎn)品設計也很不完善,后端需要很多的預留設計,避免產(chǎn)品邏輯的變更帶來整個表結構的變動
在這個階段代碼上最重要的是確定適合團隊的代碼規(guī)范,代碼檢查規(guī)則。
整體上架構如上圖
問題與優(yōu)化方式:
隨著開發(fā)的功能越來越多,Django下的app也越來越多,這就帶了發(fā)布上的不方便,每次發(fā)布版本都需要重啟所有的Django服務,如果發(fā)布遇到問題,只能加班解決了。而且單個Django工程下的代碼量也越來越多,不好維護。
隨著后端團隊的壯大,分給每個同事的需求也越來越細
如果繼續(xù)在一個工程里面開發(fā)所有的代碼,維護起來的代價太高
而我們的上一個架構中在Django里面已經(jīng)按模塊劃分了一個個app
app內(nèi)高類聚,app之間低耦合,這就為服務的拆分帶來了便利。
拆分的過程沒有遇到太大的問題,初期的拆分只是代碼的分離
把公用的代碼抽離出來實現(xiàn)一個公用的Python庫,數(shù)據(jù)庫,Redis還是共用,隨著負載的增加,數(shù)據(jù)庫也做了多實例。
如上圖,服務之間盡量避免相互調(diào)用,需要交互的地方采用http請求的方式,內(nèi)網(wǎng)的調(diào)用使用hosts指向內(nèi)網(wǎng)地址。
問題與優(yōu)化方式:
為了解決相互調(diào)用的問題,維護了一個基于gevent+msgpack的RPC服務框架doge,借助于etcd做服務治理,并在rpc客戶端實現(xiàn)了限流,高可用,負載均衡這些功能。
餓了么維護一個純Python實現(xiàn)的thrift協(xié)議框架thriftpy,并提供很多配套的工具, 如果團隊足夠大,這一套RPC方案其實是合適的,但是我們的團隊人手不足,水平參差不齊,很難推廣這一整套學習成本高昂的方案。
最終我們開發(fā)了類Duboo的RPC框架doge,代碼主要參考了weibo開源的motan。
在我離職時領域驅(qū)動設計還在學習設計階段,還沒有落地,但是我相信前公司的后端架構一定會往這個方向繼續(xù)演進。
Service Mesh這種新一代的微服務架構正在成為主流,雖然現(xiàn)在的工作與微服務無關了,但是也還會繼續(xù)關注學習。
架構的設計,技術的選型,不能完全按照流行的技術走,最終還是服務于產(chǎn)品,服務于客戶的需求。設計過程中由于團隊,人員的結構問題,有很多的妥協(xié)之處,如何在妥協(xié)中找到最優(yōu)解才是最大的挑戰(zhàn),更多相關問題的討論,請大家持續(xù)關注腳本之家!
標簽:雙鴨山 鄂爾多斯 莆田 錫林郭勒盟 丹東 哈爾濱 遵義 襄陽
巨人網(wǎng)絡通訊聲明:本文標題《從0到1搭建后端架構的演進(MVC,服務拆分,微服務,領域驅(qū)動)》,本文關鍵詞 從,到,搭建,后端,架構,的,;如發(fā)現(xiàn)本文內(nèi)容存在版權問題,煩請?zhí)峁┫嚓P信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡,涉及言論、版權與本站無關。