# QuickBooks 平臺 > 原文： [http://highscalability.com/blog/2016/11/7/the-quickbooks-platform.html](http://highscalability.com/blog/2016/11/7/the-quickbooks-platform.html)  *這是 Siddharth Ram –小型企業首席架構師的特邀帖子。 [[受電子郵件保護]](/cdn-cgi/l/email-protection#114278757579706365794e63707c51787f656478653f727e7c) 。* QuickBooks 生態系統是最大的小型企業 SaaS 產品。 QuickBooks 平臺支持面向全球范圍內的小型企業，其客戶和會計師的簿??記，薪資和付款解決方案。 由于 QuickBooks 還是合規&納稅申報平臺，因此報告的一致性非常重要。財務報告要求查詢具有靈活性-給定的報告可能具有數十種可以調整的不同維度。 協作需要員工，會計師和企業所有者同時進行多次編輯，從而導致潛在的沖突。 所有這些都導致在 Intuit 解決有趣的縮放問題。 解決可伸縮性需要考慮多個時間范圍和軸。 擴展不僅涉及擴展軟件，還涉及人員可擴展性，流程可擴展性和文化可擴展性。 所有這些軸都在 Intuit 進行了積極的研究。 我們與員工的目標是營造一種氛圍，使他們能夠盡其所能。 # 背景 QuickBooks Online 產品已有十年半的歷史了。 它是作為整體構建的，沒有明確的關注點分離。 整體服務良好地服務于 Intuit –每天有數百萬的客戶使用它進行數億筆交易。 這部分是可能的，因為產品內置了泳道。 這允許按公式劃分比例（客戶在特定分片中“歸位”）進行縮放。 如今，我們可以將整體拆分為多種服務，并遷移到 AWS 作為主要托管解決方案。 ## 數字 * 全球小型企業最大的 SaaS 產品 * 超過 500 萬的臺式機和網絡客戶 * 每天處理 250M +請求 * 年增長率超過 40％ * 通過 AWS 進行全球擴展 * 全球約有 2,000 名工程師在產品上工作。 * 2000+ 3 個基于 Intuit 平臺構建的 和 參與者應用程序 ## 技術 * Java / JVM 是主要服務/后端 * 多語言持久性–不同的用例需要使用不同的存儲技術，QuickBooks 平臺將 RDBMS（Oracle / MySQL），Neo4J 和 Cassandra 用于 OLTP 和 Hadoop & Vertica 進行分析 * 前端已使用 ReactJS 進行了重建，我們了解到縮放不僅適用于后端-前端縮放是我們開發的一項新技能。 * 監控是使用多個內部和現成的工具完成的，現成的主要工具是 Splunk 和 New Relic * 通過企業 github 進行代碼管理 * ActiveMQ 和 Kafka 處理異步消息 * Ansible 和 Chef 用于配置管理 * 大量使用邊緣緩存和 Akamai WAA ## 文化 * 每個服務都有定義了 RTO 和 RPO 的 HA / DR。 我們每周執行 HA / DR 計劃，以確保在發生常規事件時對客戶的影響很小甚至沒有。 這是所有 SaaS 產品都需要計劃和執行的最佳實踐。 * 高度重視彈性。 服務不可用通常并不意味著客戶知道它。 * 服務在內部服務門戶中發布。 這使工程師可以重用其他團隊構建的服務，并減少服務克隆。 * 性能是根據 TP99，TP90 和 TP50（通常更高）來衡量的。 TP50 代表第 50 個 第 個百分位數的客戶體驗。 我們的目標是 1 秒的 TP50 和 2 秒的 TP90。 （即少于 10％的客戶在任何給定頁面上的頁面加載時間超過 2 秒）。 * 客戶互動失敗（FCI）是我們跟蹤的另一個關鍵指標。 與客戶（HTTP 4xx / 5xx）的每次失敗交互都被視為失敗交互。 我們的目標是使每項服務的 FCI 都低于 0.025％。 * 服務團隊擁有端到端的服務。 他們負責與 devops 模型一致的服務維護和正常運行時間。 PagerDuty 用于提醒呼叫人員出現問題和參與恢復。 * 您無法改善無法測量的內容。 通過近乎實時的儀表板，可以在公司的可用性，性能，可擴展性和質量指標方面廣泛了解公司。 這是驅動組織行為的關鍵。 * 我們正在過渡到反應性，松散耦合的系統 ，該系統可增強擴展能力。 但是，這需要仔細考慮如何處理系統中最終的一致性。 * 工程師對系統中的每個故障執行 RCA（根本原因分析）。 RCA 已由工程領導審核。 我們將 5 個“為什么”和“魚骨”應用于每個 RCA。 失敗是一位出色的老師 。 * 強烈的代碼意識和域所有權。 * 任務驅動。 當人們看到自己對客戶的影響時，便會盡自己最大的努力。 * 在質量，性能，可用性和安全性上絲毫不妥協。 * 持續部署和功能切換使我們能夠快速交付 ## 可伸縮性中的有趣挑戰 # 縮放比例特性 QuickBooks Online 之類的產品具有與其他 SaaS 產品不同的縮放特性。 報表查詢可能已應用了許多其他過濾器。 這些查詢在公司之間通常是不同的。 報告會產生稅收后果，因此必須始終與賬簿保持一致。 會計和小型企業所有者可能同時進行多次編輯，才能進行協作。 該軟件需要確定如何處理沖突。 所有這些導致在 Intuit 的 QuickBooks 平臺上進行擴展的有趣方式。 # 變量 QuickBooks 平臺為全球數百萬個小型企業，其客戶和會計師提供服務。 為客戶提供各種用例：產品需要解決的可變性包括： * 設備多樣性–我們根據需要為客戶提供服務-臺式機，移動設備，在線 * 地理多樣性–在全球范圍內使用，伴隨著法規的復雜性，要??解決的稅收往往非常本地化和專業化 * 合規性多樣性–不同的政府機構（例如工資稅）對合規性有不同的規定 * 產品多樣性–根據員工人數，他們所針對的市場性質（例如，基于產品的業務與基于服務的業務），不同的客戶群具有不同的需求 * 工作流的多樣性–公司可能擁有執行（并被授予）產品子集的工人。 例如，應收賬款業務員將僅看到應收帳款流量。 員工通常不執行業務報告。 這是我們處理的多樣性的子集。 盡管解決了很多多樣性問題，但平臺始終需要解決一些基本問題。 安全性，隱私性，可伸縮性和質量是軟件基本構建模塊的一部分。 # 縮放哲學 QuickBooks 平臺通常遵循“可擴展性多維數據集” 模型，在三個維度上進行縮放：  ## X 軸–只讀副本 X 軸主要用于只讀副本。 與許多 SaaS 產品一樣，與寫入次數相比，讀取次數很多。 常見的且相對昂貴的讀取操作是報告。 小型企業和會計師需要了解他們的業務狀況。 我們通過 QuickBooks Money Bar 提供見解，并通過大量報告（例如資產負債表，損益報告）提供更詳細的見解。 只讀副本使我們既可以減少訪問的熱點，又可以提供預先計算的報告 ## Y 軸-服務 擴展的第二個方面是在不同的服務中破壞產品。 QuickBooks 平臺建模為 14 個不同的域，這些域組成了產品。 服務 API 現在是第四個修訂版-V3 QuickBooks API 可以在 [http://developer.intuit.com](http://developer.intuit.com) 中找到。 ### Z 軸-公式拆分 Z 軸指的是“分片”（sharding）-允許大范圍縮放的非規范化數據。 QuickBooks 根據公司的屬性來拆分客戶。 然后，每個分片將與具有類似屬性的其他公司共享。 ### C 軸 除了這些方面，我們經常談論“ C”軸-文化軸，這是我們擴展規模的關鍵方法。 在 C 軸上對我們的主要增強是（a）度量文化–您無法解決無法觀察到的問題（b）通過 devops 模型擁有所有權的文化，以及（c）在我們所做的任何事情中客戶支持的思想。 ### 縮放前端 在 200KLOC 以上，QuickBooks onlike 具有非常大的 Javascript 占用空間。 擴展前端的一部分意味著要理解如何確保更改是隔離的并且組件可以重復使用，以至于 3 個 rd 參與者可以直接插入前端，并且 任何遵循規則的人都可以貢獻力量。 縮放還意味著在樣式上具有統一性，易于堅持。 ## 公有云之旅 Intuit 的一項關鍵策略是將所有軟件資產移至 AWS。 在公共云中，給定共享的基礎架構，還需要考慮安全性和隱私性。 在將軟件遷移到 AWS 時，我們使用以下一般原則： * 必須保護每個端點。 在公共云中，我們不能假設服務之間的鏈接是安全的端點。 * 每個 Intuit 和 AWS 平臺服務都必須是可觀察的。 這種可觀察性是能夠分析欺詐和安全性訪問的關鍵。 * 提升并移動+分解。 在適當的情況下，我們將分解為服務并遷移到公共云。 對于較大的系統，我們進入 AWS 基礎架構并就地分解。 * 多區域 DR。 區域中斷發生。 我們希望即使在單個地區受到影響時也能夠提供服務。 * 在本地服務客戶。 安全港 和性能都決定了靠近客戶的數據存儲。 這要求客戶必須在本地區域“回國”（例如，在歐洲的 AWS 數據中心外服務的歐盟客戶）。 * 爆炸半徑遏制。 “無共享”方法可確保我們限制爆炸半徑。 系統中斷應該導致本地事件，而不是全局事件。 ## 主要課程 * 3 軸縮放是關鍵。 知道哪些軸適用于正確縮放有助于縮放。 * 確保可以控制影響。 必須充分理解和測試系統的爆炸半徑。 * RCA –失敗是一位了不起的老師。 浪費失敗的教訓是可恥的。 架構師負責分析故障并找出根本原因。 * 不要低估重新考慮在公共云中保護軟件的數量。 * Dogfood。 公司工程師使用的服務應與為 3 個 和 參與方開發人員提供的服務相同。 * 了解您的 KPI 并能夠預測性能曲線的樣子–這有助于快速識別出問題所在。 * 也可以縮放前端，而不僅僅是后端。 嗨，感謝您的帖子，它非常有用。 我想知道為什么您同時使用 ansible 和 Chef，因為我希望一家公司同時使用其中一種？ 嗨，查理， 并沒有 Ansible 和 Chef 的強烈技術理由。 不同的團隊使用了不同的技術。 隨著時間的流逝，我們將逐步淘汰其中之一。 悉達思 您好 Siddharth， 感謝您花時間描述系統。 由于您將整體拆分為服務，因此如何管理服務之間的安全性和身份驗證？ 嗨， 好問。 在整體中，通信相對容易-只需進行另一個函數調用即可。 在分布式系統中，難度會增加一些-但技術仍然非常相似。 身份驗證和安全協議是非常標準的。 Intuit 管理自己的身份系統。 每個請求必須具有身份驗證上下文-包括服務器-服務器調用。 這些將很快到期，并分配新的票證。 SSL / TLS 是用于有線加密，客戶端-服務器以及服務器-服務器通信的標準問題。 分析/監視查找訪問模式中的異常。 您如何管理服務之間的安全性和身份驗證？ 據我所知，Intuit 使用 google oauth1.0 進行身份驗證，這基本上是基于令牌的身份驗證系統。 例如，您有一個使用者密鑰和一個使用者密鑰，您獲得一個請求密鑰和請求令牌，然后吐出一個訪問令牌和訪問密鑰。 令牌有效期為 6 個月，不確定令牌何時到期才能訪問那些基于 JAVA 的 REST API 和安全標準 SHA2 算法。 我寫了一篇關于 SSL 握手的文章。 它應該有助于提供見解。 參考： https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/ 嗨， 很棒的文章，感謝您的分享，您可以解釋一下是否有建立另一個 QuickBooks 或 Zoho Books 的范圍？ 謝謝， Divya， [Quickbook Developer](http://www.catchexperts.com/quickbook-online-training)