開源概念為我們帶來了什麽?

相比傳統軟件一次收費或定期訂閱收費,開源軟件走的是截然不同的方向。而明顯的是,不同商業巨頭亦開始樂意走進這條新路。
Photo by Philipp Berndt on Unsplash

一般的用家可能會對 open source 開源這個概念感到疑惑:正常在市面上的軟件,不論是遊戲、文書、作業系統,通常都是收費,由以前一次收費到現在流行的 Software as a Service (SaaS)定期訂閱收費模式。這些軟件不會讓你直接接觸到軟件的源碼,所有源碼都加密好才推出市面,以免其他人能夠輕易複製自己的軟件作其他用途。有些公司甚至透過購買其他公司的源碼專利,以作為賺錢的途徑。

“Org charts” comic by Manu Cornet

不過,開源軟件就是走傳統軟件的相反方向:它任由他人取用軟件本身的源碼,在指定的軟件協定下(如BSD授權條款)保留一部分權利,而允許他人以學習、修改和以任何目的向任何人分發該軟件,並常常在網絡的互動社群中被公開和合作開發、改良。最有代表性的軟件莫過於網頁瀏覽器 Mozilla Firefox 和 行動作業系統 Android。

雖然有不少大型商業機構仍然禁止員工使用開源軟件,皆因其安全度未必能夠合乎這些機構的要求,而要事先進行大量安全測試。但是有如德國聯邦政府、巴西各政府、大學等都積極鼓勵員工使用開源軟件,除了減免一些購買軟件的費用之外,他們亦希望減少對外國公司軟件的依賴。

開源軟件漸漸受大型商業機構認可,甚至視為金蛋。今年7月 IBM就以每股190美元、 總值340億美元收購知名開源作業系統的開發商 Red Hat,以共同開發次世代的混合雲端平台。2018 微軟亦花了75億美元收購代管眾多開源軟件源碼的服務平台 GitHub,以擺脫多年來相對封閉的形象,亦強調 GitHub 會「加強對開發者自由、開放、創新程度」, 秉持開發者優先的精神,與微軟各自保持獨立的營運模式。由此可見,商業機構現在已經視開源為一種使到其本身得以活化的龐大資源。

Joining forces with IBM gives Red Hat the opportunity to bring more open source innovation to an even broader range of organizations and will enable us to scale to meet the need for hybrid cloud solutions that deliver true choice and agility. - JIM WHITEHURST, PRESIDENT AND CEO, RED HAT

RISC-V處理器原型

開源的概念亦已不限於軟件的領域,RISC-V就是一個 「開源硬體」的例子。同樣地,一般ARM和MIPS等商業晶片供應商因為設計CPU時牽涉不同專業範疇,所花的資源龐大,這些供應商自然要對使用其專利、版權的人士,收取高額的授權費用,才能得以生存。使用其具優點的設計檔案和指令集前,亦簽署保密協定,以保障供應商的權益。但這些傳統的保護手法,卻窒礙開發公共、低成本、自由及開放的源碼軟體編譯器和作業系統。 RISC-V 就在開拓「開源硬體」的前提底下得以誕生。

RISC-V 架構簡單、完全開源,允許任何人設計、製造和銷售RISC-V晶片和軟體而不必支付任何公司專利費之下,得到不少科技巨頭的支援。 Google、高通、微軟、華為、阿里巴巴、輝達等都加入 RISC-V 基金會。在印度政府的大力資助下,RISC-V 更成為印度的國家指令集。微軟亦以 OpenPOWER Foundation 的名義作為領軍, 推動其 Power微處理器架構發展,今年更宣布併入Linux基金會, 並以開源Power晶片的指令集架構(ISA) ,來實現無需支付專利費用Power晶片。

當前如ARM、Intel這類大型商業晶片供應商霸佔不少平板電腦、智能電話的處理器市場,而在IoT即將大行其道之下,晶片的需求更是與日俱增。 RISC-V、Power晶片等「開源硬體」的出現,正正能夠帶入晶片界的競爭,使得整體開發成本降低,在經濟方面有莫大的裨益,而開發成本降低有助推進如人工智能、超級電腦、資料分析以及 IoT 科技發展。

「開源硬體」亦解決當前一些地緣政治的問題:美中雙方的科技戰愈演愈烈,但在這些兩大政治勢力衝突底下,不少環球軟件、硬件公司遭殃。 2018年的中興事件以及華為事件, 更令中國不得不尋找新的硬件出路。

以RISC-V 基金會中國顧問委員會主席方之熙之言:

 一條就是關起門來自己做,典型的就是龍芯。因晶片還是商品,效能再高,沒人用就沒有價值,所以必須有相應的生態系統發揮價值。第二條路就是跟在別人後面,中國有許多公司做 x86、Arm、IBM Power 晶片,在某些特殊領域,用這些指令集架構確實可以做一些事,但受 ISA 所屬公司知識產權(IP)的控制,很難取得成功。

而 RISC-V 這類「開源硬體」 沒有知識產權的限制,使得如中國、印度等這類未有能力完全自製晶片的國家,得以在一定的共同基礎上,各自開發其晶片,減少對外來科技的依賴。這以使得各地的科技發展,能夠減少因為地緣政治的改變,而受到的各種負面影響。

而引入「開源」概念,亦能為本身科技偏向封閉的企業文化有所改善,使得用家能夠藉其公開的功能部分與其他產品比較。這能夠令到不同的科技產品可以透過公開驗證,增加本身的透明度以及市場競爭力。

開源這個概念能夠為我們帶來更自由、開放、創新的科技發展基礎,改善科技研發環境,同時能夠為已有科技產業注入嶄新的動力。可見將來各地的企業能夠突破以往的商業限制,整個科技的發展進程或能因此而有所裨益。


我們 ONEs Software 是一家香港的軟件開發公司,致力於通過我們專業的技術,為企業設計出最合適的軟件。如果您有興趣,歡迎與我們聯繫一起探討,為您的企業成長注入新的源動力。 更多資訊可以留意 ONES Publication 定期發佈的文章,亦可以聯絡我們,我們的網址是: https://ones.software

ONES Publication
We share what we have learned about app and web development. Find us in ones.software. Email: hello@ones.software

]]>

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)

更多資訊可以留意 ONES Publication 定期發佈的文章,亦可以聯絡我們,我們的網址是: https://ones.software

]]>

SaaS的多租戶模式(Multi-tenancy)實踐:.NET Core + Entity Framework Core

企業級軟件訂閲服務 (SaaS) 的開發 (2)
多租戶模式 (Multi tenancy)

我們於上一篇提過關於多租戶模式 (Multi tenancy) 的各種好處,今日我們就來談談如何去實際架構出一個多用戶模式的服務器架構,並能實現客戶獨立穩健、容易維護的特點。


多用戶模式的實現方法可以分爲幾種:

  1. 服務器使用同一個域名 (Domain Name),在每一個請求 (Request) 裏面都加上一個 TenantId 的參數作分辨。
  2. 服務器使用同一個域名,然後以不同的用戶ID 來作區分。
  3. 服務器接受不同域名,每個客戶都給予他一個專屬域名,並以域名去區分

這裏會示範實現第三個方案,其優點有:

  • 可以用不同子域名 (Sub-domain) 去分給不同用戶,例如 tenantA.example.com,tenantB.example.com。如果請求裏面加有用戶的名字的話,能夠讓用戶感覺方案是他們專有的服務。
  • 如果客戶自己公司有想用的域名的話,也可以使用。只要在他們的域名服務器 (Domain Name Server)上,把域名指到我們服務器的地址便可。
  • 對服務器來説,只要小心處理,用哪個方案差別都不大,但是在瀏覽器 (Browser)上差別就很大。方案 1 和 2 都是使用同一個域名進入,即使所有客戶不同,他們在瀏覽器上的 Cookie 或者 Local Storage 的空間都是共通。雖然説在實際環境中,同一臺電腦登入不同客戶的情況非常罕見。但一旦登入不同客戶,就很容易發生資料有衝突。這樣的話,就不容易達到客戶獨立這個條件。相反方案 3的話,每一個客戶都使用不同的域名,在瀏覽器上的的存取空間也會是獨立的,就不會發生以上的問題。

閒話休提,要開始實際示範了。這個示範架構的概念是「靠頂端判斷租戶資料,再於末端去進行分類處理」。這裏我們會利用 .Net Core + Entity Framework Core 來實現一個多租戶模式的例子。這個例子要符合三個要求:

  1. 根據不同請求域名 (Request Host Name),返回對應的客戶資料,如名字;
  2. 根據不同域名,存取不同的數據庫 (Database)
  3. 根據不同域名,上載和下載檔案(File) 進去不同的文件夾 (Folder)

實際操作

1.首先打開 Visual Studio,新增一個 .Net Core 的 Project,這裏我們用 2.2版本。

2.定義 Tenant (租客),裏面存放了該客戶的資料,如客戶名字數據庫的地址 (ConnectionString),存取檔案的文件夾,和這個客戶接受的所有域名。

3.定義TenantContext,用來緩存當前的Scope現在是哪一個租戶。

4.定義TenantResolver,來根據不同的域名去搜尋自己屬於哪一個租戶。這裏爲了方便示範,所有直接加入了兩個客戶的資料在這裏,但正式應該要讀取一個額外儲存所有租戶資料的檔案,或者是連接到一個遠端的租戶管理服務器,來讀取租戶資料。

這裏的例子,如果是經過 localhost:5000 進來的就是客戶A,localhost:5001進來的就是客戶B。

5. 到這裏爲止,就有了最基本的構成了。然後就是如何去判斷請求是屬於哪一個租戶,這裏使用中間件 (Middleware),來定義一個HttpTenantResolveMiddleware 去判斷。

在 HttpContext 裏面能夠找回當前 Request 的 HostName,並通過TenantResolver 裏是屬於哪一個 Tenant,最後放進去 TenantContext 裏面便可。

6.在 startup.cs,把之前定義的 Class 都加進去依賴注入,TenantResolver 用 Singleton,其他的用 Scope。

這裏有一個巧妙的地方,就是把 TenantContext 裏面的 Tenant 再放進Scope裏面,這樣就可以更直接的在拿到當前 Scope 的租戶。

7.加入 HttpTenantResolveMiddleware 進流水綫 (Pipeline)。判斷 Tenant這個流程,越早階段做越好,所以這裏直接放到第一位。

8. 這楊就可以開始簡單的測試一下。首先在 launchSetting 裏面加上兩個Tenant 的 Url。

定義一個測試的 Controller,裏面直接 注入 (inject) Tenant 進去就可以了。

然後就可以看到測試結果。同一條路徑,同一個服務器,但經過不同域名的請求,返回不同租戶的資料。

到這裏,基本的租戶分類就完成了。


數據庫存取  — Entity Framework Core

接著來示範一些對 Db 的實際操作,這裏用 SqlServer 來做示範。

1.要加入三個 Entity Framework Core 需要的 Nuget Project。

2.我們就定義一個簡單的 TenantDbContext 的數據庫,裏面有一個 Key value pair 的表。

3.在 startup.cs 裏面注入 TenantDbContext。平時的 Entity Framework 教學裏,都會在這裏加入數據庫的地址 (connectionString) 加進去,但我們就不在這裏加。

4. 再來一個小竅門,在 TenantDbContext 也注入 Teannt。覆蓋掉原來的 OnConfiguring,在這裏用 Tenant 裏面的 ConnectionString 去指定數據庫路徑。

5.然而,如果現在直接運行 add-migration 去添加 MIgration 的話,就會發生錯誤。因爲在沒有請求的時候,是不會知道現在是屬於哪個租戶,和應該連去哪個 DB。

但其實這個問題很容易解決。只要加一個 Class 去Implement IDesignTimeDbContextFactory<TenantDbContext> 就可以。在運行 add-migration的時候,就會根據這裏去創建 TenantDbContext,只要在這裏給一個假的住戶資料進去,add-migraiton 的時候就可以靠這個Tenant的數據庫路徑,去計算 Migration。

Migration 成功做出來了!

6.然後就到建立的數據庫的時候。在startup.cs configure 的最後階段,對每一個 Tenant 都創造一個新的 Scope,將該 Tenant 放進 TenantContext,再運行 Migration 就可。

運行完後看一看 SSMS,兩個客戶的數據庫都應能成功創造出來。

7.開始實際測試,做一個測試數據庫的 Controller。如果熟悉 Entity Framework的人就會發現,在這裏對 Entity Framework 的用法和平時的用法沒有任何分別

測試開。預先將設了客戶A的 hello=I’m Tenant A, 然後就可以看到不同的域名拿到的結果是不一樣,兩個數據庫是完全分開的。

檔案存取

1.這個做法也很簡單,做一個 TenantFileService,也是一開始就注入Tenant。這裡都用 Tenant 裏面的 FileDirectory 作爲路徑的基礎。

2. 在startup.cs的加到 Dependency Injection 裏面。

3.實際測試,和數據庫的測試一樣,也是 Controller 注入TenantFileService,直接使用便可。

大家可以看到經過不同的域名上載的檔案,會分別放進不同的文件夾裏面。


總結

上一篇裏面提到過,儘管是在多租戶模式(Multi Tenancy)的環境下, 用戶資料的安全和保密還是最重要的考慮。而這個例子的示範的系統架構,就正正是爲了達到這個目的。

裏面提到過,儘管是在多租戶模式(Multi Tenancy)的環境下, 用戶資料的安全和保密還是最重要的考慮。而這個例子的示範的系統架構,就正正是爲了達到這個目的。

當一個系統不斷開發期間,開發者不可能寫每一個功能的時候,都要顧慮到如何去區分現在是屬於哪個一租戶,因爲這樣很容易會發生人爲錯誤,也會令到代碼混亂,難以維護。

而這個結構的好處是,在最頂端的階段已經確立好這個請求是屬於那個一租戶,然後到了最末端的 IO 的部分,根據最頂端的判斷好的租戶資料去決定如何存取,而中間的邏輯部分就完全不用顧慮到租戶的問題,就當普通的服務器去開發功能便可。

當然實際的多租戶模式的不止這麽簡單,還有很多範圍要顧及,如背景工作 (Background Job)緩存 (Cache)WebSocket日誌文件 (Logging) 等等。但只要牢記這這個例子的概念 「靠頂端判斷租戶資料,再於末端去進行分類處理」,那無論功能如何增加擴大,也能做好維護工作,而不會發生用戶資料混亂的事情發生。

大家可以上我們的Github,去下載這個 project 實際來試試看。 https://github.com/ones-software/dotnet-core-multi-tenancy-sample


ONEs software: https://ones.software/hk/bookings-one/

]]>

軟件可以即要即用?企業級軟件訂閲服務 (SaaS) 的開發 (1)


自從 2006 年 Amazon 推出自家的雲端運算服務 AWS 開始,雲端運算徹底改變了傳統伺服器架構的使用方法。由每一次都要購買或租借一臺伺服器主機,變成想用多少伺服器資源都可以即時得到,並採納按照實際使用時間來計算收費的資源訂閱 (Subscription) 模式,大大提升架構系統的靈活度和資源分配效率。這種伺服器架構上的革命,造就了 Software as a Service (SaaS) 的興起。

在這種交付模式(即 SaaS)中雲端集中式代管軟件及其相關的資料,軟件僅需透過網際網路,而不須透過安裝即可使用。用戶通常使用精簡用戶端經由一個網頁瀏覽器來存取軟件即服務。--維基百科

雲端運算經歷了十餘年的發展,隨著各大科技巨頭如 Microsoft AzureGoogle Cloud 紛紛加入戰團,今時今日雲端運算服務已經發展得非常成熟。雲端運算能提供到一些普通伺服器不容易做到的功能,如專門處理大數據的資料庫 (Big data Database),以及針對地域問題的災難恢復 (Disaster recovery)。這些服務提供極高的彈性,方便了不少軟件開發商去開發新的軟件,而訂閱收費模式亦大大降低了初創企業入場的門檻。

https://www.cio.com/article/2991767/10-tips-for-running-a-profitable-subscription-based-business.html

由於雲端運算採取了訂閲收費,軟件的收費模式亦跟隨著由一次性 (one-off) 收費趨向以訂閲收費的形式來供客戶選擇。這個顯然是整個軟件業界的發展方向,例如 Microsoft 和 Adobe, 都將旗下歷史悠久的 Microsoft Office 和 Adobe Photo 分別轉為 Office 365Creative Cloud 這種訂閲式收費軟件。 新的訂閲模式的娛樂服務如 Netflix / Disney+ / Apple TV + 也不斷興起,而Google 最近發佈的 Stadia 更是企圖用訂閲收費的模式,來衝擊整個遊戲業界。

Every customer interaction is a marketing opportunity. If you go above and beyond on the customer service side, people are much more likely to recommend you. — — Stewart Butterfield, co-founder of Slack


雖然說軟件訂閲是一個大趨勢,但如何去建立一個成功的系統,就需要相當多軟件工程上的學問。和對普羅大衆的軟件不同,企業對軟件的要求會更加嚴格,因爲整個服務會影響到他們自身的日常商業運作,所以在建立這種系統時,需要注意的項目就比平時更多。今後我會在這裡和大家由以下的方向出發,去探討怎樣去建立一個穩健的軟件訂閲服務。

  1. 系統架構 (System architecture)
  2. 可擴展性 (Scalability)
  3. 高可用性 (High availability)
  4. 安全性 (Security)
  5. 監察與維護 (Monitoring and Maintenance)
  6. 持續發展 (Continuous development)

那麼,讓我首先講解一下系統架構所需要留意的事項。


系統架構 (System architecture)

建立軟件系統的第一步是設計好適合的系統架構,根據不同的商業需求 (Business Requirement) 所設計出的系統架構也會不同。但歸納起來,訂閲服務的系統架構的可以分爲兩大類:單一租戶模式 (Single tenancy) 多租戶模式 (Multi-tenancy)


單一租戶模式 (Single tenancy)

單一租戶模式 是為各個客戶設立一套獨立的軟件系統,他們會有獨立的數據庫、服務器、文件存儲空間等等。

安全且穩定: 絕大部分企業都會重視資料的安全和保密。單一租戶模式的好處在於每個客戶都有完全獨立的系統,不會有用戶之間資料發生衝突的情況發生,也不會因爲其他客戶的使用量增加而影響到自身的系統。單一租戶對於企業來説會是一個極具說服力的方案。

有彈性及易於管理:所有數據庫備份、系統還原的工作,或者其他的定制服務,單一租戶模式都能夠提供給予客戶。系統也能夠根據客戶的要求更改域名,或者安裝在客戶指定的雲端服務上面。而因為每個服務器都是獨立運作的,用戶可以選擇在不影響業務的時間帶,來進行系統更新。

單一租戶模式是一個直觀的方案,和傳統的系統分別其實不大,只是將系統由傳統的數據中心轉移到雲端服務之上,而雲端服務的成本也就轉化為系統的訂閲收費。


租戶模式 (Multi-tenancy)

和單一租戶模式不同,多租戶模式是以共用系統資源爲主,多個用戶會同時使用同一套系統

經濟實惠:在商業角度來看,價錢是相當重要的考慮因素,多租戶模式就能通過分享各個用戶的用量,來分攤成本。這就能將現有的資源得到充分利用,以避免服務器資源上的浪費。按照不同服務的性質而有差別,但採取多租戶模式的話,往往就能夠將伺服器的成本降至一成以下

迅速提供服務:訂閲服務講求的是能否迅速提供服務,使客戶在短時間内就開始使用是重中之重。 單一住戶模式可能需要數天的設立時間,並對系統進行整合測試 (Integration test)、負載測試 (Load test)等等的測試,才能確保實際運行穩定。而多租戶模式則是在已經運行中的系統中,添加新的租戶 (Tenant) 給予客戶。添加用戶往往只要數分鐘便完成,而且系統的穩健程度就得到確保。

容易監察、維護及更新:完善系統的監察亦是確保服務質素的重要一環。在多租戶模式下,開發者只需要監測一組伺服器的狀態,便可知道所有客戶是否能正常使用系統。而當要修正系統時,只要將修正配置到一組伺服器上就能解決問題,不需要針對個別客戶進行修正。

用戶回饋和產品發展:多租戶模式往往可以使得產品有更高速的成長速度。每當新功能完成並配置到系統上,所有租戶也能即時受惠。而功能亦能啓發用戶提出新的需求,開發者能根據這衆多的用戶回饋去分析和開發新的功能。

雖然多租戶模式下的系統是分享了各種資源並降低成本,但要注意的是用戶的資料是必須做好區分。例如可以使用同一個數據庫伺服器,但每個客戶的數據庫必須分開。文件存儲亦是同等狀況,每個客戶儲存文件的文件夾必須分開。即使在資源共享的情況下,數據的安全和保密還是最重要的考慮。


如何取捨?

Photo by Victoriano Izquierdo on Unsplash

兩種都各有優點,但實際要建立一個系統的時候,到底應該如何取捨呢?恕我直言,我是傾向支持開發多租戶模式,原因是多租戶模式本身是可以作爲單一租戶模式來使用。

不同的客戶對系統會有不同的要求。如果有客戶提出必須有一個完全獨立的系統時,你可以爲一個客戶另外設立一組伺服器。這組伺服器只是爲了服務這客戶而設,並限制只有該客戶才能使用這個環境,不會添加新的租客。這樣多住戶模式就能簡單地變成單一租戶模式來使用,各取優點。

總結

現在多租戶模式的應用是大勢所趨,Slack、Office 365 ,這些軟件都是採用這種系統架構。這樣才可以控制成本,以維持市場上的競爭力。

多租戶模式似乎有絕對的優勢,但實際上做出一個穩健的多租戶模式系統並不容易,對開發者的系統架構能力也有很高的要求。而系統有任何問題也會影響到全部的客戶。例如系統如不採取一個有效的方法,去將用戶的流量分流到不同的數據庫的話,極有可能會令到系統本身出現混亂,往後亦難以作出維護。

我們之後會和大家介紹多租戶模式的實踐,由原始碼的層面出發,去看看如何做出一個穩健的多租戶模式架構。更多資訊可以留意 ONES Publication 定期發佈的文章,亦可以聯絡我們,
我們很樂意提供相關的專業意見:https://ones.software/hk/bookings-one/


ONEs software。香港軟件開發團隊,提供專業的軟件開發服務。包括手機應用程序開發,網頁開發和定制軟件開發。 https://ones.software/zh-hk

]]>