[isTMS]課程 - 團隊開發與架構設計實戰

 

傳統與近代的架構分層

相較於單體式的應用程式。若將軟體分層，對架構設計有很多好處。這種設計模式將應用程序劃分為不同的功能層，每層負責特定的任務，從而實現關注點分離（Separation of Concerns）。

所謂的關注點分離（Separation of Concerns, SoC） 是一種軟體設計原則，旨在將應用程序或系統中的各個功能和責任區分開來，使每個部分專注於解決某個特定問題。這樣做可以降低複雜性，提高程式碼的可讀性、可維護性和擴展性，也降低模組之間的倚賴，讓模組可以獨立開發、維護、修改、測試。

以下是將軟體分層有助於架構設計的幾個原因：

1. 模組化：分層設計有助於將應用程序劃分為可獨立開發和維護的模組。這可以讓開發團隊更容易理解和管理應用程序的各個部分，從而提高開發效率。
2. 重用性：將相關功能放在同一個模組中，可以提高代碼的重用性。這可以降低開發成本，並使得應用程序更易於維護。
3. 易於維護：分層設計有助於降低應用程序各部分之間的耦合度。當需要修改某一部分時，分層設計可以減少對其他部分的影響，使得應用程序更易於維護和升級。
4. 可測試性：將軟體分層有助於提高代碼的可測試性。由於各層負責特定功能，可以針對每層單獨編寫測試用例，從而更容易檢測和修復錯誤。
5. 靈活性：分層設計讓應用程序更具靈活性。例如，可以更容易地替換某一層的技術選擇，而不影響其他層。此外，也可以根據性能和安全需求對特定層進行優化。
6. 擴展性：將軟體分層有助於實現應用程序的橫向和縱向擴展。可以根據負載需求對特定層進行擴展，從而提高整個系統的性能。

而分層架構是一種常見的架構設計模式，它可以降低系統的複雜度和管理難度，同時也可以提高系統的可維護性、可擴展性、可重用性和安全性。在實際應用中，需要根據實際需求和場景選擇適合的分層模式和技術，從而實現更好的效果和性能。

然而，分層架構也有一些缺點和限制。例如，分層架構可能會導致系統的過度分層，從而增加系統的複雜度和管理難度。此外，分層架構可能會導致系統的性能下降，因為每個層次都需要進行額外的處理和通訊。

基本的 n-tier 架構

Tier在物理上是分隔的，不同Tier運行在不同的電腦上。 一般來說，Tier之間的溝通，可以是直接呼叫另一層(HTTP、RPC)，或使用非同步的傳訊機制，例如 Message bus、Queue、Event ... 等。

雖然每個 Layer 可以佈署在自己的 Tier 中，但並非必要。 數個Layer也可能可以佈署在相同 Tier 上。然而實際分隔各層可較有效的實踐高可用性、延展性和Failover，但也會因為網路通訊增加而造成負擔或延遲。

傳統的三層式應用程式有展示層、中介層和資料庫層。 中介層是選擇性的。 更複雜的應用程式有可能是三層以上。 上圖展示的是具有兩個中間層的應用程式，且佈署在不同環境的狀態。

底下則是一個採用 Windows Azure 環境的 n-tier 分層範例:

ref: https://learn.microsoft.com/zh-tw/azure/architecture/guide/architecture-styles/n-tier

Web-Queue-Worker

Web-Queue-Worker 是典型面對長時間執行(運算)或背景運算需求的服務架構。Web前端面對(蒐集)客戶需求，透過Quque機制暫存需求，交由Worker逐漸消化:

上圖中還有 Cache ，主要的任務是前端在面對用戶對資料庫做大量的查詢時(如果有的話)，可以透過 Cache 快速回應。

此架構的 Azure 實作解決方案如下:

https://learn.microsoft.com/zh-tw/azure/architecture/guide/architecture-styles/web-queue-worker

事件驅動

事件驅動架構包含產生事件串流的事件產生者(Event Producer/Event Source)，以及接聽事件的事件取用者(Event Consumer/Event Handler)。透過把一件工作包裝成事件，我們可以增加系統運行的延展性，而實踐的方式就是事件驅動架構(Event Architecture)。

Event Architecture，它基本上就跟我們寫程式的event感覺很像，就是有某些服務(系統)會產生事件，產生出的事件會被丟到一個地方暫時存放，然後會有某些服務(系統)來認領(或訂閱)特定這些事件，形成了底下這樣的架構:

整個架構中，會有 event source(或稱event producer)產生各種事件(例如，偵測到檔案上傳、抓取當前溫度、交易金額達到100萬上限...等)，這些事件(-->由程式設計師所定義的各種值得被關注的行為)一旦發生，就由程式碼產生一個event object，然後丟出去(到Event Buffer)，這時候Event source的任務就結束了。

接著來看 Event Handler，它負責處理事件。它可以向Event Buffer來訂閱(subscription)某個事件，當這個事件發生時，Event Handler就會取得該事件(前面說過，內容可能是一組JSON，一個字串，一個文檔)，然後著手處理。例如，收到了交易金額達到100萬上限，就發送一封通知信件...這樣。

如此的設計可以讓，事件的provider和Consumer被切開，因為兩者本來的職責就不同。切開後，即可有效的各自進行開發、擴展、或處理failover。

這整個就是『Event Architecture』這個機制的處理方式，它被廣泛的用在許多情境與場合。

https://learn.microsoft.com/zh-tw/azure/architecture/guide/architecture-styles/event-driven

微服務架構

https://learn.microsoft.com/zh-tw/azure/architecture/guide/architecture-styles/microservices