如果有接觸過網頁開發的讀者，或者會聽過很多不同的專有名詞，其中不少得Front-end (前端) 和 Back-end （後端）這兩個字詞。有一些網站可能只需要設計師和前端開發者，有些則需要後端開發者和測試人員等等，那究竟前端和後端如何分辨？首先，讓我們搞清楚前端開發是什麼一回事。

Front-end 前端開發

前端包含所有用家能夠見到、繼而互動的畫面，而現今的網頁主要仍是利用HTML、CSS 和 Javascript 來建構這些畫面。

HTML相信即使不是程式員都不陌生，HTML 全名是 Hypertext Markup Language（超文件標示語言），是建立網頁的標準標示語言，簡單來說就是一個網頁的骨幹。早期的網頁，如這個有關WWW萬維網的網站(連結)，主要只有文字，充其量會有一些圖像，所以畫面比較乏味，如下面的例子1a）。於是，就有CSS的誕生了。

1a) 只使用HTML的網頁 ：https://codepen.io/OnesSoftware/pen/wVKvxx

CSS 於 1998年出現， 全名是 Cascading Style Sheets（層疊樣式表）， 一種用來為例如HTML、XML 等這些結構化文件添加樣式的電腦語言，亦即是一個網頁的表皮／裝飾。

在CSS 誕生前，要控制網頁如何顯示，就要在HTML檔案內包含顯示的資訊，例如字型的大小和顏色、背景應該是怎樣的、如何排列等等，這些都必須逐一在HTML檔案內列出。有時會因為資訊重複列出而令到網站過份冗長。CSS的出現使開發者可以將大部分這些顯示用的資訊中隔離出來，從而簡化 HTML 的檔案。這些資訊會被放在一個輔助的，用CSS語言寫的檔案中。理想來說， 現在的HTML檔案中應該只包含結構和內容的資訊，而CSS檔案中就包含樣式的資訊，以達致分工的目的。

1b) 使用了 HTML 和 CSS 的網頁： https://codepen.io/OnesSoftware/pen/rXOajM

在上面的例子1b)，是將純粹使用HTML作為框架的 1a)，加上 CSS 的裝飾，例如文字顏色、 邊框和背景顏色。

網頁的骨幹和表皮都有了，已經可以製作一些漂亮的靜態頁面，但如果要有一些能夠互動的部分，例如持續取得一些即時的資訊、儲存數據，甚至只是按下按鈕時彈出對話框，只用HTML和CSS的話都難以實行。 JavaScript 就正正能夠補充給予網頁「肌肉」並得以「活動」這個角色了。

1995 面世的 JavaScript 主要用作管理網頁的內容以及用戶的操作行為，而由於不同PHP、ASP的伺服器端手稿語言，不需要伺服器的支援也能夠在用戶的瀏覽器上運行，所以的確能夠減少對伺服器的負擔。

1c) 使用 HTML 、CSS 和 JavaScript 的網頁：https://codepen.io/OnesSoftware/pen/WVrwbv

在上面的例子 1c) 中，加了JavaScript 的輔助後，按下按鈕就會彈出「clicked」的對話框。

時至今日，前端的技術不斷轉變， 中間有過Flash、 Silverlight 這類 Web前端應用程式的開發解決方案曾經稱霸多年，卻因為手機平台不支援等因素而被淘汰。反而最基礎的 HTML、JavaScript、CSS不斷改進，以致如播放實時影片、繪圖、動畫等的功能都無須額外方案處理。而現在有不少 framework 和 library，如 ReactJS／Bootstrap 等等，能夠提供規格化的開發資源，使得開發的效率和水準得以大大提升。

前端開發者的主要職責，除了負責網頁的內容如何擺放，亦即所謂的 User Interface（使用者介面），也要照顧到用戶的瀏覽體驗，那就是 User EXperience（使用者體驗），這就要和專門的 UI、UX 設計師合作才得以處理得宜。前端開發者也要和後端開發者處理前後端之間的編程介面（API），使得有需要數據得以儲存、獲取和處理等等。

有興趣理解前端開發者的技術路線圖，可以看：

https://github.com/goodjack/developer-roadmap-chinese/blob/master/chinese-version/images/frontend.png

Ref：

https://zh.wikipedia.org/wiki/HTML

https://zh.wikipedia.org/wiki/%E5%B1%82%E5%8F%A0%E6%A0%B7%E5%BC%8F%E8%A1%A8

https://www.pluralsight.com/blog/film-games/whats-difference-front-end-back-end

https://flatironschool.com/blog/front-end-vs-back-end-development/

更多資訊可以留意 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

聯絡我們:
主頁: https://ones.software/hk/
電郵地址: hello@ones.software
電話號碼: (+852) 5538 3410
Contact us:
Homepage: https://ones.software/
Email address: hello@ones.software
Phone number: (+852) 5538 3410

]]>

The post 甚麼是前端開發？ first appeared on ONEs Blog.

我們於上一篇提過關於多租戶模式 (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/

]]>

The post SaaS的多租戶模式(Multi-tenancy)實踐：.NET Core + Entity Framework Core first appeared on ONEs Blog.

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

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

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

由於雲端運算採取了訂閲收費，軟件的收費模式亦跟隨著由一次性 (one-off) 收費趨向以訂閲收費的形式來供客戶選擇。這個顯然是整個軟件業界的發展方向，例如 Microsoft 和 Adobe， 都將旗下歷史悠久的 Microsoft Office 和 Adobe Photo 分別轉為 Office 365 和 Creative 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) 給予客戶。添加用戶往往只要數分鐘便完成，而且系統的穩健程度就得到確保。

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

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

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

如何取捨？

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

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

總結

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

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

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

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

]]>

The post 軟件可以即要即用？企業級軟件訂閲服務 (SaaS) 的開發 (1) first appeared on ONEs Blog.