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

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

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

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

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

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

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

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

SaaS的關(guān)鍵設(shè)計(jì)注意事項(xiàng)

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

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

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

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

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

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

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

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

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

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

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

SaaS的DevOps注意事項(xiàng)

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

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

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

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

SaaS的其他注意事項(xiàng)

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

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

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