點選上方 "
Python人工智慧技術
"
關註，
星標或者置頂
22點24分準時推播，第一時間送達
後台回復「
大禮包
」，送你特別福利
編輯：樂樂 | 來自： 哇噠嘻哇
連結：https://www.zhihu.com/question/278798145/answer/3416549119
上一篇：
正文
大家好，我是Python人工智慧技術
最近幾年裏，經常看到某些曾重度使用 Python 的大公司遷移成其它語言技術棧，但是，那些小公司/小團隊的情況如何呢？
一直很想了解那些仍在堅持使用 Python，且支撐業務量有一定規模的公司是如何使用 Python 技術棧做開發的、會遇到哪些困難/教訓、有什麽樣的優秀經驗？
偶然在某乎上看到「 為什麽軟體公司很少用python開發web? 」問題下的回答，這裏分享給大家。
作者：哇噠嘻哇
（ https://www.zhihu.com/question/278798145/answer/3416549119）
回復：
我用 Python 有 10 多年了，現在維護最久的一個計畫每年有幾個億的交易額，是個電商平台，並行數不算大，平時有幾十的並行，過節會 100 出頭這樣，極限的時候我看也沒到 200 過，資料庫上最多的訂單表量總數在 5000 萬左右，每天增加幾萬。計畫有七八年了，還是用的 Python 2.7 + Django 1.8，沒打算升級了。
目前配備的 1 台 4 核 8G、3 台 8 核 16G 阿裏雲，資料庫和 Redis 也是用的阿裏雲，一年的費用大概 5 萬不到，CDN 用的七牛，每年大概也得幾萬。有包括我在內三個程式設計師在維護，基本每周都有新功能在增加，經過幾年的調整有效程式碼估計 70% 不到了，部份程式碼因為業務等原因沒在用了。
2021 年開發的另一套系統用的 Python 3.8 + Django 3，平時沒啥量，節日會飆上去，目前為止的最高記錄是一分鐘 350 單，一天 15 萬單，那天差不多交易額 1500 萬。平時配置的兩台 8 核 16G，節日會擴容單 6 台，資料庫等也會做臨時升級。有包括我在內四個程式設計師在維護。
另外小的計畫有幾個，沒怎麽做起來，也沒多少量，差不多是兩個人負責一個計畫，一個人同時負責兩個計畫這樣交叉著進行的。
目前整個公司後端的技術棧都是 Python + Django + Gunicorn 這樣（有個小計畫用的 tornado），公司基於 Django 做了一些基礎框架的積累，整個公司人也不多，大概十四五個程式設計師基本都對這套框架熟悉。新人來了也先一般是透過加強 Python 基礎 -> 學習 Django -> 學習公司框架 -> 進入計畫開發這樣的一個流程。
公司對命名、風格等方面要求多些，CR 的時候也關註的多些，熟悉之後大家基本都很默契了，因此 Python 動態語言的弊端沒怎麽體現出來。
早期沒經驗也出現過並行稍微上來點就崩的情況，後面對資料庫進行了升級（早期是自建的）又做了些 Redis 的緩存，現在發生的情況就少了很多了。
Django 構造的一些查詢語言過於復雜或者沒考慮最佳化，或導致出現一些慢查詢，現在解決的辦法是定期的關註慢日誌，尋找出現的程式碼去做最佳化，資料庫本身也需要做根據業務進行升級。這點其實換任何語言都一樣。
大部份程式語言我都有接觸過，但唯獨覺得 Python 能夠讓我像母語一樣能夠很方便的表達我的意思給電腦。
對於 Python，從我自身的感覺來講是熟悉之後程式設計師就只需要理解業務把需求轉換成程式碼，不需要在一些技術上花費過多的時間。Python 的庫也比較多，基本上遇到的大部份問題都有現成的東西可以使用。Django 的 ORM 也很贊，基本上讓程式設計師可以比較方便的操作到資料庫，不需要去管表結構變更、復雜查詢等。
要說缺點也有，比如 Python 比較累贅，尤其隨著計畫變大變復雜之後，啟動載入需要的時間越來越長，跑起來之後占用的記憶體也越來越大。
Django 的 ORM 帶來便利性的同時也帶來了一些低效的程式碼，比如經常看到的就是有些人構造了比較復雜的查詢，導致 join 的表太多了查詢時間太長，或者很多時候不管要不要的的欄位都一次性查出來了，以及 for 迴圈裏面大量的數據查詢等。
但我覺得這些缺點不算致命，因為相比人工開支和開發效率，增加雲伺服器的成本是極低的，況且對於效能而言大部份的計畫都到不了需要去最佳化的階段就黃了。有些規範或者使用方式可以透過培訓來進行提升，大部份人寫的程式碼品質都會逐步上來。
除了 Web 本身，我們有些硬體裝置（大部份是帶 Linux 的單板機，比如樹莓派、7688 等）上也會用 Python，好處就是可以在電腦上開發然後直接放到裝置上執行，也不需要專門招嵌入式工程師，基本上對硬體呼叫部份封裝之後就可以讓公司任何一個後端去開發了。
在一些圖片處理辨識、爬蟲、自動化測試、CICD 等方面我們也在用 Python。
對於小團隊來講，Python 的低門檻高效率比起所謂的效能損失型別難以捉摸有價值，當然，前提是需要建立規範、強調品質以及持續性的關註和最佳化。
想不到這個回答有這麽多人關註，我就再補充幾點吧。
上面提到的每分鐘 350 單的那套系統，主要做的事情是把幾個外賣平台的訂單聚合接入到系統，然後讓商家使用也是聚合接入的配送平台呼叫騎手配送出去，整個過程涉及外賣訂單的同步和配送單的同步以及一些管理功能。
外賣平台的訂單通知（新訂單、訂單狀態變動等）會透過請求 HTTP 介面通知我們的系統，早期我們做的是同步的方式，即收到請求之後去呼叫外賣平台的訂單查詢介面（及另外幾個配套的介面）來獲取訂單詳情數據之後建立訂單存到數據，然後再響應，因為大量的網路請求需要不少時間，並行量稍微上來一點就扛不住了，試過多開幾台機器和多開幾個行程，但作用都不太大。
記得早期每分鐘能處理 30 單基本是極限了，再多了就出現明顯的響應慢了，而外賣平台的通知又要求我們在規定的時間內響應，因此同步處理的這個套路沒能堅持多久就遇到極大的瓶頸了，嘗試過做多執行緒任務佇列等但效果不行也有任務遺失的風險。
後面我們用了 Celery，收到通知之後把訊息放到 Celery 佇列就返回，讓 Celery 的工作者行程來慢慢處理，避免高峰期扛不住。因為把訊息放到 Celery 佇列的極快的操作，系統也就能即時的響應外賣平台的通知訊息了。
根據訊息積壓情況，我們會適當的調整 Celery 工作者行程數量，並且可以根據訊息的優先級分配不同的佇列，這樣能保證新訂單的通知訊息能夠及時的處理，讓商家盡早知道有新訂單需要處理。
最早 Celery 的訊息分發我們用的 Redis，後面為了更方便監控換成了 RabbitMQ。也可能是經過了幾年的叠代，目前應對節日我們心裏相對有點底，該增加的雲資源就臨時增加一下，Celery 的工作者行程也做成了自動擴容，原則上來講不遇到十分極端的情況的話我們還是有信心能夠應扛得住的。
除了上面提到的這些，大概七八年前我們用 Python 2 + Django 1.8 給政府做過一個讓企業填報數據系統，每年會放開一周讓企業來填，大概有四五千家企業來填，每個企業填七八個表，並行數當時沒註意，保守估計也會有幾十。
一開始用的 Django 內建的 runserver 模式跑的（其實也是沒經驗），很容易就出現卡頓的情況，後面透過 Gunicorn 跑了幾個行程之後就沒出現在語言層面卡的問題來了，慢的時候大機率也是資料庫負載占用太高了或者 mongodb 做數據匯總。
伺服器配置不高只是 2C8G 的，跑 Python Web、MySQL 和 MongoDB，還有其他的一堆套用行程。這個系統跑了三年，第四年因為政府層面的關系變動由另外一家公司重新做來開發了，功能沒我們做的多而且難用，比我們的還卡，不知道他們用的什麽語言。
這個計畫上，Python + MonogoDB 的方式給予我們極大的靈活性，因為每年填報的數據不一樣，統計指標也不一樣，整個系統支持填報表單的自訂、數據校驗、數據匯入匯出、自訂統計等，換其他語言我感覺是很難做出這樣的效果，或者說相同的效果需要付出的代價會更高。
當然這套系統沒多少維護方面的事情，基本上是一次開發成型，後面保證能存取就行，當時是我帶著一個初級程式設計師開發的，我負責核心的架構和大部份程式碼的實作，他做簡單點的邏輯、UI、表定義等，可能他也不一定容易理解我寫的那堆程式碼。這類復雜系統的程式碼可維護性我覺得很大程度取決於規範、文件和培訓，而不是語言層面的型別約束。
另外還做過一套給旅行社內部用的辦公系統，主要是針對東南亞的旅行社，支持多語言多幣種，涵蓋了幾乎旅行社日常的所有業務，包括計劃、成團、拼團、酒店車船、購物、導遊、客人、報賬、收益、財務、報表、圖表等。
也是 Python 2 + Django 1.8 做的，我們給每家旅行社獨立部署一個 Web 行程 + 一個資料庫（資料庫名稱是獨立的，但一台機器上跑一個 mysql）。每個 Web 行程跑起來之後大概 170MB 的記憶體占用，我們用的 2C8G 的機器，每台機器可以給 40 家左右的客戶提供服務，一般客戶每天的使用者使用數據也就是 10 來個，大點的旅行社會有個二三十個員工同時操作，大部份是查數據錄數據，每家的並行估計不會超過 10。
每月初各家都在做賬導數據的時候偶爾會反饋卡頓的問題，據我觀察大部份是資料庫層面的效能問題，我們的解決方案是客戶告訴客戶過一會兒再導（或者要導的數據多的話就讓他們在晚上導），只要幾家之間稍微錯開導數據了也就沒問題。
為了省成本，資料庫我們也是在雲伺服器上自建的，幾乎是把雲伺服器榨到極限了，白天伺服器基本都是跑在 80% 以上的 CPU 占用以及 90% 以上的記憶體占用，導數據的時候 CPU 會跑滿。
2020 年前我們手上有 100 多家客戶，疫情三年基本都沒在做旅遊了，這幾年可能是那幾台伺服器最清閑的時候了，去年今年恢復了一些客戶，但和之前完全沒法比，因為收入銳減，客戶的付費意願也降低了不少。
我是 2012 年前後接觸的 Python，在這之前用 Java 和 C# 的多，Java 用來做 Android 和 Web 的開發，C# 是做 Windows 桌面程式和 Windows Phone 的開發。
之前用的 Java SSH 框架 xml 配置我很頭大，感覺基本都是在寫廢話，不知道現在的 Spring 會不會方便一些，除了框架的麻煩外，Java 語言本身我感覺也是相對繁瑣些。
C# 的感覺比 Java 好，但跨平台方面又拉胯一些，所以現在除了做桌面程式會選 C#，其他情況也不會選了，況且現在大部份情況下寫桌面程式也用網頁了。
而 Python 的感覺就是足夠簡單，可以讓人專註於業務，所以公司在選擇主要的語言的時候就定了 Python 了（雖然那時候我其實對 Python 的熟悉程度還不如 Java 和 C#），整個團隊建設也往 Python 方向，但是也完全想表達隨著 AI 的發展，Python 也會跟著火起來。
前些年招 Python 的人相對困難些，基本都是其他語言的來團隊裏面了才逐漸的適應和熟悉的，這幾年有 Python 基礎的人稍晚多點了（感謝公眾號廣告？），但大部份層次也不高還需要一個熟悉和加強的過程。
一般好點的跟計畫半年以上就可以比較熟練了，慢熱點的可能需要個一年多，更關鍵還是看興趣，有的人就是骨子裏喜歡寫程式了，下班了也會弄些自己感興趣的進步就會很塊。
不同的團隊經驗估計也不能完全復制，我是公司的創始人之一，技術上事基本是我確定，也不存在離職之類的問題。
我對於用 Python 去解決我們遇到的大部份的技術問題還是很有興趣的，包括如何規範如何帶人才能讓程式碼可控人員也能得到提高等也是有信心。
總的講這些年跌跌撞撞多少也積累了點技術和管理上的經驗，換個別的語言說實在的我反而不那麽自信了。
為了跟上AI時代我幹了一件事兒，我建立了一個知識星球社群：ChartGPT與副業。想帶著大家一起探索 ChatGPT和新的AI時代 。
有很多小夥伴搞不定ChatGPT帳號，於是我們決定，凡是這三天之內加入ChatPGT的小夥伴，我們直接送一個正常可用的永久ChatGPT獨立帳戶。
不光是增長速度最快，我們的星球品質也絕對經得起考驗，短短一個月時間，我們的課程團隊釋出了 8個專欄、18個副業計畫 ：
簡單說下這個星球能給大家提供什麽：
1、不斷分享如何使用ChatGPT來完成各種任務，讓你更高效地使用ChatGPT，以及副業思考、變現思路、創業案例、落地案例分享。
2、分享ChatGPT的使用方法、最新資訊、商業價值。
3、探討未來關於ChatGPT的機遇，共同成長。
4、幫助大家解決ChatGPT遇到的問題。
5、 提供一整年的售後服務，一起搞副業
星球福利：
1、加入星球4天後，就送ChatGPT獨立帳號。
2、邀請你加入ChatGPT會員交流群。
3、贈送一份完整的ChatGPT手冊和66個ChatGPT副業賺錢手冊。
其它福利還在籌劃中... 不過，我給你大家保證，加入星球後，收獲的價值會遠遠大於今天加入的門票費用 ！
本星球第一期原價 399 ，目前屬於試營運，早鳥價 169 ，每超過50人漲價10元，星球馬上要來一波大的漲價，如果你還在猶豫，可能最後就要以 更高價格加入了 。。
早就是優勢。建議大家盡早以便宜的價格加入！
歡迎有需要的同學試試，如果本文對您有幫助，也請幫忙點個 贊 + 在看 啦！❤️
在 還有更多優質計畫系統學習資源，歡迎分享給其他同學吧！
你還有什
麽想要補充的嗎？
免責聲明：本文內容來源於網路，文章版權歸原作者所有，意在傳播相關技術知識&行業趨勢，供大家學習交流，若涉及作品版權問題，請聯系刪除或授權事宜。
技術君個人微信
添加技術君個人微信即送一份驚喜大禮包
→ 技術資料共享
→ 技術交流社群
--END--
往日熱文：
Python程式設計師深度學習的「四大名著」：
這四本書著實很不錯！我們都知道現在機器學習、深度學習的資料太多了，面對海量資源，往往陷入到「無從下手」的困惑出境。而且並非所有的書籍都是優質資源，浪費大量的時間是得不償失的。給大家推薦這幾本好書並做簡單介紹。
獲得方式：
1.掃碼關註本公眾號
2.後台回復關鍵詞：名著
▲長按掃描關註，回復名著即可獲取
