引言

要成為託管服務行業的領導者，您必須快速靈活。透過使用Python實現我們的企業資料系統，Rackspace可以快速有效地更改其內部系統，以跟上行業和我們自身業務流程的變化。我們透過一個名為“CORE”的中央客戶資訊系統來實現這一點，該系統用於客戶關係管理（CRM）和企業資源規劃（ERP）。Python和CORE是Rackspace提供我們的狂熱支援（Fanatical Support™）和更快客戶服務的關鍵因素。

背景

Rackspace的中央客戶資料庫最初是一個簡單的ERP系統，用於配置和跟蹤託管伺服器。它最初規模不大，只是一小部分PHP頁面，對於Rackspace最初的幾百臺伺服器客戶來說，執行良好。

隨著Rackspace的發展，這個小小的PHP系統成為了Rackspace業務的中心。每當出現自動化流程的機會時，它都被整合到這個系統中。

幾年後，結果是成千上萬個PHP頁面和模組的龐大、難以維護的混亂局面，這些頁面和模組主要由一個人編寫和維護。PHP（當時是版本3）的限制已被推到極致，系統對於一個人來說過於龐大，而且很難引入新人來協助維護。

Rackspace託管服務在最先進的資料中心提供定製伺服器 放大

我們第一次嘗試更新系統是在PHP版本4釋出時。該版本承諾提供更好的面向物件功能，並且是Rackspace投入更多人員到該專案的合適時機。

該系統從頭開始徹底重新設計，包括新的資料庫模式和應用程式設計策略。此時，我們將專案重新命名為“CORE”，它是“核心物件隨處複用”（Core Objects Reused Everywhere）的首字母縮寫，以反映CORE的整體設計目標：公司所有系統中的模組化和可重用性。考慮到這個目標，我們的團隊開始使用PHP的面向物件功能。

雖然我們能夠重新調整應用程式並增加功能，但該專案最終失敗，很大程度上是由於在使用PHP提供的物件框架時遇到的問題。

記憶體洩漏、介面不一致、內部資料模型不一致、隨機釋放物件、儘管明確使用引用仍有多個物件副本、內部PHP錯誤以及無法追溯的程式碼故障幾乎使得在PHP中完成任務成為不可能。

即使我們獲得了一個相對穩定的程式碼庫，我們也遠未達到“核心物件隨處複用”的目標，因為我們不得不偏離純粹的面向物件方法，僅僅是為了規避PHP固有的問題。很明顯，PHP不適合我們的大規模、任務關鍵型專案。必須找到新的解決方案。

Python在CORE中

我們一直認為Python是實現我們企業系統的優秀選擇，但最初我們放棄了它，轉而繼續使用我們已有的（龐大）PHP程式碼庫。當時，我們認為透過引入更結構化的系統設計，PHP可以在CORE中成功使用。

不幸的是，這不足以克服我們在PHP方面遇到的其他問題，因此我們重新評估了我們的情況。Python 2.2的第一個Alpha版本最近釋出，我們決定開始使用該版本中的新功能開發新的CORE框架。

內省的強大功能

編寫新框架的首要任務之一是構建其資料庫介面。

Python的內省模型在Python 2.2釋出後得到了顯著增強。我們決定使用它來構建一個基於DBI 2.0相容資料庫聯結器的通用資料庫介面類。在這種方法中，不是手動編寫查詢或表特定的包裝器，而是透過元類將所有資料庫查詢抽象為一個乾淨的API。

我們建立這個元類的派生類，為每個表建立一個API。每個表的類都包含一些描述資料庫中列的類常量。這樣，我們可以在不擔心任何特定表的實現細節的情況下，快速簡單地向整體API新增新表。

該API還使用元資料自動驗證和轉換傳遞給資料庫的值。這是透過一個“規範化器”函式完成的，該函式將透過API傳遞的Python資料型別轉換為有效的SQL值。該函式還驗證資料庫或Python不一定檢查的型別和格式，例如電話號碼和郵政編碼。

物件隨處複用

資料庫API完成後，我們在其之上建立了第二層類。這個更高層次的API實現了特定應用程式的業務邏輯，例如聯絡人管理或故障工單處理。它還阻止使用者執行與Rackspace業務實踐不一致的操作，或分配可能導致資料庫中其他型別高階資料損壞的資料。

隨著第二層的建立，我們實現了“核心物件隨處複用”的最初目標。公司內的程式設計師開始使用這個API來實現應用程式功能的介面。這與我們的API開發團隊幾乎沒有互動，並且可以在不擔心濫用API的情況下完成。

雖然我們主要為核心企業應用CORE設計了API，但它在Rackspace的許多其他系統中得到了重用。例如，一個團隊在API之上構建了一個SOAP伺服器，以便從他們的PHP應用程式中訪問它。其他應用程式直接使用API，看到我們的工作如此輕鬆地被重用並與其他系統整合，令人非常滿意。

將Python與Apache整合

有了API之後，我們開發CORE的下一個任務是找到一個有用的模板模組，將我們的Python程式碼與執行在Apache網路伺服器上的HTML頁面整合。

在查看了許多可用的基於Python的模板模組後，我們選擇建立自己的簡單解析器。我們的方法是將伺服器端模板頁面轉換為Python服務程式，其輸出由HTTP伺服器傳送到使用者的瀏覽器。

雖然這是一個相當簡單的練習，但我們確實遇到了一些問題，這些問題源於我們CORE資料庫元類的設計。我們發現，在執行時更改類和模組（如元類所做的那樣）違反了Python可選的受限執行環境所施加的準則。由於我們認為受限執行是支援持久Web模組的必要元件，因此我們選擇使用CGI而不是mod_python或類似的持久解決方案來部署CORE。

由於快速硬體和多臺伺服器隨處可用，並且由於我們的模板解析器預編譯並快取其生成的Python服務程式程式碼，CGI解決方案足以滿足我們的需求。它還允許我們解決諸如資料庫連線池和限制Python之外的執行環境等問題。

單元測試

多虧了Python自帶的單元測試模組，我們的專案在投入生產時產生的bug比我們使用PHP時想象的要少得多。在使用PHP進行維護時，總會有一個問題，即一個地方的更改是否會破壞應用程式的另一部分。

我們現在在設計API時為每個API編寫單元測試。這意味著我們可以透過執行整個API的單元測試來驗證一個模組的更改以及它對所有其他模組的影響。

自從引入Python和單元測試以來，我們在已部署應用程式中看到的bug的性質已經發生變化，主要包括使用者介面中的問題，例如佈局問題或錯誤的事件處理。

現在，很少有bug來自API本身，即使有，通常也是應用程式部署過程中修訂管理不善或DBA協調不力造成的。Python無法解決開發過程中的所有問題，但它確實為我們減少了關鍵系統缺陷的數量。

文件

文件缺失是我們之前開發工作中的一個主要問題。我們嘗試了多種工具和策略來記錄我們的PHP工作，但最終這些都失敗了。程式碼變化太快，而且當時可用於PHP的程式碼級文件工具過於挑剔，不值得投入精力來使文件正確解析。此外，儘管有周密的計劃和編碼策略，PHP和HTML的混合使得解讀和理解程式碼更加困難。

幸運的是，Python在設計時考慮了文件，為模組、類和方法使用了“文件字串”。由於文件本身就是語言的一部分，並且pydoc是Python發行版中的標準模組，因此很容易將API文件提取到HTML和其他格式。

隨著時間的推移，我們發現Python的語法結構使得程式碼具有極高的可讀性，這本身就有助於文件化和維護程式碼的整體任務。

結論

Python極大地改進了CORE專案的開發流程，並縮短了開發時間，加快了釋出速度，使我們能夠跟上Rackspace不斷變化的業務流程。

Python使我們能夠建立一個複雜而動態的資料模型，它靈活且易於使用，可以抽象資料庫操作。有了它，我們實現了“核心物件隨處複用”的目標。

Python整合的單元測試和文件工具極大地增強了我們部署和維護更穩定、無錯誤產品的能力。

最終結果是一個成功的企業應用程式，它對Rackspace託管服務（Rackspace Managed Hosting）在託管行業中兌現其狂熱支援（Fanatical Support）、無與倫比的速度（Unmatched Speed）和無限靈活性（Unlimited Flexibility）的承諾至關重要。

關於作者

Nick Borko是內部應用開發總監，也是Rackspace企業資料庫應用程式CORE的專案經理。Rackspace託管服務是向中小型企業提供託管服務的領導者。所有客戶平臺都包括最先進的資料中心、定製伺服器、可突發連線、99.999%正常執行時間SLA、專用客戶經理、即時緊急響應以及24x7全天候訪問即時專家技術人員，以支援所有硬體和核心軟體。Rackspace成立於1998年，總部位於德克薩斯州聖安東尼奧，為80多個國家/地區的客戶管理伺服器。