# Appknox 架構-從 AWS 切換到 Google Cloud > 原文： [http://highscalability.com/blog/2015/5/25/appknox-architecture-making-the-switch-from-aws-to-the-googl.html](http://highscalability.com/blog/2015/5/25/appknox-architecture-making-the-switch-from-aws-to-the-googl.html)  *這是來自 Appknox 的全棧& DevOps 工程師 [dhilipsiva](http://dhilipsiva.com/) 的來賓帖子。* [Appknox](https://www.appknox.com/) 幫助檢測和修復移動應用程序中的安全漏洞。 保護您的應用程序就像提交商店鏈接一樣簡單。 我們上傳您的應用程序，掃描安全漏洞，然后報告結果。 What's notable about our stack: * **模塊化設計**。 到目前為止，我們已經對模塊進行了模塊化，因此我們將前端與后端分離了。 這種架構具有許多優點，我們將在后面的文章中討論。 * **從 AWS 切換到 Google Cloud** 。 我們使代碼在很大程度上與供應商無關，因此我們能夠輕松地從 AWS 切換到 Google Cloud。 ## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#primary-languages)主要語言 1. 后端的 Python & Shell 2. 前端的 CoffeeScript 和 LESS ## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#our-stack)我們的堆棧 1. Django 的 2. Postgres（從 MySQL 遷移） 3. 兔子 MQ 4. 芹菜 5. 雷迪斯 6. 記憶快取 7. 漆 8. Nginx 的 9. 人的 10. Google 計算 11. 谷歌云存儲 ## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#architecture)架構 [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/sourimg/architecture-at-appknox.jpg) ### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#how-it-works)它是如何工作的？ 我們的后端架構由 3 個子系統組成：客戶端，數據和工作程序。 ### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#client-subsystem)客戶端子系統 客戶端子系統由兩個不同的負載平衡，自動擴展的 App &套接字服務器組成。 這是所有用戶交互的地方。 我們非常注意不要在此處進行任何阻塞調用，以確保將延遲降至最低。 **App Server** ：每個 App 服務器都是單個計算單元，裝有 Nginx 和 Django-gunicorn 服務器，由超級用戶管理。 用戶請求在此提供。 當用戶提交其應用程序的網址時，我們會將其提交給 RabbitMQ `download`隊列，并立即讓用戶知道該網址已提交。 如果上載任何應用程序，將從服務器獲取簽名的 URL。 瀏覽器將使用此簽名 URL 將數據直接上傳到 S3，并在完成后通知應用服務器。 **套接字服務器**：每個套接字服務器都是一個裝有 Nginx 和一個節點（socket-io）服務器的計算單元。 該服務器使用 Redis 作為其適配器。 是的，當然，這用于實時更新。 ### 數據子系統 #### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#data-subsystem) 該系統用于數據存儲，排隊和發布/訂閱。 這也負責解耦架構。 **數據庫群集**：我們使用 Postgres。 不言而喻，它由一個“重寫入”母版和幾個“重讀取”副本組成。 **RabbitMQ** ：我們芹菜工人的經紀人。 對于不同的工人，我們有不同的隊列。 主要是`download`，`validate`，`upload`，`analyse`，`report`，`mail`和`bot`。 Web 服務器將數據放入隊列，芹菜工作者將其拾取并運行。 **Redis** ：這充當套接字 io 服務器的適配器。 每當我們想要通知用戶任何工作人員的更新時，我們都會將其發布到 Redis，Redis 隨后將通過 Socket.IO 通知所有用戶。 ### [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#worker-subsystem)工作者子系統 這是所有繁重的起重工作完成的地方。 所有工作人員均通過 Redis 從 RabbitMQ 和已發布更新中獲取任務給用戶。 **靜態掃描儀**：這是一個自動縮放的計算單元組。 每個單位由 4-5 名芹菜工人組成。 每個芹菜工人一次掃描一個應用程序。 **其他任務**：這是一個自動縮放的計算單元組。 每個單位由 4-5 名芹菜工作者組成，他們執行各種任務，例如從商店下載應用程序，生成報告 pdf，上傳報告 pdf，發送電子郵件等。 **動態掃描**：這是特定于平臺的。 每個 Android 動態掃描程序都是一個按需計算實例，該實例具有 android 模擬器（帶有 SDK）和一個捕獲數據的腳本。 該模擬器顯示在瀏覽器的畫布上，供用戶進行交互。 每個 iOS 掃描儀都位于托管的 Mac-Mini 服務器場中，該服務器場具有支持 iOS 平臺的腳本和模擬器。 ## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#reasons-for-choosing-the-stack)選擇堆棧的原因 我們選擇 **Python** 是因為我們用于掃描應用程序的主要庫位于 python 中。 而且，我們比已知的任何其他語言都更喜歡 python。 我們選擇 **Django** 是因為它具有模塊化功能。 **灰燼**-我們認為這是目前最強大的前端框架。 是的，學習曲線比其他任何曲線都陡峭，但是一旦您爬上那座陡峭的山峰，您將絕對喜歡余燼。 這是很自以為是的。 因此，只要您遵守它的約定，就可以減少編寫工作。 **Postgres** -最初，我們選擇 MySQL 是因為它是事實。 在甲骨文收購 Sun Microsystems（MySQL 的母公司）之后，MySQL 陷入停滯。 我想我們都期望如此。 因此，我們確實使用了社區維護的 MariaDB（MySQL 的一個分支）。 后來，我們需要持久鍵值存儲，這是 Postgres 開箱即用的。 它在 Python 中發揮的非常好。 我們使用 UUID 作為主鍵，這是 Postgres 中的本機數據類型。 另外，`uuis-ossp`模塊提供了在數據庫級別生成和操作 UUID 的功能，而不是在應用程序級別創建它們的功能，這更加昂貴。 因此我們切換到 Postgres。 其余的都是事實。 **RabbitMQ** 用于任務隊列。 **Celery** 用于任務管理。 **Redis** 用于發布/訂閱。 **Memcached &清漆**用于緩存。 ## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#things-that-didnt-go-as-expected)事情未按預期進行 未能按預期進行的事情之一是**縮放套接字**。 我們最初使用的是 Django-socket.io。 我們意識到這無法擴展到多個服務器。 因此，我們將其編寫為單獨的節點模塊。 我們使用了支持 Redis-adapter 的節點的 socket-io 庫。 客戶端連接到節點的套接字服務器。 因此，我們現在從 python 代碼發布到 Redis。 Node 只會將通知推送給客戶端。 可以獨立于充當客戶端 JSON 端點的應用程序服務器進行擴展。 ## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#notable-stuff-about-our-stack)關于堆棧的顯著資料 我們喜歡**模塊化設計**。 到目前為止，我們一直在對模塊進行模塊化，以至于我們將前端與后端分離。 是的，你沒有看錯。 所有 HTML，CoffeeScript 和 LESS 代碼都是獨立于后端開發的。 前端開發不需要服務器在運行。 在開發過程中，我們依靠前端設備來獲取假數據。 我們的**后端命名為** **Sherlock** 。 我們檢測移動應用程序中的安全漏洞。 所以這個名字似乎很貼切。 Sherlock 很聰明。 我們的**前端稱為 Irene** 。 還記得艾琳·阿德勒（Irene Adler）嗎？ 她美麗，多彩，并告訴我們用戶出了什么問題。 我們的**管理員名為 Hudson** 。 還記得哈德森夫人嗎？ 夏洛克的女房東？ 考慮到我們應該為可憐的沃森博士扮演什么角色。 也許我們會。 因此，Sherlock 不提供任何 HTML / CSS / JS 文件。 我再說一遍，它**不提供任何單個靜態文件/ HTML 文件**。 夏洛克和艾琳都是獨立開發的。 兩者都有單獨的部署過程。 兩者都有自己的測試用例。 我們將 Sherlock 部署到**計算實例**，并將 Irene 部署到 **Google Cloud Storage** 。 這種架構的**優勢在于：** 1. 前端團隊可以**獨立于后端的**工作，而無需互相踩腳。 2. 從服務器移除**等繁重的工作，例如在服務器上呈現頁面。** 3. 我們可以**開放源代碼的前端代碼**。 輕松雇用前端人員。 只需要求他們修復存儲庫中的錯誤，便可以雇用他們。 畢竟，即使您不開源它，任何人都可以讀取前端代碼？ ## [](https://github.com/dhilipsiva/dhilipsiva.github.io/blob/source/_posts/2015-01-26-architecture-at-appknox.md#our-deployment-process)我們的部署流程 該代碼是從`master`分支自動部署的**。 我們遵循 [Vincent Driessen](http://nvie.com/posts/a-successful-git-branching-model/) 的 Git 分支模型。 Jenkins build 提交到`develop`分支。 如果成功，我們將進行另一項手動測試，只是要確保將其與`master`分支合并并自動部署。** ## 最初使用的 AWS。 我們決定使用 Google Cloud 的原因有 3 個。 1. 我們喜歡基于**基于項目的方法來管理不同應用程序的資源**。 它使訪問基礎架構更加實用。 由于我們的“動態掃描”功能的復雜性，它使識別實例更加容易。 2. 當我們受到打擊時，它具有**令人敬畏的文檔**，并獲得了 Google 工程師的私人 1：1 幫助。 3. 我們收到了一些**重要的 Google 積分**，這有助于我們在早期階段削減成本。 我始終遠離 IaaS 提供商提供的特殊服務。 例如，我們沒有使用 Amazon RDS 或 SQS。 配置了我們自己的數據庫服務器，RabbitMQ 和 Redis 實例。 這樣做的原因是-這些服務相對較慢（且成本較高），并且您的產品依賴于供應商。 我們將所有這些抽象為獨立于供應商的。 我們忘了抽象的一件事就是存儲。 我們直接消耗了 S3。 當我們嘗試遷移到 Google Cloud 時，這只是一個小小的選擇。 因此，當我們決定遷移到 Google Storage 時，我們對存儲層進行了抽象，并遵循了 Google [Storage Migration docs](https://cloud.google.com/storage/docs/migrating) 的要求。 而且一切正常。 現在，無需更改代碼即可將代碼庫托管在 Google Cloud 和 AWS 上。 當然，您將不得不更改配置。 但不是代碼。 感謝您的來信。 因此，遷移到 Google 云的原因就在于此。 但是，需要對第 1 點進行說明。 你說什么意思 “我們喜歡基于“項目”的方法來管理不同應用程序的資源。它使訪問基礎架構更加務實。由于“動態掃描”功能的復雜性，它使識別實例更加容易。” 謝謝 anand @anand 你好 這里是“ dhilipsiva”。 對于我們的“動態掃描”功能，我們動態創建一個新實例，進行掃描，并在完成掃描后終止它（出于安全原因）。 在 AWS 中，您將必須創建一個網絡接口并將其分配給應該屬于同一 VPN 的實例（在創建實例時）。 使用 AWS 時，我們必須等待設備啟動，獲取 IP 并在啟動后繼續啟動掃描過程。 但是在 Google Cloud 中，無論何時創建實例，該實例都將自動可見，并且對同一 Project 中的其他實例也可以訪問[它會自動進行聯網]。 而且我們不必檢測 IP，我們可以將實例的“名稱”用作其他實例的域并進行訪問。 IP 不是必需的。 在這種情況下，我們不必等待任何事情。 只需將一些啟動腳本放入“動態掃描”實例中，一切便是事件驅動的。 不知道這是否能正確解釋這一點，但可悲的是，這就是我可以分享的所有信息：P 您可以尋找 Nginx + lua-resty-redis 而不是 nodejs。 縮放效果更好且非常輕便 嗨，吉里達爾，那是一個非常好的建議。 感謝分享。 一定會調查一下。 架構圖未完整顯示，工作子系統被隱藏了！如果顯示完整，將會更好！