主頁 > 知識庫 > 從0到1搭建后端架構的演進(MVC,服務拆分,微服務,領域驅(qū)動)

從0到1搭建后端架構的演進(MVC,服務拆分,微服務,領域驅(qū)動)

熱門標簽:宿遷怎么辦理400電話 400電話辦理費用低 谷歌地圖標注日期 聯(lián)通外呼系統(tǒng)電腦app軟件 鶴壁高頻外呼系統(tǒng)多少錢一個月 外呼系統(tǒng)怎么群發(fā)短信 地圖標注項目幾個月 蘇州呼叫中心外呼系統(tǒng)哪家強 400電話申請到底哪家好

產(chǎn)品是一款服務于人力資源的SaaS在線服務,面向HR有Web Android/iOS 小程序多個客戶端

后端采用RESTful風格API來提供服務。主要使用Python語言,方便快速迭代。

架構的演進經(jīng)歷了4個大的階段:

一、MVC

項目剛開始的時候,后端同事不超過5個,這個階段主要的工作是實現(xiàn)產(chǎn)品的原型,沒有太多的考慮架構

使用Django來快速實現(xiàn)功能,DB的表結構設計好之后,抽象出功能View

由于產(chǎn)品設計也很不完善,后端需要很多的預留設計,避免產(chǎn)品邏輯的變更帶來整個表結構的變動

在這個階段代碼上最重要的是確定適合團隊的代碼規(guī)范,代碼檢查規(guī)則。

整體上架構如上圖

  • Nginx負責負載均衡,分發(fā)流量到多個Django服務
  • Django處理邏輯
  • 異步任務就交給Celery
  • 數(shù)據(jù)量比較大的地方使用Redis做緩存
  • 同時還有實時消息通知的需要使用了Nginx Push Module

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

  • Django并發(fā)性能差
  • 使用uWSGI Master+Worker 配合 gevent 攜程支持高并發(fā)Redis連接數(shù)過多
  • 使用redis-py自帶的連接池來實現(xiàn)連接復用MySQL連接數(shù)過多
  • 使用djorm-ext-pool(https://github.com/djangonauts/djorm-ext-pool)連接池復用連接Celery配置gevent支持并發(fā)任務

隨著開發(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)化方式:

  • Nginx Push Module由于長時間沒有維護,長連接最大數(shù)量不夠,
  • 使用Tornado + ZeroMQ實現(xiàn)了tormq(https://github.com/zhu327/tormq)服務來支撐消息通知
  • 服務之間的調(diào)用采用http的方式,并且要求有依賴的服務主機配置hosts指向被調(diào)用的地址,這樣帶來的維護上的不方便。
  • 以及在調(diào)用鏈的過程中沒有重試,錯誤處理,限流等等的策略,導致服務可用性差。
  • 隨著業(yè)務拆分,繼續(xù)使用Nginx維護配置非常麻煩,經(jīng)常因為修改Nginx的配置引發(fā)調(diào)用錯誤。
  • 每一個服務都有一個完整的認證過程,認證又依賴于用戶中心的數(shù)據(jù)庫,修改認證時需要重新發(fā)布多個服務。

三、微服務架構

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

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

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

餓了么維護一個純Python實現(xiàn)的thrift協(xié)議框架thriftpy,并提供很多配套的工具, 如果團隊足夠大,這一套RPC方案其實是合適的,但是我們的團隊人手不足,水平參差不齊,很難推廣這一整套學習成本高昂的方案。

最終我們開發(fā)了類Duboo的RPC框架doge,代碼主要參考了weibo開源的motan。

四、領域驅(qū)動設計

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

在我離職時領域驅(qū)動設計還在學習設計階段,還沒有落地,但是我相信前公司的后端架構一定會往這個方向繼續(xù)演進。

Service Mesh這種新一代的微服務架構正在成為主流,雖然現(xiàn)在的工作與微服務無關了,但是也還會繼續(xù)關注學習。

架構的設計,技術的選型,不能完全按照流行的技術走,最終還是服務于產(chǎn)品,服務于客戶的需求。設計過程中由于團隊,人員的結構問題,有很多的妥協(xié)之處,如何在妥協(xié)中找到最優(yōu)解才是最大的挑戰(zhàn),更多相關問題的討論,請大家持續(xù)關注腳本之家!

您可能感興趣的文章:
  • 解讀Serverless架構的前世今生
  • SSM框架前后端信息交互實現(xiàn)流程詳解
  • 適合后臺管理系統(tǒng)開發(fā)的12個前端框架(小結)
  • 詳解Java 微服務架構
  • 淺談SpringCloud實現(xiàn)簡單的微服務架構

標簽:雙鴨山 鄂爾多斯 莆田 錫林郭勒盟 丹東 哈爾濱 遵義 襄陽

巨人網(wǎng)絡通訊聲明:本文標題《從0到1搭建后端架構的演進(MVC,服務拆分,微服務,領域驅(qū)動)》,本文關鍵詞  從,到,搭建,后端,架構,的,;如發(fā)現(xiàn)本文內(nèi)容存在版權問題,煩請?zhí)峁┫嚓P信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡,涉及言論、版權與本站無關。
  • 相關文章
  • 下面列出與本文章《從0到1搭建后端架構的演進(MVC,服務拆分,微服務,領域驅(qū)動)》相關的同類信息!
  • 本頁收集關于從0到1搭建后端架構的演進(MVC,服務拆分,微服務,領域驅(qū)動)的相關信息資訊供網(wǎng)民參考!
  • 企业400电话

    智能AI客服机器人
    15000

    在线订购

    合计11份范本:公司章程+合伙协议+出资协议+合作协议+股权转让协议+增资扩股协议+股权激励+股东会决议+董事会决议

    推薦文章