I Love Python

<轉> 語言多元化是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 安全性問題。

謬誤 #3: 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的實現。

留心未來的帖子，我將深刻研究細節在這個概覽。 那麼你在那以前就必須瞭解細節，已經修正 或是註釋起來， 個人電子郵件是 mahmoud@paypal.com. 到那時，開心編碼吧！