誰說不能用 Python開發企業應用？

作者：Mahmoud Hashemi

譯文：開源

語言多元化是PayPal編程文化中一個重要的組成部分。在C++和Java長期流行的同時，更多的團隊選擇了JvaScript和Scala。同時，Braintree的收購也引入了一個久經世故的Ruby社區。

Python作為一門特別的語言，在eBay和PayPal有很長的歷史。而且其流行程度依然有增不減。

eBay的開發者支持Python這個應用於基層領域多年的語言。甚至在eBay管理層官方支持Python以前，技術人員就開始使用Python。我在幾年前加入PayPal並選擇Python來寫內部應用，然而，我卻發現了PayPal中將近15年以前的Python代碼。

目前，Python 支撐著 超過50個項目, 包括:

• 功能和產品型, 例如 eBay Now 和 RedLaser

• 運營和基礎設施型**, 從開放的 OpenStack 到專有設施

• 中間層服務和應用型**, 例如 PayPal 用來設定價格以及檢測用戶可用功能的那個（服務/應用）

• 監測代理和介面*型*, 用於涉及到部署和安全的一些用例

• 批處理任務*型*, 例如數據導入，價格調整，及其它項目

• 以及不計其數的開發者工具

在接下來的文章里我將詳細介紹那些使得 eBay 和 PayPal 的 Python 生態系統從2011年的不超過25個工程師到2014年超過260個工程師所使用的技術和舉措。對於本文，我則會專註於10個不得不予以揭露的關於 eBay 和 PayPal 的企業環境的謬誤。

謬誤 #1: Python 是一門新語言

伴隨著所有的初創公司正在使用它以及孩子們最近也在學習它的事實，這個謬誤為何仍然存在是可以理解的。實際上 Python 已經 超過23歲了, 它最初發佈於1991年, 早於 HTTP 1.0協議 5年且早於 Java 4年. 目前比較有著名的很早就使用 Python 的例子是在1996年: Google 的第一個成功的網路爬蟲.

如果你對於長長的 Python 歷史比較好奇，Python 的作者 Guido van Rossum 已經為你準備好整個故事了.

謬誤 #2: Python 沒有被編譯

不像 C++ 一樣需要一個獨立的編譯器工具鏈，Python 實際上被編譯成了位元組碼，和 Java 或者許多其他的編譯型語言十分相似。更進一步的編譯過程，如果有的話, 取決於運行時環境, 不管是 CPython，PyPy，Jython/JVM，IronPython/CLR，或是其它的進程式虛擬機（process virtual machine）。參考 謬誤 #6 來了解更多。

一條在 PayPal 以及其它地方的通用原則就是，（應用的）安全性不能依賴於代碼的已編譯狀態。更為重要的是加強運行時環境的安全，因為實質上每種語言都有一個解碼器，或者能被攔截並導出受保護的狀態。參考下一條謬誤來了解更多的 Python 安全性問題。

輕量級 Python 的親和力可能使他看起來不怎麼可怕，但是這裡直覺很大程度上是受到了誤導的. 安全的一個核心原則就是儘可能讓呈現的目標更小. 大系統是違背安全原則的，因為他們趨向於 使行為過渡集中化, 並且也 讓開發者難於理解. Python 通過倡導簡潔化來邊緣化這些噁心的問題. 更有甚者, CPython 通過讓自己成為一個簡單、穩定並且易於審核的虛擬機來使這些問題得到解決. 事實上，近期 Coverity Software 的一個分析結果顯示 CPython 得到了他們的最高質量評級.

Python 還擁有一系列可擴展的開源、產業標準化的安全庫序列. 在PayPal, 我們把安全和授信看做是重中之重, 我們發現 hashlib, PyCrypto, 以及 OpenSSL, 通過 PyOpenSSL 和我們自己的定製構建的結合，涵蓋了 PayPal 多樣化的安全和性能需求.

這些諸多的原因，使得 Python 成為PayPal（和eBay）的應用程序安全團隊在某些業務中最快的選擇. 這裡有把Python用在PayPal的安全第一環境中的幾個以安全為基礎應用程序:

• 創建安全代理，以促進密鑰的輪換以並鞏固加密實現

• 同業界領先的 HSM 技術集成

• 為缺乏兼容性的技術棧構建受TLS保護的封裝代理

• 為我們內部的互相認證計劃生成鍵和證書

• 開發主動的漏洞掃描器

另外，還有無數存在安全隱患的用Python構建，面向操作的系統, 諸如防火牆和連接管理. 未來，我們一定回去深入的整合PayPal Python的安全事項.

謬誤 #4: Python 是一門腳本語言

Python 確實可以用來編寫腳本，並且因其簡單的語法、跨平台並且無所不在於 Linux, Macs, 和其它Unix 機器而成為這個領域的領跑者之一.

事實上, Python 可能是常規用途編程語言中最靈活的技術. 以下是一些實例:

• 電信基礎設施 (Twilio)

• 支付系統 (PayPal, Balanced Payments)

• 神經科學和心理學 (許多, 許多, 例子)

• 數值分析和工程 (numpy, numba, 以及 更多其它)

• 動畫(LucasArts, Disney, Dreamworks)

• 遊戲後台 (Eve Online, Second Life, Battlefield, 以及 其它很多)

• Email 基礎設施 (Mailman, Mailgun)

• 媒體存儲和處理 (YouTube, Instagram, Dropbox)

• 操作和系統管理 (Rackspace, OpenStack)

• 自然語言處理(NLTK)

• 機器學習和計算機版本 (scikit-learn, Orange, SimpleCV)

• 安全性和滲透性測試 (很多很多 以及 eBay/PayPal

• 大數據 (Disco, Hadoop support)

• 如理 (Calendar Server, 它 驅動了 Apple iCal)

• 搜索系統 (ITA, Ultraseek, 還有 Google)

• Internet 基礎設施 (DNS) (BIND 10)

更別提網站和web服務了，那些都不在少數. 事實上，PayPal工程師看起來像是有興趣致力於基於Python的web特性,比如 YouTube 和 Yelp. 如果對Python成功案例的更大清單感興趣，那就看看官方的清單吧.

謬誤 #5: Python 是弱類型的

Python 類型系統的特點是擁有強大、靈活的類型操作. 維基百科上對此作出的闡述.

而存在一個不爭而有趣的事實是， Python 是比Java更加強類型的. Java 對於原生類型和對象區分了類型系統，它讓null存在於一個灰色地帶. 另一方面，現代的 Python 擁有一個統一的強類型系統, 其中什麼都沒有（None） 的類型是明確指定的. 更進一步的，JVM自身也是動態類型的，因為可以把它的 根源 追溯到由Sun所收購的Smalltalk VM的一個實現.

Python的類型系統 很棒，但要提供給企業級使用，目前仍然還有許多更重大的事項需要關注.

謬誤 #6: Python 速度慢

首先是有一個重要區別: Python 是一門編程語言，而不是運行時環境. Python 擁有幾個實現:

• CPython 是參考實現, 且也是廣泛發布和使用的實現.

• Jython 是Python用於JVM的是一個成熟的實現.

• IronPython 是 Microsoft 針對其自家的通用語言運行時——又名 .NET，實現的Python .

• PyPy 是一個正在日趨成熟的Python實現，擁有JIT編譯，增量垃圾收集諸多先進的特性.

每一個運行時都有其自己的性能特點, 而且他們本身也不慢. 這裡更重要的地方在於不能錯誤地把一個性能指標分派到一門編程語言智商. 應該總是把該評估用在一個應用程序運行時上面，最好是針對一個特定的使用場景.

清楚了那些事項之後，下面就是一些有Python提供的小項，體現其重要的性能優勢:

• 把 NumPy 用作 Intel 的 MKL SIMD介面

• PyPy的 JIT 編譯能 達到比C還快的性能

• Disqus 能在同樣的100個盒子上容納兩億五千萬到5億用戶

誠然，這些都不是最新的列子，只是我個人的最愛罷了. 這將很容易扯到高性能Python以及獨立提供的運行時這些廣闊的領域. 我們不應只是專註於解決單個特殊的案例, 而是應該把注意力放在對開發人員在 最終產品性能 方面的生產力的普遍影響上面, 特別是在一種企業級環境之下.

C++ vs Python,. 兩種語言在同一個輸出下的對比.

給定足夠的時間，一個循規蹈矩的開發者只會按照下面這種經過論證的方式來編寫精確高效的軟體：

• 設計實現一個可以正確完成任務的軟體，包括開發單獨的測試

• 測試性能，明確瓶頸

• 優化，根據測試和Amdahl法則，並且利用Python與C的淵源

雖然這聽起來很簡單，但是即使是老道的工程師，這依舊是一個非常耗時的過程。Python設計之初就考慮到了這一套開發流程。根據我們的經驗，通常C++和Java項目完成一次迭代流程的時間，夠Python項目完成三次迭代流程。今天，PayPal和eBay中不乏有Python項目使用更少的代碼戰勝了同類C++和Java項目，這多虧了快速的開發使得仔細的裁剪和優化變得可能。

Myth #7: Python無法做到大規模

大規模有許多定義，但無論怎樣，YouTube是個大規模網站。每月UV超過十億，每分鐘上傳的視頻時長超過100小時，佔用互聯網帶寬的20%，所有這一切都以Python作為核心技術。Dropbox,Disqus, Eventbrite, Reddit, Twilio, Instagram, Yelp, EVE Online, Second Life,，以及，是的，以及eBay和PayPal中都有Python大規模的例子，這些證明大規模不僅僅是可能：它是一種模式。

成功的關是鍵簡單性且一致性。CPython，Python的主要虛擬機，其最大限度地放大了這些特性，從而演變出了一個精確可測的運行時。人們很難發現 Python程序員關心垃圾的收集暫停或應用地啟動時間。擁有強大的平台和網路支持，Python其本身自然而然的智能水平可擴展，BitTorrent就是其充分的體現。

此外，規模化主要涵蓋測量和迭代。Python是以分析和優化為要義建立的。看Myth #6了解更多Python如何垂直拓展的細節。

Myth #8: Python缺少好的併發支持

除了偶爾叫囂性能和規模化的問題，有人想提的技術些，"Python缺乏併發，"或者，"GIL怎麼樣？"如果幾十個反例仍不足以支持Python水平及垂直拓展規模的能力，那麼再更深地解釋CPython實現細節也不會有幫助，所以我會簡短些。

Python擁有強大的併發原語，包括generators, greenlets, Deferreds, 和futures.。Python有優秀的併發框架，包括eventlet, gevent,和Twisted。Python在定製運行時尚投入了驚人的工作量，包括Stackless和 PyPy。所有煩人這些和更多表明，根本不存工程師們在Python併發編程方面的缺憾。同時，所有這些都正在被正式的在企業生產環境中支持或使用。例如，請參考Myth #7。

全局解釋器鎖，或稱GIL，是Python在大多數應用場景下的性能優化，也是幾乎所有CPython實現代碼的開發上的基礎優化。GIL使得Python可以很便利地使用操作系統的線程或輕線程（通常指greenlets），且不影響使用多進程。更多相關信息，請看該主題的Q&A列表，以及Python文檔中的介紹。

在PayPal中，一個典型服務的部署需要多台機器，多個進程，多個線程，以及一個數字非常龐大的greenlets，相當於一個非常強大可擴展的并行環境（見下圖）。在大多數的企業環境中，團隊更傾向於往更高層次過度，謹慎並注重災難恢復。然而，在某些情況下，每台機器每天Python服務仍然處理數以百萬計的請求，而且輕鬆處理。

一個基於單一worker的協同非同步架構草圖。最外層的盒子是進程，下一個層次為線程，這裡這些線程都是輕線程。操作系統處理線程間的搶佔，而I/O非同步協同合作。

謬誤 #9: Python 程序員很稀缺

事實上，現在使用 Python 的 web 開發者的確沒有使用 PHP 或者 Java 的 web 開發者多。這可能主要是由於企業需求和教育之間的相互作用導致的，不過 教育領域（教學所使用的編程語言）的趨勢使得情況可能產生變化 。

也就是說，使用 Python 的開發者並不稀缺。現在全世界有數百萬使用 Python 的開發者。已有幾十個Python 技術大會、 StackOverflow 上成千上萬的 Python 內容問答、雇傭大量使用 Python 的開發者的大企業比如 YouTube 、 美國銀行（ Bank of American ）和 LucasArts/Dreamworks 等等，這些都顯而易見地證實了這一點。在 eBay 和 PayPal 我們一直保持擁有幾百位使用 Python 的正式開發者，這是怎麼做到的呢？

那麼，當一個項目被創建時為什麼它會被首推？對於孩子來，大學生和教授們來說，Python作為第一門程序設計語言是非常易於學習的。在eBay，僅僅需要一個星期，一個新的Python程序員就能展示一個真正的成果，並且他們開始散發光芒常常只要2-3個月，通過Internet的寶藏（互動式教程，書，文檔和開源代碼庫）一切皆有可能。

另外一個重要的考慮因素是，項目使用Python會更簡單，它不會像其他項目那樣需要那麼多的開發者。在謬誤6和謬誤9中提到的那樣，在Python項目中，學習像Instagram那樣的高效團隊是一個常見的比喻，並且這確實是我們在eBay和PayPal的經驗。

Myth #10: Python不適應於大項目

Myth #7 討論了大規模運行Python的項目，但開發Python大規模項目是什麼情況呢？正如在Myth #9中提到的，大多數Python不被人看好。 然而Instagram在其被億元美金收購當天達到千萬的點擊量，而整個公司只有十幾個人。Dropbox在2011年只有70個工程師，其他團隊更少。所以，Python適合大規模團隊嗎？

美國銀行實際上有超過5000的Python開發者，一個單獨的項目超過一千萬行Python代碼。JP摩根也經歷了類似的轉變。YouTube也有數千的開發者和數百萬行的代碼。大規模產品和團隊每天都在使用Python，因為它具有良好的模塊化和封裝特性，在特定方面許多的大規模開發建議是一致的。工具，強大的慣例以及代碼審查促使了項目規模化管理的現實。

幸運的是，Python發展於上面所提到的好的奠基。我們在檢查執行使用pyflakes以及其他工具進行Python代碼的靜態分析，正如堅持PEP8——Python語言的基礎風格指南。

最後，應該指出的是，除了調度加速Myth #6以及#7中所提到的，使用Python的項目通常需要更少的開發者。我們常見的成功案例中，使用Java或C++的項目通常有3-5開發者耗時2-6個月，最終由單一的開發者在2-6周（或小時，因為這些原因）完成項目。

有點像奇迹，但卻是現代發展的事實，但其往往出自一個競爭激烈的行業。

一種乾淨的狀態

這些謬誤可能只是消遣。討論這些謬誤仍然很活躍的和受啟發的，包括內部和外部， 因為隱含在每一個謬誤里的都是一個Python的優勢的認識。 而且， 記住這些看似乏味的表現和麻煩的問題是穩步成長的表露， 並穩定地增長興趣促進教育和持續地工作。 在這裡，希望能撲滅一場充滿火焰的戰爭，並且使得能真正去談論工作與Python的實現。

留心將來的帖子，我將深入研究細節在這個概覽。 那麼你在那之前就必須了解細節，已經修正或是註釋起來， 我的電子郵件是 [email protected]. 到那時，開心編碼吧！

題圖：pexels，CC0 授權。