SaaS的可擴展性:如何使你的軟件不論初創企業還是跨國公司都能支援得到?


企業級軟件訂閲服務 (SaaS) 的開發 (3)

Photo by Alex Kotliarskyi on Unsplash


這篇文章繼續上一篇有關企業用軟件訂閲服務開發的探討,而這次談到可擴展性 (Scalability)。可擴展性就是當軟件服務的用量增加時,可以通過系統架構的調整去應付增加的用量。而對於企業軟件來說,用量增加也代表客戶增加,這裡會一同探討軟件服務會面對不同規模的客戶。

你負責的產品會賣給什麽樣的客戶,要看產品本身的市場定位,客戶可以大如跨國企業,也可小如初創公司。但是無論如何,其終究會遇到客戶規模差別很大的問題。

例如說你的產品是針對會計師設計的軟件,一個客戶可以是十多人的本地小公司,亦可能是過千人的跨國會計師樓。即使軟件本來只是針對小型公司的市場,但在產品發展的路途上,無論如何也有機會遇到大公司。大型公司能提出的豐厚條件下,你的企業/上司自然不會輕易放過這些機會。而如何讓你的軟件既能符合中小型公司的需要,也能滿足大公司的要求,就是問題所在。


根據常見的企業規模去區分,軟件的服務模式大致可以歸類為三大類別:

  • 雲端共享服務 (Sharing Service)
  • 雲端隔離服務 (Isolated Service)
  • On-Premise

雲端共享服務 (Sharing Service)

Photo by Samuel Zeller on Unsplash

共享服務正是多租戶模式 (Multi-tenancy)的部分所題到的資源共享設計,利用大量客戶去攤分服務的成本,令到單一客戶的成本可以降低。使用共享服務的客戶類型主要是初創/小型公司,他們不會投入大量資金去購買企業用軟件。在有選擇的情況下,他們多數會用較低價格或者免費的應用程式(例如他們傾向使用免費的 Google Docs,而不會購買 Microsoft Office)。共享服務能為客戶提供最實惠的軟件價格,但也因爲收費低廉甚至免費提供,共享服務的收益也會比較低

另外,即使是大型客戶,在決定購買軟件前,都會希望有試用版,來測試軟件否適合他們。雲端共享就是一個很適合提供試用版的地方。當客戶滿意你的軟件時,就有機會花真金白銀購買,並要求轉至下文所題及到的隔離服務 (Isolated Service),或者On-Premise 模式的服務。

共享服務如何應付流量與擴展

雲端共享服務的用量是根據客戶的數量而作出相應的增減,正常情況下 (產品的銷售理想時),客戶不斷增加,服務器便會達到滿載的水平。所以系統的可拓展性對於雲端共享服務是必要的。不過可幸的是,現今各大雲端服務供應商都發展成熟,雲端服務的擴展其實非常容易。服務擴展有兩個方向:垂直方向 (Veritical)水平方向 (Horizontal)

垂直方向 (Veritical):常稱爲Scale-up,增加服務器的處理性能以應付更多的用量,很簡單來說就是電腦太慢的話就升級硬件。現在的雲端服務 Scale-up 相當容易使用,基本上就是選擇你需要的硬件配置就可以,配置的變更不需要一分鐘就完成。

Azure Cloud Service Vertial Scaling

水平方向 (Horizontal):常稱爲Scale out,增加電腦數量去分擔處理流量。Scale-out 有一個必須的基本配備,就是網絡負載均衡器(NLB — Network Load Balancer),它可以依照服務的狀態,把請求派發到不同的服務器進行處理。

和 Scale-up 一樣,Scale-out 也很容易使用,用戶可以簡單到拉動 Scrollbar 就能控制服務器的數量。

Azure Cloud Service Horizontal Scaling

順便一提,Scale-out 的架構和之前所説到的多租戶模式 (Multi-tenancy) 並無衝突。只要能認清楚客戶的數據庫是哪一個的話,經由哪一臺服務器處理也沒有問題。

Scale-out with Multi-tenancy

自動調整 (Auto-scale)

其實現在的大型雲端服務供應商都有提供自動調整的服務,亦易於設定。根據用戶的設定,再按運行中的服務器使用量,雲端服務就會自動去增加或者減少服務器的數目。如下面的設定,當CPU的用量多於75%的時候就只都增加一臺服務,低於25%的話就自動減少一臺,最少一臺,最大十臺。

Azure VM Autoscale 

自動調整除了在客戶量增加的時候大派用場外,還可以在流量降低時,相對地減少服務器數量。企業軟件通常都是在工作時間内的用量比較大,工作時間以外的流量會變得非常小。假設工作時間大約是 09:00 — 18:00,餘下的時間就可以把服務器數量大減。服務器的價格是按照運行時間(分鐘)來算的,所以這樣可以進一步縮減服務器的成本。

數據庫

使用共享雲端服務的用戶大都是中小型公司,所以不太可能會發生數據庫應付不了的用戶。比較容易發生的倒是數據庫服務器應付不了太多客戶的問題。這裏的處理方法不難。例如我們訂明一個數據庫服務器最多只會運行100個客戶的數據庫。當該數據庫超過100個客戶時,我們就另外他添加一個數據庫服務器去處理。每一個數據庫服務器再根據他自身的用量來進行 Scale-up / down,以作調整服務器的性能和成本。

儲存空間 / 其他雲端服務

根據實質情況,你還可能使用很多不同的雲端服務,如檔案上載儲存服務 (e.g. Blob Storage,Amazon S3) ,或者處理媒體檔案的服務 (e.g. Azure Media Service, Amzon Media Service,etc) 。這些雲端服務等同於微服務 (MicroService) ,基本上不會出現遠超負荷的問題,因為它們的設計是要服務所有雲端的用戶。所以在考慮服務器負荷的時候,就毋須煩惱這類雲端服務。不過,這些服務的用量和價錢都成正比,所以在控制成本方面,就要多花時間留意。


隔離服務 (Isolated Service)

隔離服務是上一篇提到的 單一住戶模式(Single-Tenacy),使用隔離服務的公司主要是中型至大型公司,這些公司會按自己的需要,投放資源來購買企業軟件。這些公司爲求確保他們的服務質素,往往願意付出相對高的價錢,要求軟件供應者為他們在雲端設立專用服務器,並分割一定量的資源在專門服務這些公司

而在隔離服務的範圍内,可擴展性的重要性反而不大,因爲客戶的用量基本上都是固定的,亦比較容易估算。通常不會出現突然用量大增,而導致系統超出負荷的情況發生。即使需要做到自動擴展,做法也和上文提到的共享服務相差不多。而隔離服務的優劣就在講單一租戶模式的時候就提到過,這裡就不重複了。


On-Premise

當公司規模去到大公司/跨國企業時,他們會非常重視資料保密,也不會隨意把企業的資料放上公共的雲端服務。他們會要求把軟件發佈到他們公司的私人雲端 (Private Cloud),或者他們的數據中心 (Data Center) 。其實這就是回歸到傳統的服務器架構,確實有點脫離了現代雲端服務其攤分成本的概念。但從另外一個方向來看,這些大公司往往已在使用大量不同的系統,所以他們實際上是和自己公司的其他軟件去攤分,而不是和別的公司去攤分成本。

On-Premise 已經不是軟件訂閱服務所應討論的範圍,在此不贅。不過如果你的軟件服務是針對企業用戶的話,On-Premise 是必然會遇到的課題。關於 On-Premise,還待日後再談。


總結

可擴展性對於產品的發展起到很關鍵的作用。基於軟件訂閲服務攤分成本的概念下,你的服務越吸納更多客戶,平均服務器成本也會越來越低,價格有下調的空間,服務也就會更有吸引力。

接下來大家討論和可擴展性不可分離的 高可用性 (High availbility)

Leave a Reply

Your email address will not be published. Required fields are marked *