云應(yīng)用程序SaaS的設(shè)計方法

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

如何設(shè)計云應(yīng)用程序（SaaS）

如何設(shè)計云應(yīng)用程序（SaaS）

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

為云設(shè)計應(yīng)用程序與本地應(yīng)用程序設(shè)計有何不同？

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

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

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

SaaS的關(guān)鍵設(shè)計注意事項

· 選擇適當?shù)脑品?wù)：當然，您正在部署到云。 但是，您想使用哪些服務(wù)？ 您是否只是要使用基礎(chǔ)架構(gòu)即服務(wù)（IaaS）？ 還是要利用某些平臺即服務(wù)（PaaS）功能？ 答案可能并不總是直截了當?shù)摹?因此，這里有一些準則。

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

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

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

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

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

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

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

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

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

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

SaaS的DevOps注意事項

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

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

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

· 敏捷的基礎(chǔ)架構(gòu)：要在SaaS上取得成功，您需要確保您的基礎(chǔ)架構(gòu)是敏捷的并且可以應(yīng)對需求的變化。 隨著需求上升，它可以擴展適當?shù)膶?，當需求下降時，釋放不需要的資源。 這需要一定程度的實驗和測試才能達到適當?shù)钠胶狻?例如，您可以使用AWS自動擴展功能自動擴展/縮減基礎(chǔ)架構(gòu)。

SaaS的其他注意事項

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

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

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