作者 | 金色旭光

在過去的一個半月里我第一次作為后端開發(fā)組長角色參與公司項(xiàng)目從0到1的開發(fā)，記錄這一次開發(fā)的經(jīng)歷。

1、背景介紹

首先說明一下背景。我所在的公司是做智慧社區(qū)相關(guān)業(yè)務(wù)，開發(fā)的項(xiàng)目是系統(tǒng)升級工具，方便公司實(shí)施同事安裝和升級系統(tǒng)。

參與后端開發(fā)一共四個人，包括我在內(nèi)。其他三個同事有一個是應(yīng)屆生、兩個做大數(shù)據(jù)的。按照公司的技術(shù)規(guī)劃，對內(nèi)項(xiàng)目開發(fā)節(jié)奏要短平快，用Python語言完成，對外的項(xiàng)目一律用Java語言完成。

項(xiàng)目經(jīng)過正常開發(fā)生命周期，包括需求采集、產(chǎn)品設(shè)計(jì)、系統(tǒng)設(shè)計(jì)、詳細(xì)設(shè)計(jì)、編碼、測試等過程。其中詳細(xì)設(shè)計(jì)就是針對接口做的詳細(xì)設(shè)計(jì)，一共用時3天完成，設(shè)計(jì)了45個功能點(diǎn)，包括40個接口和5個初始化準(zhǔn)備工作。編碼用時計(jì)劃為3周。最終在時間點(diǎn)之內(nèi)完成了相關(guān)的開發(fā)。

我在這次開發(fā)過程中擔(dān)任的是組長的角色，主要的任務(wù)包括：

（1）項(xiàng)目框架的搭建。本次開發(fā)是一個從0到1的過程，在此之前并沒有Python項(xiàng)目的框架。

（2）關(guān)鍵技術(shù)的實(shí)現(xiàn)。包括通用接口，復(fù)雜的技術(shù)點(diǎn)。

（3）任務(wù)分配。所有接口根據(jù)任務(wù)量分配給指定的成員，完成最多的接口開發(fā)。

2、項(xiàng)目框架搭建

Python做web開發(fā)常用的項(xiàng)目框架其實(shí)并不是很多，我的候選項(xiàng)有三個：

Django 前后端不分離框架、Flask 最容易上手的框架、FastAPI 異步高性能框架。

對比這三個框架，我從業(yè)務(wù)邏輯、公司技術(shù)棧、復(fù)雜度等三個角度出發(fā)，選擇了Flask。

業(yè)務(wù)邏輯

業(yè)務(wù)邏輯對性能并沒有特別要求，就是通過接口調(diào)用運(yùn)維的ansible腳本，沒有高并發(fā)，計(jì)算密集等任務(wù)，所以三個都能滿足。

技術(shù)棧

公司技術(shù)棧是前后端分離，所以Django這種前后端不分離的框架并不適合，雖然Django也可以做純后端開發(fā)（防杠）。

復(fù)雜程度

復(fù)雜度來說肯定是Flask最簡單。Django號稱大而全，配置復(fù)雜。FastAPI是異步框架，需要學(xué)習(xí)異步編程，雖然用來做同步框架也很絲滑，但是學(xué)習(xí)成本需要增加很多。其他三個同事都沒有做過Python項(xiàng)目，所以盡量減少學(xué)習(xí)成本。

經(jīng)過這三個方向的衡量，最終確定了Flask框架，搭配peewee orm數(shù)據(jù)庫框架。核心的技術(shù)包括：

（1）web框架 Flask

（2）數(shù)據(jù)庫ORM框架 peewee

（3）數(shù)據(jù)庫 sqlite

（4）運(yùn)維腳本執(zhí)行模塊 subprocess

（5）WSGI服務(wù) Gunicorn

（6）代碼檢查工具pre-commit

在編碼前我已經(jīng)準(zhǔn)備好完整的項(xiàng)目框架，寫好了數(shù)據(jù)庫CRUD接口的demo，后續(xù)開發(fā)過程同事模仿相關(guān)接口，一定程度上提高了開發(fā)效率。

3、關(guān)鍵技術(shù)實(shí)現(xiàn)

帶團(tuán)隊(duì)開發(fā)并且是帶領(lǐng)成員第一次做Python項(xiàng)目，自然要將有挑戰(zhàn)的任務(wù)安排給自己。在關(guān)鍵技術(shù)的實(shí)現(xiàn)上挑選三個有代表性的講解。三個分別是：系統(tǒng)命令執(zhí)行通用接口、流式日志、sqlite 多線程寫問題解決。

系統(tǒng)命令通用接口

項(xiàng)目主要用于公司開發(fā)的其他系統(tǒng)安裝和升級，因此需要調(diào)用運(yùn)維人員用ansible編寫的相關(guān)腳本。調(diào)用的ansible腳本格式如下：

ansible-playbook 03.mysql.yml
ansible-playbook 08.zk.yml

需要到指定的路徑下執(zhí)行如上的命令。在詳細(xì)設(shè)計(jì)階段就知道需要使用Python調(diào)用系統(tǒng)命令的工具，所以就讓應(yīng)屆生同事調(diào)研了subprocess模塊，輸出相關(guān)文檔。一來是給新人一個學(xué)習(xí)方向，再則借這個機(jī)會熟悉項(xiàng)目需要的技術(shù)。

在開發(fā)階段根據(jù)對相關(guān)模塊的理解，完成了通用接口的開發(fā)。寫通用接口切忌朝令夕改，依賴它的代碼也要隨之變化。一兩次還能接受，次數(shù)多估計(jì)要被問候祖宗了。所以該接口實(shí)現(xiàn)程度不僅僅是寫完，而且是自己親自調(diào)用，確認(rèn)沒有問題才宣告完成。

在沒有完成之前耐著性子調(diào)試，直到?jīng)]有任何問題才在群里告訴其他開發(fā)人員。整個系統(tǒng)中需要大量的調(diào)用該命令執(zhí)行腳本，最終也都比較順利的完成，沒有因?yàn)榻涌谠斐傻腷ug。

流式日志

按照產(chǎn)品的設(shè)計(jì)，當(dāng)一個組件在安裝時需要在web頁面上展示日志，并且日志的格式要和終端中安裝日志一樣，也就是一行一行的滾動打印。產(chǎn)品對日志的要求是全量滾動展示，刷新頁面要能夠再次全量展示出來。為了實(shí)現(xiàn)該功能，調(diào)研了三個方案：

一、定時刷新。缺點(diǎn)：日志有幾萬行，每一次讀取全部日志給前端，前端會卡頓，而且打印也不連續(xù)，體驗(yàn)不好。

二、websocket。可以完成后端向前端的主動推送，但是刷新頁面并不會從頭開始推送。

三、流式響應(yīng)。可以將大塊文件切分成小塊分批傳給前端，刷新頁面時會再次從頭開始推送，符合要求。

經(jīng)過對比最終使用了流式響應(yīng)，也就是ChatGPT那種響應(yīng)的方式。但是需要解決一個問題：什么時候結(jié)束推送？因?yàn)榘惭b一邊向文件中寫入日志，流式日志一邊讀出日志，如果日志已經(jīng)讀完了安裝還沒結(jié)束，那這個時候肯定需要等待而不是停止響應(yīng)。

解決辦法是在安裝完成之后插入標(biāo)記字符，當(dāng)流式日志讀取到標(biāo)記字符時就表明結(jié)束了，沒有讀取到標(biāo)記字符則等待。核心代碼如下：

def log_flow():
    query = request.values
    log_path = query["log_path"]

    def generate():
        with open(log_path, "r") as f:
            while True:
                chunk = f.read(800)
                if not chunk or chunk.isspace():
                    time.sleep(0.1)
                if chunk == 800 * "-":
                    break
                content = json.dumps({"content": chunk})
                yield f"event: message\ndata: {content}\n\n"
                time.sleep(0.05)

return Flask_response(generate(), mimetype="text/event-stream"

效果：

sqlite3 多線程寫問題

在數(shù)據(jù)庫存儲這一塊，領(lǐng)導(dǎo)欽定用sqlite3，咱也據(jù)理力爭過用MySQL，but無效。領(lǐng)導(dǎo)說該項(xiàng)目只需要一個輕量的數(shù)據(jù)庫即可，sqlite3輕量，所以就很合適。而且其他項(xiàng)目中已經(jīng)使用的非常成熟了。好吧，既然領(lǐng)導(dǎo)堅(jiān)持，我也只能硬著頭皮上了。

開始還沒問題，到了項(xiàng)目開發(fā)中后期就發(fā)現(xiàn)問題了，接口經(jīng)常報(bào)錯：

File "/home/ljk/.virtualenvs/idt_dev/lib/Python3.8/site-packages/peewee.py", line 3246, in execute_sql
cursor.execute(sql, params or ())
File "/home/ljk/.virtualenvs/idt_dev/lib/Python3.8/site-packages/peewee.py", line 3014, in __exit__
reraise(new_type, new_type(exc_value, *exc_args), traceback)
File "/home/ljk/.virtualenvs/idt_dev/lib/Python3.8/site-packages/peewee.py", line 192, in reraise
raise value.with_traceback(tb)
File "/home/ljk/.virtualenvs/idt_dev/lib/Python3.8/site-packages/peewee.py", line 3246, in execute_sql
cursor.execute(sql, params or ())
peewee.OperationalError: database is locked

查詢之后發(fā)現(xiàn)是sqlite3不支持多線程寫。sqlite3支持事務(wù)，是用庫鎖來完成的。當(dāng)一個寫入開始后，整個數(shù)據(jù)庫都加鎖了，再次有寫操作就會報(bào)錯。

這個問題首先從技術(shù)上是不好解決的，sqlite3的架構(gòu)設(shè)計(jì)就是如此，還能讓它支持多線程寫嗎？只能通過業(yè)務(wù)邏輯解決。經(jīng)過一次會議討論之后，得出幾個解決方法：

• 分庫。將寫操作分到不同的庫里完成。既然寫操作會鎖庫，那就分出不同的庫，就能避免鎖庫的問題。
• 全局寫隊(duì)列。將所有的寫放到一個消息隊(duì)列里面，將多線程的寫變成串行的寫。
• 全局寫標(biāo)識。所有的寫操作開始前判斷是否有可寫標(biāo)識，能寫入就寫入，否則接口返回，告訴前端數(shù)據(jù)庫繁忙。

經(jīng)過投票，大家一致決定用第三種方式實(shí)現(xiàn)，技術(shù)難度最小，代碼侵入性最少。因?yàn)榈谌N方案是我提出來的，所以最終由我來完成。具體的過程可參見另一篇文檔《peewee操作sqlite鎖表問題分析》。

最終是解決了該問題，雖然不是優(yōu)雅，但是在目前的時間成本和風(fēng)險(xiǎn)控制上局部是最優(yōu)解了。后續(xù)將調(diào)研peewee這個ORM框架提供的sqliteQueueDatabase實(shí)現(xiàn)寫隊(duì)列。

摘錄于peewee擴(kuò)展插件playhouse：

SqliteQueueDatabase可作為常規(guī)SqliteDatabase。如果你想簡單點(diǎn) read and write 從訪問sqlite數(shù)據(jù)庫多線程.

SQLite在任何給定的時間只允許一個連接寫入數(shù)據(jù)庫。因此，如果您有一個多線程應(yīng)用程序（例如Web服務(wù)器）需要寫入數(shù)據(jù)庫，當(dāng)一個或多個嘗試寫入的線程無法獲取鎖時，您可能會偶爾看到錯誤。

SqliteQueueDatabase 旨在通過一個長期存在的連接發(fā)送所有寫查詢，從而簡化操作。好處是，您可以看到多個線程在向數(shù)據(jù)庫寫入時沒有沖突或超時。但是，缺點(diǎn)是您不能發(fā)出包含多個查詢的寫事務(wù)——本質(zhì)上，所有寫操作都在自動提交模式下運(yùn)行。

4、個人感受

第一次帶團(tuán)隊(duì)開發(fā)，才明白很多事情。

做項(xiàng)目的主人公

第一真正理解什么叫主人公意識。各種文章都說要對項(xiàng)目有主人公意識才能成長更快。我感覺只有站在這樣一個位置上才能感受到這種意識。

項(xiàng)目進(jìn)度的第一責(zé)任人就是你，項(xiàng)目中出現(xiàn)了大大小小的問題都是找你。領(lǐng)導(dǎo)會問題項(xiàng)目進(jìn)度如何，有沒有阻塞，能不能按期完成？隊(duì)員會問這個校驗(yàn)框架是否ok？這個語法有沒有問題？測試會找你說這個bug該給誰的？所以你必須對這個項(xiàng)目了如指掌，小到代碼的一個配置項(xiàng)，大到工程進(jìn)度的把控。開發(fā)過程中有任何問題都得及時頂上，組長就是一塊磚，哪里需要哪里搬~

團(tuán)隊(duì)和諧

再說說團(tuán)隊(duì)的和諧。以前做一個小開發(fā)，只要完成自己的任務(wù)就可以了，團(tuán)隊(duì)的氛圍影響我寫代碼的速度嗎？帶團(tuán)隊(duì)開發(fā)就不一樣。團(tuán)隊(duì)中有各種特點(diǎn)的同事，有埋頭苦干不匯報(bào)進(jìn)度的、有能力強(qiáng)脾氣差的、有脾氣好進(jìn)度慢的。總之各種性格的人都會存在。

本次開發(fā)中就遇到了一個能力強(qiáng)脾氣差的，看到技術(shù)上小問題就直接群里開懟，誰不是熱血小青年？第一次遇到這種情況可想而知。領(lǐng)導(dǎo)不得不為此找我們談話一兩次，甚至驚動了大部門領(lǐng)導(dǎo)。那段時間團(tuán)隊(duì)氛圍特別差，沒有人說話。我也不敢多說什么，害怕氣氛更差，項(xiàng)目不能如期完成，到那個時候不是我的問題也變成我的問題了。所以只能選擇忍一忍，盡量回避分歧。好在領(lǐng)導(dǎo)的談話起到很大的作用，該安撫的安撫，該批評的批評，后來也沒有發(fā)生語言的沖突，順利按期完成項(xiàng)目。

總結(jié)

第一次帶團(tuán)隊(duì)做項(xiàng)目對我來說是一次挑戰(zhàn)和提高。從技術(shù)層面講讓我以后面對技術(shù)選型時能以更高的角度看待問題；從個人角度講這是一次難得的機(jī)會讓我負(fù)責(zé)開發(fā)團(tuán)隊(duì)，對接測試團(tuán)隊(duì)、前端團(tuán)隊(duì)、運(yùn)維團(tuán)隊(duì)等。這對我的溝通交流都是一次鍛煉。

最后，希望下一次做的更好，讓所有組員都能有一些進(jìn)步。