最初發(fā)布于Cloud Nine Apps。

如何設計云應用程序（SaaS）

如何設計云應用程序（SaaS）

軟件即服務（SaaS）已成為許多軟件供應商的主要模型。 與云供應商提供基礎架構服務一樣，它有助于類似地交付軟件。 SaaS應用程序通常部署在公共云上，例如Amazon Cloud（AWS），Microsoft Azure，Google Cloud等。 但是，組織有時可能會選擇使用其數(shù)據(jù)中心（也稱為私有云）來托管SaaS應用程序并利用其在基礎架構上的投資。 在設計SaaS應用程序時，不僅需要將應用程序比特部署到云中，還需要花費更多。 進行適當?shù)脑O計考慮，不僅可以幫助您完成良好的設計，還可以幫助您降低成本并更有效地管理部署。 在這篇文章中，我將介紹一些多年來我發(fā)現(xiàn)有用的設計SaaS應用程序的關鍵注意事項和技巧。

為云設計應用程序與本地應用程序設計有何不同？

· 更好的模塊化：如果您擁有一個龐大的單片應用程序，那么明智的做法是查看它是否可以分解為可以單獨部署的邏輯組件。 這不僅可以提高模塊化，還可以幫助您減少應用程序的占用空間。 假設您有一個使用后臺作業(yè)刷新數(shù)據(jù)的應用程序。 您可以將核心應用程序和后臺作業(yè)分離為2個（或更多）可以分別部署的組件。 這將減少核心應用程序的占用空間。 因此，您可能會選擇較小的資源大小。 另外，根據(jù)需要，您可以獨立地縮放這兩個。 因此，如果對后臺作業(yè)的需求增加，則可以增加其容量，并增加應用程序層的容量。 由于每個資源的資源量都很小，因此，僅擴展所需的層/組件將導致整體成本低于整體資源的整體成本。 說得通？

· 應用程序始終是最新的：對于許多本地應用程序來說，這是一個很大的轉變。 在云中，客戶通常希望應用程序始終處于最新版本。 現(xiàn)在，如果您將其視為一名架構師，則意味著您不僅可以更新應用程序位，而且可以在不涉及客戶的情況下升級客戶數(shù)據(jù)。 也就是說，這對他們是完全透明的。

這些只是一些差異。 但是，您明白了。

SaaS的關鍵設計注意事項

· 選擇適當?shù)脑品眨寒斎唬诓渴鸬皆啤?但是，您想使用哪些服務？ 您是否只是要使用基礎架構即服務（IaaS）？ 還是要利用某些平臺即服務（PaaS）功能？ 答案可能并不總是直截了當?shù)摹?因此，這里有一些準則。

· 您是否要將同一應用程序部署到多個云平臺或內部部署？ 在這種情況下，可能沒有（或最小化）特定于云供應商的服務并堅持使用更多的IaaS服務是有意義的。

· 成本應該是選擇服務時的重要考慮因素。 例如，某些由Cloud供應商管理的PaaS服務可以由您的團隊自己管理，以降低成本。 盡管這對于每項服務可能都沒有意義，但值得探討。

· 牢記您的團隊專業(yè)知識。 使用某種云服務需要什么？ 而且，如果團隊還維護基礎架構，那么需要什么技能？

· 針對故障的設計：設計容錯和高可用性的應用程序是Cloud的基礎。 假定您的應用程序會遇到問題，以及如何確保繼續(xù)為用戶提供服務。 這些可能是應用程序故障或基礎架構故障。 云供應商提供了一些有用的功能來幫助您。

· 使用負載平衡器：出于負載平衡的目的，您可以將應用程序節(jié)點放在負載平衡器的后面，并確保即使一個或多個節(jié)點出現(xiàn)故障，也可以通過其他節(jié)點為應用程序提供服務。

· 地理分布的應用程序：多個Cloud供應商提供了將應用程序分布在多個地理區(qū)域的功能，這樣，即使一個區(qū)域受到了影響（例如，由于自然災害），也可以從其他區(qū)域提供應用程序。 例如，AWS支持跨多個可用區(qū)部署應用程序。

· 模塊化您的應用程序：如我們在上一節(jié)中討論的，隔離可以分別部署和管理的組件可以幫助減少應用程序的占用空間，從而降低基礎架構的成本。 您也可以考慮將其中一些組件作為微服務。 如果您的應用程序之外還有其他潛在使用者，則微服務方法可能特別有用。 現(xiàn)在，這并不意味著您會全力以赴，創(chuàng)建不必要的組件。 因此，一種方法是制作可以單獨部署的組件（例如核心應用程序與后臺作業(yè)）。

· 安全性：安全性涉及很多方面-從保護基礎結構到應用程序。 一些關鍵方面包括確保僅打開所需的端口，使用對資源的盡可能少的特權，進行適當?shù)幕诮巧脑L問控制，使用加密，等等。 安全性不應被視為一次性交易。 這是一個持續(xù)的過程，應該隨著時間的推移而改進和發(fā)展。

· 多租戶：在云中運行的一個主要好處是能夠使用同一應用程序實例為多個客戶提供服務。 這給應用程序設計帶來了一些明顯的挑戰(zhàn)，以確保每個客戶的數(shù)據(jù)出于安全和監(jiān)管目的而被隔離。 一些團隊選擇為每個客戶使用不同的持久性存儲實例，例如為每個客戶使用單獨的數(shù)據(jù)庫。 而且，有些人選擇使用行級標識符隔離數(shù)據(jù)。 無論采用哪種方法，重要的是確保體系結構滿足可伸縮性和安全性需求。 例如，如果選擇每個客戶使用一個數(shù)據(jù)庫，則可以在一個RDS實例上托管多個數(shù)據(jù)庫。 而且，當容量用盡時，您可以建立另一個RDS實例。

· 零/最小停機時間和無縫升級：信不信由你，許多客戶期望SaaS應用程序的停機時間為零或非常小，并且由于這些停機時間通常由構建應用程序的同一公司管理，因此應進行無縫升級。面臨的挑戰(zhàn)是您的應用程序可能沒有被設計為能夠順利處理升級，特別是如果它已被轉換為SaaS應用程序而已。需要考慮兩個關鍵方面：a）部署應用程序位和文件b）處理持久性存儲升級。對于推出應用程序位策略，可以使用諸如Blue / Green部署之類的策略，其中，如果成功推出，則將新版本部署到新堆棧中，進行測試并啟用。較舊的堆棧資源可以在以后退役并回收。實現(xiàn)無縫升級的一種方法是使基礎數(shù)據(jù)模型n_1兼容。這意味著，如果要部署的發(fā)行版具有數(shù)據(jù)模型版本n，則該數(shù)據(jù)模型與先前的數(shù)據(jù)模型版本（n — 1）向后兼容，從而確保升級不會破壞它。您如何確保？這就要求在整個開發(fā)周期中遵守紀律，并遵循某些準則，例如不刪除任何列，提供必要的升級腳本來處理任何數(shù)據(jù)遷移需求，等等。并且，如果升級未成功，則支持回滾升級。現(xiàn)在，您可以理解，這不僅在技術上具有挑戰(zhàn)性，因為它涉及數(shù)據(jù)遷移和回滾，而且還可能導致部署速度大大降低。因此，您必須仔細評估適合您的應用程序需求的合理方案，并相應地實施解決方案。

SaaS的DevOps注意事項

DevOps對SaaS至關重要，因此值得單獨討論。 以下是一些關鍵注意事項。

· 持續(xù)交付：DevOps管道應該能夠獲取簽入的代碼，并從中生成一個構建，然后以自動化的方式經歷各個階段（QA，性能，最終通過/不通過檢查，生產部署）。 這可能涉及到擁有多個管道（通常是每個階段），并擁有一個超級管道來推動構建通過這些階段中的每個階段。 現(xiàn)在，開發(fā)這些管道可能還需要一些時間，但是開始為每個管道定義合同是一個好主意，這樣用戶管道就不必擔心細節(jié)了。 最終，目標應該是使雙手完全免于打擾或盡可能地接近手。

· 對所有版本（包括DevOps更改）使用版本控制：對于應用程序代碼，通常最好使用源代碼控制的master分支。 但是，對于任何DevOps更改執(zhí)行相同的操作同樣重要。 例如，在推出基礎架構更改時，還應將這些更改檢入源代碼管理中，進行測試，然后將其推向生產環(huán)境。

· 敏捷的基礎架構：要在SaaS上取得成功，您需要確保您的基礎架構是敏捷的并且可以應對需求的變化。 隨著需求上升，它可以擴展適當?shù)膶樱斝枨笙陆禃r，釋放不需要的資源。 這需要一定程度的實驗和測試才能達到適當?shù)钠胶狻?例如，您可以使用AWS自動擴展功能自動擴展/縮減基礎架構。

SaaS的其他注意事項

· 計劃和優(yōu)先級：與其他任何成功的項目一樣，SaaS項目也需要計劃和優(yōu)先級。 盡管每個人都希望實現(xiàn)"將每一個檢查都投入生產"之類的目標，但要了解什么才是最有意義的事情，并首先將重要的事情放在優(yōu)先位置。 當然，有一個延伸目標沒錯。 但是，重要的是首先正確處理重要的事情。 例如，如果您沒有良好的單元測試和自動化范圍，并且您試圖將每個代碼更改推向生產環(huán)境，即使您完成了更改，其實用性也值得懷疑。 之所以會適得其反，是因為生產中的事情可能會開始崩潰得太快，然后研發(fā)團隊將被消耗掉。

· 貨幣化模型：SaaS也影響貨幣化模型。 在內部部署中，您可能會被罰款一定數(shù)量的許可證，而在SaaS中，您可能不得不重新考慮什么是最適合您的業(yè)務的模型。 您是否要使用基于訂閱的模型，基于利用率的模型，混合模型或其他所有模型？

希望您對設計基于云或SaaS的應用程序有更好的了解。 看到涉及許多不同方面的應用程序投入生產，無疑是一種豐富的體驗。 就像我經常說的那樣，"云是一個旅程，而不是目的地"。 因此，請繼續(xù)學習并不斷發(fā)展。