Table of Contents
企業級軟件訂閲服務 (SaaS) 的開發 (3)
這篇文章繼續上一篇有關企業用軟件訂閲服務開發的探討，而這次談到可擴展性 (Scalability)。可擴展性就是當軟件服務的用量增加時，可以通過系統架構的調整去應付增加的用量。而對於企業軟件來說，用量增加也代表客戶增加，這裡會一同探討軟件服務會面對不同規模的客戶。
你負責的產品會賣給什麽樣的客戶，要看產品本身的市場定位，客戶可以大如跨國企業，也可小如初創公司。但是無論如何，其終究會遇到客戶規模差別很大的問題。
例如說你的產品是針對會計師設計的軟件，一個客戶可以是十多人的本地小公司，亦可能是過千人的跨國會計師樓。即使軟件本來只是針對小型公司的市場，但在產品發展的路途上，無論如何也有機會遇到大公司。大型公司能提出的豐厚條件下，你的企業／上司自然不會輕易放過這些機會。而如何讓你的軟件既能符合中小型公司的需要，也能滿足大公司的要求，就是問題所在。
根據常見的企業規模去區分，軟件的服務模式大致可以歸類為三大類別：
- 雲端共享服務 (Sharing Service)
- 雲端隔離服務 (Isolated Service)
- On-Premise
雲端共享服務 (Sharing Service)
共享服務正是多租戶模式 (Multi-tenancy)的部分所題到的資源共享設計，利用大量客戶去攤分服務的成本，令到單一客戶的成本可以降低。使用共享服務的客戶類型主要是初創／小型公司，他們不會投入大量資金去購買企業用軟件。在有選擇的情況下，他們多數會用較低價格或者免費的應用程式（例如他們傾向使用免費的 Google Docs，而不會購買 Microsoft Office）。共享服務能為客戶提供最實惠的軟件價格，但也因爲收費低廉甚至免費提供，共享服務的收益也會比較低。
另外，即使是大型客戶，在決定購買軟件前，都會希望有試用版，來測試軟件否適合他們。雲端共享就是一個很適合提供試用版的地方。當客戶滿意你的軟件時，就有機會花真金白銀購買，並要求轉至下文所題及到的隔離服務 (Isolated Service)，或者On-Premise 模式的服務。
共享服務如何應付流量與擴展
雲端共享服務的用量是根據客戶的數量而作出相應的增減，正常情況下 (產品的銷售理想時)，客戶不斷增加，服務器便會達到滿載的水平。所以系統的可拓展性對於雲端共享服務是必要的。不過可幸的是，現今各大雲端服務供應商都發展成熟，雲端服務的擴展其實非常容易。服務擴展有兩個方向：垂直方向 (Veritical)和水平方向 (Horizontal)。
垂直方向 (Veritical)：常稱爲Scale-up，增加服務器的處理性能以應付更多的用量，很簡單來說就是電腦太慢的話就升級硬件。現在的雲端服務 Scale-up 相當容易使用，基本上就是選擇你需要的硬件配置就可以，配置的變更不需要一分鐘就完成。
水平方向 (Horizontal)：常稱爲Scale out，增加電腦數量去分擔處理流量。Scale-out 有一個必須的基本配備，就是網絡負載均衡器（NLB — Network Load Balancer），它可以依照服務的狀態，把請求派發到不同的服務器進行處理。
和 Scale-up 一樣，Scale-out 也很容易使用，用戶可以簡單到拉動 Scrollbar 就能控制服務器的數量。
順便一提，Scale-out 的架構和之前所説到的多租戶模式 (Multi-tenancy) 並無衝突。只要能認清楚客戶的數據庫是哪一個的話，經由哪一臺服務器處理也沒有問題。
自動調整 (Auto-scale)
其實現在的大型雲端服務供應商都有提供自動調整的服務，亦易於設定。根據用戶的設定，再按運行中的服務器使用量，雲端服務就會自動去增加或者減少服務器的數目。如下面的設定，當CPU的用量多於75%的時候就只都增加一臺服務，低於25%的話就自動減少一臺，最少一臺，最大十臺。
自動調整除了在客戶量增加的時候大派用場外，還可以在流量降低時，相對地減少服務器數量。企業軟件通常都是在工作時間内的用量比較大，工作時間以外的流量會變得非常小。假設工作時間大約是 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)。
更多資訊可以留意 ONES Publication 定期發佈的文章，亦可以聯絡我們，我們的網址是： https://ones.software
]]>