大公司為什么使用Python

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)大公司為什么使用Python，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

PyCon 是全世界最大的以 Python 編程語(yǔ)言 為主題的技術(shù)大會(huì)，大會(huì)由 Python 社區(qū)組織，每年舉辦一次。在 Python 2017 上，Instagram 的工程師們帶來(lái)了一個(gè)有關(guān) Python 在 Instagram 的主題演講，同時(shí)還分享了 Instagram 如何將整個(gè)項(xiàng)目運(yùn)行環(huán)境升級(jí)到 Python 3 的故事。本文為該次演講的內(nèi)容摘要，由 Python 愛好者朱雷撰寫，聊聊架構(gòu)經(jīng)授權(quán)發(fā)布。

Instagram 是一款移動(dòng)端的照片與視頻分享軟件，由 Kevin Systrom 和 Mike Krieger 在 2010 年創(chuàng)辦。Instagram 在發(fā)布后開始快速流行。于 2012 年被 Facebook 以 10 億美元的價(jià)格收購(gòu)。而當(dāng)時(shí) Instagram 的員工僅有區(qū)區(qū) 13 名。

如今，Instagram 的總注冊(cè)用戶達(dá)到 30 億，月活用戶超過 7 億 （作為對(duì)比，微信最新披露的月活躍用戶為 9.38 億）。而令人吃驚的是，這么高的訪問量背后，竟完全是由以速度慢著稱的 Python + Django 支撐。

為什么選擇 Python 和 Django

Instagram 選擇 Django 的原因很簡(jiǎn)單，Instagram 的兩位創(chuàng)始人 (Kevin Systrom and Mike Krieger) 都是產(chǎn)品經(jīng)理出身。在他們想要?jiǎng)?chuàng)造 Instagram 時(shí)，Django 是他們所知道的最穩(wěn)定和成熟的技術(shù)之一。

時(shí)至今日，即使已經(jīng)擁有超過 30 億的注冊(cè)用戶。Instagram 仍然是 Python 和 Django 的重度使用者。Instagram 的工程師 Hui Ding 說(shuō)到： 『一直到用戶 ID 已經(jīng)超過了 32bit int 的限額（約為 20 億），Django 本身仍然沒有成為我們的瓶頸所在?！?/p>

不過，除了使用 Django 的原生功能外，Instagram 還對(duì) Django 做了很多定制化工作：

·擴(kuò)展 Django Models 使其支持 Sharding （一種數(shù)據(jù)庫(kù)分片技術(shù)）。

·手動(dòng)關(guān)閉 GC（垃圾回收）來(lái)提升 Python 內(nèi)存管理效率，他們同樣也寫過一篇博客來(lái)說(shuō)明這件事情：Dismissing Python Garbage Collection at Instagram。

·在位于不同地理位置的多個(gè)數(shù)據(jù)中心部署整套系統(tǒng)。

Python 語(yǔ)言的優(yōu)勢(shì)所在

Instagram 的聯(lián)合創(chuàng)始人 Mike Krieger 說(shuō)過： 『我們的用戶根本不關(guān)心 Instagram 使用了哪種關(guān)系數(shù)據(jù)庫(kù)，他們當(dāng)然也不關(guān)心 Instagram 是用什么編程語(yǔ)言開發(fā)的。』

所以，Python 這種 簡(jiǎn)單 而且 實(shí)用至上 的編程語(yǔ)言最終贏得了 Instagram 的青睞。他們認(rèn)為，使用 Python 這種簡(jiǎn)單的語(yǔ)言有助于塑造 Instagram 的工程師文化，那就是：

（1）專注于定位問題、解決問題 - 而不是工具本身的各種花花綠綠的特性

（2）使用那些經(jīng)過市場(chǎng)驗(yàn)證過的成熟技術(shù)方案 - 而不用被工具本身的問題所煩擾

（3）用戶至上：專注于用戶所能看到的新特性，為用戶帶去價(jià)值

但是，即使使用 Python 語(yǔ)言有這么多好處，它還是很慢，不是嗎？

不過，這對(duì)于 Instagram 不是問題，因?yàn)樗麄冋J(rèn)為：『Instagram 的最大瓶頸在于開發(fā)效率，而不是代碼的執(zhí)行效率』。

At Instagram, our bottleneck is development velocity, not pure code execution.

所以，最終的結(jié)論是：你完全可以使用 Python 語(yǔ)言來(lái)實(shí)現(xiàn)一個(gè)超過幾十億用戶使用的產(chǎn)品，而根本不用擔(dān)心語(yǔ)言或框架本身的性能瓶頸。

如何提升運(yùn)行效率

但是，即使是選用了擁有諸多好處的 Python 和 Django。在 Instagram 的用戶數(shù)迅速增長(zhǎng)的過程中，性能問題還是出現(xiàn)了：服務(wù)器數(shù)量的增長(zhǎng)率已經(jīng)慢慢的超過了用戶增長(zhǎng)率。Instagram 是怎么應(yīng)對(duì)這個(gè)問題的呢？

他們使用了這些手段來(lái)緩解性能問題：

·開發(fā)工具來(lái)幫助調(diào)優(yōu)：Instagram 開發(fā)了很多涵蓋各個(gè)層面的工具，來(lái)幫助他們進(jìn)行性能調(diào)優(yōu)以及找到性能瓶頸。

·使用 C/C++ 來(lái)重寫部分組件：把那些穩(wěn)定而且對(duì)性能最敏感的組件，使用 C 或 C++ 來(lái)重寫，比如訪問 memcache 的 library。

·使用 Cython：Cython 也是他們用來(lái)提升 Python 效率的法寶之一。

除了上面這些手段，他們還在探索異步 IO 以及新的 Python Runtime 所能帶來(lái)的性能可能性。

為什么要升級(jí)到 Python 3

在相當(dāng)長(zhǎng)的一段時(shí)間，Instagram 都跑在 Python 2.7 + Django 1.3 的組合之上。在這個(gè)已經(jīng)落后社區(qū)很多年的環(huán)境上，他們的工程師們還打了非常非常多的小 patch。難道他們要被永遠(yuǎn)卡在這個(gè)版本上嗎？

所以，在經(jīng)過一系列的討論后，他們最終做出一個(gè)重大的決定：升級(jí)到 Python 3??！

事實(shí)上，Instagram 目前已經(jīng)完成了將運(yùn)行環(huán)境遷移到 Python 3 的工作 - 他們的整套服務(wù)已經(jīng)在 Python 3 上跑了好幾個(gè)月了。那么他們是怎么做到的呢？接下來(lái)便是由 Instagram 工程師 Lisa guo 帶來(lái)的 Instagram 如何遷移到 Python 3 的故事。

對(duì)于 Instagram 來(lái)說(shuō)，下面這些因素是推動(dòng)他們將運(yùn)行環(huán)境遷移到 Python 3 的主要原因：

1、新特性：類型注解 Type Annotations

看看下面這段代碼：

def compose_from_max_id(max_id):    
    '''@param str max_id'''

圖中函數(shù)的 max_id 參數(shù)究竟是什么類型呢？int？tuple？或是 list? 等等，函數(shù)文檔里面說(shuō)它是 str 類型。

但隨著時(shí)間推移，萬(wàn)一這個(gè)參數(shù)的類型發(fā)生變化了呢？如果某位粗心的工程師修改代碼的同時(shí)忘了更新文檔，那就會(huì)給函數(shù)的使用者帶來(lái)很大麻煩，最終還不如沒有注釋呢。

2、性能

Instagram 的整個(gè) Django Stack 都跑在 uwsgi 之上，全部使用了同步的網(wǎng)絡(luò) IO。這意味著同一個(gè) uwsgi 進(jìn)程在同一時(shí)間只能接收并處理一個(gè)請(qǐng)求。這讓如何調(diào)優(yōu)每臺(tái)機(jī)器上應(yīng)該運(yùn)行的 uwsgi 進(jìn)程數(shù)成了一個(gè)麻煩事：

為了更好利用 CPU，使用更多的進(jìn)程數(shù)？但那樣會(huì)消耗大量的內(nèi)存。而過少的進(jìn)程數(shù)量又會(huì)導(dǎo)致 CPU 不能被充分利用。

為此，他們決定跳過 Python 2 中哪些蹩腳的異步 IO 實(shí)現(xiàn) （可憐的 gevent、tornado、twisted 眾），直接升級(jí)到 Python 3，去探索標(biāo)準(zhǔn)庫(kù)中的 asyncio 模塊所能帶來(lái)的可能性。

3、社區(qū)

因?yàn)?Python 社區(qū)已經(jīng)停止了對(duì) Python 2 的支持。如果把整個(gè)運(yùn)行環(huán)境升級(jí)到 Python 3，Instagram 的工程師們就能和 Python 社區(qū)走的更近，可以更好的把他們的工作回饋給社區(qū)。

遷移方案

在 Instagram，進(jìn)行 Python 3 的遷移需要必須滿足兩個(gè)前提條件：

（1）不停機(jī)，不能有任何的服務(wù)因此不可用

（2）不能影響產(chǎn)品新特性的開發(fā)

但是，在 Instagram 的開發(fā)環(huán)境中，要滿足上面這兩點(diǎn)來(lái)完成遷移到 Python 3.6 這種龐大的工程是非常困難的。

基于主分支的開發(fā)流程

即便使用了以多分支功能著稱的 git，Instagram 所有的開發(fā)工作都是主要在 master 分支上進(jìn)行的，Instagram 所奉行的開發(fā)哲學(xué)是：『不管是多大的新特性或代碼重構(gòu)，都應(yīng)該拆解成較小的 Commit 來(lái)進(jìn)行?！?/p>

那些被合并進(jìn) master 分支的代碼，都將在一個(gè)小時(shí)內(nèi)被發(fā)布到線上環(huán)境。而這樣的發(fā)布過程每天將會(huì)發(fā)生上百次。在這么頻繁的發(fā)布頻率下，如何在滿足之前的那兩個(gè)前提下來(lái)完成遷移變得尤其困難。

被棄用的遷移方案

創(chuàng)建一個(gè)新分支

很多人在處理這類問題時(shí)，第一個(gè)蹦進(jìn)腦子的想法就是： 『讓我們創(chuàng)建一個(gè)分支，當(dāng)我們開發(fā)完后，再把分支合并進(jìn)來(lái)』。但在 Instagram 這么高的迭代頻率上，使用一個(gè)獨(dú)立分支并不是好主意：

·Instagram 的 Codebase 每天都在頻繁更新，在開發(fā) Python 3 分支的過程中，讓新分支與現(xiàn)有 master 分支保持同步開銷極大，同時(shí)極易出錯(cuò)

·最終將 Python 3 分支這個(gè)改動(dòng)非常多的分支合并回 Master 擁有非常高的風(fēng)險(xiǎn)

·只有少數(shù)幾個(gè)工程師在 Python 3 分支上專職負(fù)責(zé)升級(jí)工作，其他想幫助遷移工作的工程師無(wú)法參與進(jìn)來(lái)

挨個(gè)替換接口

還有一個(gè)方案就是，挨個(gè)替換 Instagram 的 API 接口。但是 Instagram 的不同接口共享著很多通用模塊。這個(gè)方案要實(shí)施起來(lái)也非常困難。

微服務(wù)

還有一個(gè)方案就是將 Instagram 改造成微服務(wù)架構(gòu)。通過將那些通用模塊重寫成 Python 3 版本的微服務(wù)來(lái)一步步完成遷移工作。

但是這個(gè)方案需要重新組織海量的代碼。同時(shí)，當(dāng)發(fā)生在進(jìn)程內(nèi)的函數(shù)調(diào)用變成 RPC 后 ，整個(gè)站點(diǎn)的延遲會(huì)變大。此外，更多的微服務(wù)也會(huì)引入更高的部署復(fù)雜度。

所以，既然 Instagram 的開發(fā)哲學(xué)是：小步前進(jìn)，快速迭代。他們最終決定的方案是：一步一步來(lái)，最終讓 master 分支上的代碼同時(shí)兼容 Python 2 和 Python 3 。

正式遷移到 Python 3

既然要讓整個(gè) codebase 同時(shí)兼容 Python 2 和 Python 3，那么首先要符合這點(diǎn)的就是那些被大量使用的第三方 package。針對(duì)第三方 package，Instagram 做到了下面幾點(diǎn)：

·拒絕引入所有不兼容 Python 3 的新 package

·去掉所有不再使用的 package

·替換那些不兼容 Python 3 的 package

在代碼的遷移過程中，他們使用了工具 modernize 來(lái)幫助他們。

使用 modernize 時(shí)，有一個(gè)小技巧：每次修復(fù)多個(gè)文件的一個(gè)兼容問題，而不是一下修復(fù)一個(gè)文件中的多個(gè)兼容問題。 這樣可以讓 Code Review 過程簡(jiǎn)單很多，因?yàn)?Reviewer 每次只需要關(guān)注一個(gè)問題。

對(duì)于 Python 這種靈活性極強(qiáng)的動(dòng)態(tài)語(yǔ)言來(lái)說(shuō)，除了真正去執(zhí)行代碼外，幾乎沒有其他比較好的檢查代碼錯(cuò)誤的手段。

前面提到，Instagram 所有被合并到 master 的代碼提交會(huì)在一個(gè)小時(shí)內(nèi)上線到線上環(huán)境，但這不是沒有前提條件的。在上線前，所有的提交都需要通過成千上萬(wàn)個(gè)單元測(cè)試。

于是，他們開始加入 Python 3 來(lái)執(zhí)行所有的單元測(cè)試。一開始，只有極少數(shù)的單元測(cè)試能夠在 Python 3 環(huán)境下通過，但隨著 Instagram 的工程師們不斷的修復(fù)那些失敗的單元測(cè)試，最終所有的單元測(cè)試都可以在 Python 3 環(huán)境下成功執(zhí)行。

但是，單元測(cè)試也是有局限性的：

·Instagram 的單元測(cè)試沒有做到 100% 的代碼覆蓋率

·很多第三方模塊都使用了 mock 技術(shù)，而 mock 的行為與真實(shí)的線上服務(wù)可能會(huì)有所不同

所以，當(dāng)所有的單元測(cè)試都被修復(fù)后，他們開始在線上正式使用 Python 3 來(lái)運(yùn)行服務(wù)。

這個(gè)過程并不是一蹴而就的。首先，所有的 Instagram 工程師開始訪問到這些使用 Python 3 來(lái)執(zhí)行的新服務(wù)，然后是 Facebook 的所有雇員，隨后是 0.1%、20% 的用戶，最終 Python 3 覆蓋到了所有的 Instagram 用戶。

遷移過程的技術(shù)問題

Instagram 在遷移到 Python 3 時(shí)碰到很多問題，下面是最典型的幾個(gè)：

Unicode 相關(guān)的字符串問題

Python 3 相比 Python 2 最大的改動(dòng)之一，就是在語(yǔ)言內(nèi)部對(duì) unicode 的處理。

在 Python 2 中，文本類型 （也就是 unicode） 和二進(jìn)制類型 （也就是 str） 的邊界非常模糊。很多函數(shù)的參數(shù)既可以是文本，也可以是二進(jìn)制。但是在 Python 3 中，文本類型和二進(jìn)制類型的字符串被完全的區(qū)分開了。

于是，下面這段在 Python 2 下可以正常運(yùn)行的代碼在 Python 3 下就會(huì)報(bào)錯(cuò)：

mymac = hmac.new('abc') TypeError: key: expected bytes or bytearray, but got 'str'

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-tQT44Q0M-1570179360052)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

解決辦法其實(shí)很簡(jiǎn)單，只要加上判斷：如果 value 是文本類型，就將其轉(zhuǎn)換為二進(jìn)制。如下所示：

value = 'abc'
if isinstance(value, six.text_type):    
value = value.encode(encoding='utf-8') 
mymac = hmac.new(value)

但是，在整個(gè)代碼庫(kù)中，像上面這樣的情況非常多。作為開發(fā)人員，如果需要在調(diào)用每個(gè)函數(shù)時(shí)都要想想： 這里到底是應(yīng)該編碼成二進(jìn)制，或者是解碼成文本呢？ 將會(huì)是非常大的負(fù)擔(dān)。

于是 Instagram 封裝了一些名為 ensure_str()、ensure_binary()、ensure_text() 的幫助函數(shù)，開發(fā)人員只需對(duì)那些不確定類型的字符串，使用這些幫助函數(shù)先做一次轉(zhuǎn)換就好。

mymac = hmac.new(ensure_binary('abc'))

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-Ls5jOGEl-1570179360053)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

不同 Python 版本的 pickle 差異

Instagram 的代碼中大量使用了 pickle。比如用它序列化某個(gè)對(duì)象，然后將其存儲(chǔ)在 memcache 中。如下面的代碼所示：

memcache_data = pickle.dumps(data, pickle.HIGHEST_PROTOCOL)data = pickle.loads(memcache_data)

問題在于，Python 2 與 Python 3 的 pickle 模塊是有差別的。

如果上文的第一行代碼，剛好是由 Python 3 運(yùn)行的服務(wù)進(jìn)行序列化后存入 memcache。而反序列化的過程卻是由 Python 2 進(jìn)行，那代碼運(yùn)行時(shí)就會(huì)出現(xiàn)下面的錯(cuò)誤：

ValueError: unsupported pickle protocol: 4

這是由于在 Python 3 中，pickle.HIGHEST_PROTOCOL 的值為 4，而 Python 2 中的的 pickle 最高支持的版本號(hào)卻是 2。那么如何解決這個(gè)問題呢？

Instagram 最終選擇讓 Python 2 和 Python 3 使用完全不同的 namespace 來(lái)訪問 memcache。通過將二者的數(shù)據(jù)讀寫完全隔開來(lái)解決這個(gè)問題。

迭代器

在 Python 3 中，很多內(nèi)置函數(shù)被修改成了只返成迭代器 Iterator：

map() filter() dict.items()

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來(lái)直接上傳(img-GLVPUDc0-1570179360059)(data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==)]

迭代器有諸多好處，最大的好處就是，使用迭代器不需要一次性分配大量?jī)?nèi)存，所以它的內(nèi)存效率比較高。

但是迭代器有一個(gè)天然的特點(diǎn)，當(dāng)你對(duì)某個(gè)迭代器做了一次迭代，訪問完它的內(nèi)容后，就沒法再次訪問那些內(nèi)容了。迭代器中的所有內(nèi)容都只能被訪問一次。

在 Instagram 的 Python 3 遷移過程中，就因?yàn)榈鞯倪@個(gè)特性被坑了一次，看看下面這段代碼：

CYTHON_SOURCES = [a.pyx, b.pyx, c.pyx] 
builds = map(BuildProcess, CYTHON_SOURCES)
while 
    any(not build.done() 
for build in builds):    
    pending = [build 
for build in builds 
if not build.started()]    
<do some work>

這段代碼的用處是挨個(gè)編譯 Cython 源文件。當(dāng)他們把運(yùn)行環(huán)境切換到 Python 3 后，一個(gè)奇怪的問題出現(xiàn)了：CYTHON_SOURCES 中的第一個(gè)文件永遠(yuǎn)都被跳過了編譯。為什么呢？

這都是迭代器的鍋。在 Python 3 中，map() 函數(shù)不再返回整個(gè) list，而是返回一個(gè)迭代器。

于是，當(dāng)?shù)诙写a生成 builds 這個(gè)迭代器后，第三行代碼的 while 循環(huán)迭代了 builds，剛好取出了第一個(gè)元素。于是之后的 pending 對(duì)象便里面永遠(yuǎn)少了那第一個(gè)元素。

這個(gè)問題解決起來(lái)也挺簡(jiǎn)單的，你只要手動(dòng)的吧 builds 轉(zhuǎn)換成 list 就可以了：

builds = list(map(BuildProcess, CYTHON_SOURCES))

但是這類 bug 非常難定位到。如果用戶的 feeds 里面永遠(yuǎn)少了那最新的第一條，用戶很少會(huì)注意到。

字典的順序

看看下面這段代碼：

>>> testdict = {'a': 1, 'b': 2, 'c': 3}>>> json.dumps(testdict)

它會(huì)輸出什么結(jié)果呢？

# Python2'{"a": 1, "c": 3, "b": 2}'# Python 3.5.1'{"c": 3, "b": 2, "a": 1}'    
# or'{"c": 3, "a": 1, "b": 2}'# Python 3.6'{"a": 1, "b": 2, "c": 3}'

在不同的 Python 版本下，這個(gè) json dumps 的結(jié)果是完全不一樣的。甚至在 3.5.1 中，它會(huì)完全隨機(jī)的返回兩個(gè)不同的結(jié)果。Instagram 有一段判斷配置文件是否發(fā)生變動(dòng)的模塊，就是因?yàn)檫@個(gè)原因出了問題。

這個(gè)問題的解決辦法是，在調(diào)用 json.dumps 傳入 sort_keys=True 參數(shù)：

>>> json.dumps(testdict, sort_keys=True)'{"a": 1, "b": 2, "c": 3}'

遷移到 Python 3.6 后的性能提升

當(dāng) Instagram 解決了這些奇奇怪怪的版本差異問題后，還有一個(gè)巨大的謎題困擾著他們：性能問題。

在 Instagram，他們使用兩個(gè)主要指標(biāo)來(lái)衡量他們的服務(wù)性能：

·每次請(qǐng)求產(chǎn)生的 CPU 指令數(shù)（越低越好）

·每秒能夠處理的請(qǐng)求數(shù)（越高越好）

所以，當(dāng)所有的遷移工作完成后，他們非常驚喜的發(fā)現(xiàn)：第一個(gè)性能指標(biāo)，每次請(qǐng)求產(chǎn)生的 CPU 指令數(shù)居然足足下降了 12% ?。?！

但是，按理說(shuō)第二個(gè)指標(biāo) - 每秒請(qǐng)求數(shù)也應(yīng)該獲得接近 12% 的提升。不過最后的變化卻是 0%。究竟是出了什么問題呢？

他們最終定位到，是由于不同 Python 版本下的內(nèi)存優(yōu)化配置不同，導(dǎo)致 CPU 指令數(shù)下降帶來(lái)的性能提升被抵消了。那為什么不同 Python 版本下的內(nèi)存優(yōu)化配置會(huì)不一樣呢？

這是他們用來(lái)檢查 uwsgi 配置的代碼：

if uwsgi.opt.get('optimize_mem', None) == 'True':    optimize_mem()

注意到那段... ... == 'True'了嗎？在 Python 3 中，這個(gè)條件判斷總是不會(huì)被滿足。問題就在于 unicode。在將代碼中的'True'換成 b'True'（也就是將文本類型換成二進(jìn)制，這種判斷在 Python 2 中完全不區(qū)分的）后，問題解決了。

所以，最終因?yàn)榧由狭艘粋€(gè)小小的字母 'b'，程序的整體性能提升了 12%。

完美切換

在今年二月份，Instagram 的后端代碼的運(yùn)行環(huán)境完全切換到了 Python 3 下：

當(dāng)所有的代碼都都遷移到 Python 3 運(yùn)行環(huán)境后：

·節(jié)約了 12% 的整體 CPU 使用率（Django/uwsgi）

·節(jié)約了 30% 的內(nèi)存使用（celery）

同時(shí)，在整個(gè)遷移期間，Instagram 的月活用戶經(jīng)歷了從 4 億到 6 億 的巨大增長(zhǎng)。產(chǎn)品也發(fā)布了評(píng)論過濾、直播等非常多新功能。

那么，那幾個(gè)最開始驅(qū)動(dòng)他們遷移到 Python 3 的目的呢？

·類型注解：Instagram 的整個(gè) codebase 里已經(jīng)有 2% 的代碼添加上了類型注解，同時(shí)他們還開發(fā)了一些工具來(lái)輔助開發(fā)者添加類型提示

·asyncio：他們?cè)趩蝹€(gè)接口中利用 asynio 平行的去做多件事情，最終降低了 20-30% 的請(qǐng)求延遲。

·社區(qū)：他們與 Intel 的工程師聯(lián)合，幫助他們更好的對(duì) CPU 利用率進(jìn)行調(diào)優(yōu)。同時(shí)還開發(fā)了很多新的工具，幫助他們進(jìn)行性能調(diào)優(yōu)

Instagram 帶給我們的啟示

Instagram 的演講視頻時(shí)間不長(zhǎng)，但是內(nèi)容很豐富，在編寫此文前，我完全沒有想到最終的文章會(huì)這么長(zhǎng)。

那么，Instagram 的視頻可以給我們哪些啟示呢？

·Python + Django 的組合完全可以負(fù)載用戶數(shù)以 10 億記的服務(wù)，如果你正準(zhǔn)備開始一個(gè)項(xiàng)目，放心使用 Python 吧！

·完善的單元測(cè)試對(duì)于復(fù)雜項(xiàng)目是非常有必要的。如果沒有那『成千上萬(wàn)的單元測(cè)試』。很難想象 Instagram 的遷移項(xiàng)目可以成功進(jìn)行下去。

·開發(fā)者和同事也是你的產(chǎn)品用戶，利用好他們。用他們?yōu)槟愕男绿匦园l(fā)布前多一道測(cè)試。

·完全基于主分支的開發(fā)流程，可以給你更快的迭代速度。前提是擁有完善的單元測(cè)試和持續(xù)部署流程。

·Python 3 是大勢(shì)所趨，如果你正準(zhǔn)備開始一個(gè)新項(xiàng)目，無(wú)需遲疑，擁抱 Python 3 吧！

上述就是小編為大家分享的大公司為什么使用Python了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。