.NET Web入門到高階路線

PgSQL PostgreSQL 的歷史簡介. 現在被稱為 PostgreSQL 的物件- 關係型資料庫管理系統（有一段時間被稱為 Postgres95）是從伯克利寫的 POSTGRES 軟體包發展而來的。. 經過十幾年的發展， PostgreSQL 是世界上可以獲得的最先進的開放原始碼的資料庫系統，它提供了多版本並行控制，支援幾乎所有 SQL 構件（包括子查詢，事務和使用者定義型別和函數），並且可以獲得非常廣闊範圍的（開發）語言繫結（包括 C，C++，Java，perl，tcl，和 python）

中介軟體

中介軟體是介於應用系統和系統軟體之間的一類軟體，它使用系統軟體所提供的基礎服務（功能），銜接網路上應用系統的各個部分或不同的應用，能夠達到資源共用、功能共用的目的。它並沒有很嚴格的定義，但是普遍接受IDC的定義：中介軟體是一種獨立的系統軟體服務程式，分散式應用軟體藉助這種軟體在不同的技術之間共用資源，中介軟體位於客戶機伺服器的作業系統之上，管理計算資源和網路通訊。從這個意義上可以用一個等式來表示中介軟體：中介軟體=平臺+通訊，這也就限定了只有用於分散式系統中才能叫中介軟體，同時也把它與支撐軟體和實用軟體區分開來。

MongoDB

MongoDB 是一個基於分散式檔案儲存的資料庫。由 C++ 語言編寫。旨在為 WEB 應用提供可延伸的高效能資料儲存解決方案。

MongoDB 是一個介於關聯式資料庫和非關聯式資料庫之間的產品，是非關聯式資料庫當中功能最豐富，最像關聯式資料庫的。

Redis

REmote DIctionary Server(Redis) 是一個由 Salvatore Sanfilippo 寫的 key-value 儲存系統，是跨平臺的非關係型資料庫。

Redis 是一個開源的使用 ANSI C 語言編寫、遵守 BSD 協定、支援網路、可基於記憶體、分散式、可選永續性的鍵值對(Key-Value)儲存資料庫，並提供多種語言的 API。

Redis 通常被稱為資料結構伺服器，因為值（value）可以是字串(String)、雜湊(Hash)、列表(list)、集合(sets)和有序集合(sorted sets)等型別。

RabbitMQ

RabbitMQ是實現了高階訊息佇列協定（AMQP）的開源訊息代理軟體（亦稱訊息導向中介層）。RabbitMQ伺服器是用Erlang語言編寫的，而叢集和故障轉移是構建在開放電信平臺框架上的。所有主要的程式語言均有與代理介面通訊的使用者端庫。

ActiveMQ

Apache ActiveMQ是Apache軟體基金會所研發的開放原始碼訊息中介軟體；由於ActiveMQ是一個純Java程式，因此只需要作業系統支援Java虛擬機器器，ActiveMQ便可執行。

SkyWalking

用於分散式系統的應用程式效能監視工具，特別為微服務、雲原生和基於容器(Kubernetes)架構設計。

Consul

Consul是微服務架構中，解決服務發現、設定中心的分散式中介軟體。
Consul是HashiCorp公司推出的開源工具，Consul由Go語言開發，部署起來非常容易，只需要極少的可執行程式和組態檔，具有綠色、輕量級的特點。Consul是分散式的、高可用的、可橫向擴充套件的用於實現分散式系統的服務發現與設定。

服務發現（Service Discovery）：Consul提供了通過DNS或者HTTP介面的方式來註冊服務和發現服務。一些外部的服務通過Consul很容易的找到它所依賴的服務。
健康檢查（Health Checking）：Consul的Client可以提供任意數量的健康檢查，既可以與給定的服務相關聯(「webserver是否返回200 OK」)，也可以與本地節點相關聯(「記憶體利用率是否低於90%」)。操作員可以使用這些資訊來監視叢集的健康狀況，服務發現元件可以使用這些資訊將流量從不健康的主機路由出去。
Key/Value儲存：應用程式可以根據自己的需要使用Consul提供的Key/Value儲存。 Consul提供了簡單易用的HTTP介面，結合其他工具可以實現動態設定、功能標記、領袖選舉等等功能。
安全服務通訊：Consul可以為服務生成和分發TLS證書，以建立相互的TLS連線。意圖可用於定義允許哪些服務通訊。服務分割可以很容易地進行管理，其目的是可以實時更改的，而不是使用複雜的網路拓撲和靜態防火牆規則。
多資料中心：Consul支援開箱即用的多資料中心. 這意味著使用者不需要擔心需要建立額外的抽象層讓業務擴充套件到多個區域。

Kafka

Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料。這種動作（網頁瀏覽，搜尋和其他使用者的行動）是在現代網路上的許多社會功能的一個關鍵因素。這些資料通常是由於吞吐量的要求而通過處理紀錄檔和紀錄檔聚合來解決。對於像Hadoop的一樣的紀錄檔資料和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的訊息處理，也是為了通過叢集機來提供實時的消費。

Dapr

Dapr 是一個可移植的、事件驅動的執行時，它使任何開發人員能夠輕鬆構建出彈性的、無狀態和有狀態的應用程式，並可執行在雲平臺或邊緣計算中，它同時也支援多種程式語言和開發框架。

微軟Dapr簡介

運維

Docker

Docker 是一個開源的應用容器引擎，基於 Go 語言並遵從 Apache2.0 協定開源。

Docker 可以讓開發者打包他們的應用以及依賴包到一個輕量級、可移植的容器中，然後釋出到任何流行的 Linux 機器上，也可以實現虛擬化。

容器是完全使用沙箱機制，相互之間不會有任何介面（類似 iPhone 的 app）,更重要的是容器效能開銷極低。

DockerCompose

Compose 是用於定義和執行多容器 Docker 應用程式的工具。通過 Compose，您可以使用 YML 檔案來設定應用程式需要的所有服務。然後，使用一個命令，就可以從 YML 檔案設定中建立並啟動所有服務。

Drone

Drone是為繁忙的開發團隊提供的自助持續整合平臺。

CI/CD

CI 持續整合（Continuous Integration）
協同開發是目前主流的開發方式，也就是多位開發人員可以同時處理同一個應用的不同模組或者功能。

但是，如果企業計劃在同一天，將所有開發分支程式碼整合在一起，最終可能會花費很多時間和進行很多重複勞動，費事費力。因為程式碼衝突是難以避免的。

如果開發人員原生的環境和線上不一致的話，那麼這個問題就更加複雜了。

持續整合（CI）可以幫助開發者更加方便地將程式碼更改合併到主分支。

一旦開發人員將改動的程式碼合併到主分支，系統就會通過自動構建應用，並執行不同級別的自動化測試（通常是單元測試和整合測試）來驗證這些更改，確保這些更改沒有對應用造成破壞。

如果自動化測試發現新程式碼和現有程式碼之間存在衝突，CI 可以更加輕鬆地快速修復這些錯誤。

CD 持續交付（Continuous Delivery）
CI 在完成了構建、單元測試和整合測試這些自動化流程後，持續交付可以自動把已驗證的程式碼釋出到企業自己的儲存庫。

持續交付旨在建立一個可隨時將開發環境的功能部署到生產環境的程式碼庫。

在持續交付過程中，每個步驟都涉及到了測試自動化和程式碼釋出自動化。

在流程結束時，運維團隊可以快速、輕鬆地將應用部署到生產環境中。

CD 持續部署（Continuous Deployment）
對於一個完整、成熟的 CI/CD 管道來說，最後的階段是持續部署。

它是作為持續交付的延伸，持續部署可以自動將應用釋出到生產環境。

實際上，持續部署意味著開發人員對應用的改動，在編寫完成後的幾分鐘內就能及時生效（前提是它通過了自動化測試）。這更加便於運營團隊持續接收和整合使用者反饋。

總而言之，所有這些 CI/CD 的關聯步驟，都極大地降低了應用的部署風險。

不過，由於還需要編寫自動化測試以適應 CI/CD 管道中的各種測試和釋出階段，因此前期工作量還是很大的。

微服務

一種軟體開發技術- 面向服務的體系結構（SOA）架構樣式的一種變體，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為使用者提供最終價值。每個服務執行在其獨立的程序中，服務與服務間採用輕量級的通訊機制互相溝通（通常是基於HTTP的RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠獨立地部署到生產環境、類生產環境等。另外，應儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據上下文，選擇合適的語言、工具對其進行構建。

.NET 應用程式體系結構檔案

.NET 微服務。適用於容器化

使用 DDD 和 CQRS 模式降低微服務中的業務複雜性

領域驅動設計(DDD)

域驅動設計 (DDD) 提倡基於與用例相關的真實業務來構建模型。在構建應用程式的上下文中，DDD 用域來描述問題。它將獨立的問題區域描述為界定的上下文（每個界定的上下文關聯一個微服務），並強調使用一種通用的語言來討論這些問題。它還提出許多技術概念和模式，如具有充血模型的域實體（無貧血模型）、值物件、聚合和聚合根（或根實體）規則，用於支援內部實現。本部分介紹這些內部模式的設計和實現。

有時這些 DDD 技術規則和模式被認為是障礙，因為會導致實施 DDD 方法時的學習曲線較陡峭。但重要的並非模式本身，而是如何根據業務問題組織程式碼，並使用相同的業務術語（通用語言）。此外，只有在需要實現採用重要業務規則的複雜微服務時，才應使用 DDD 方法。較為簡單的功能，如 CRUD 服務，可使用較為簡單的方法來管理。

設計和定義微服務時，最關鍵的任務是界定邊界。藉助 DDD 模式，可瞭解域中的複雜性。對於每個界定的上下文的域模型，需確定和定義為域建模時所需的實體、值物件和聚合。生成和優化限定在某個邊界內的域模型，該邊界用於定義上下文。如果是微服務的形式，這會十分明晰。這些邊界內的元件最終會成為微服務，但在某些情況下，BC 或業務微服務可由多個物理服務組成。 DDD 與邊界相關，微服務也是如此。

在 CQRS 微服務中實現讀取/查詢

對於讀取/查詢，來自 eShopOnContainers 參照應用程式的訂購微服務獨立於 DDD 模型和事務區域實現查詢。此實現主要是因為查詢的需要和事務的需要有很大不同。寫入的執行事務必須符合域邏輯。另一方面，查詢是冪等的，可以與域規則分離。

應用框架

ABP

ABP是一個開源且檔案友好的應用程式框架。ABP不僅僅是一個框架，它還提供了一個最徍實踐的基於領域驅動設計(DDD)的體系結構模型，可以支援.net framework和.net core兩種技術流派。

ABP 框架特點

依賴注入，這個部分使用 Castle windsor （依賴注入容器）來實現依賴注入，這個也是我們經常使用IOC來處理的方式；
Repository倉儲模式，已實現了Entity Framework、NHibernate、MangoDB、記憶體資料庫等，倉儲模式可以快速實現對資料介面的呼叫；
身份驗證與授權管理，可以使用宣告特性的方式對使用者是否登入，或者介面的許可權進行驗證，可以通過一個很細粒度的方式，對各個介面的呼叫許可權進行設定；
資料有效性驗證，ABP自動對介面的輸入引數物件進行非空判斷，並且可以根據屬性的申請資訊對屬性的有效性進行校驗；
審計紀錄檔記錄，也就是記錄我們對每個介面的呼叫記錄，以及對記錄的建立、修改、刪除人員進行記錄等處理；
Unit Of Work工作單元模式，為應用層和倉儲層的方法自動實現資料庫事務，預設所有應用服務層的介面，都是以工作單元方式執行，即使它們呼叫了不同的儲存物件處理，都是處於一個事務的邏輯裡面；
例外處理，ABP框架提供了一整套比較完善的流程處理操作，可以很方便的對異常進行進行記錄和傳遞；
紀錄檔記錄，我麼可以利用Log4Net進行常規的紀錄檔記錄，方便我們跟蹤程式處理資訊和錯誤資訊；
多語言/在地化支援，ABP框架對多語言的處理也是比較友好的，提供了對XML、JSON語言資訊的設定處理；
Auto Mapping自動對映，這個是ABP的很重要的物件隔離概念，通過使用AutoMaper來實現域物件和DTO物件的屬性對映，可以隔離兩者的邏輯關係，但是又能輕鬆實現屬性資訊的賦值；
動態Web API層，利用這個動態處理，可以把Application Service 直接釋出為Web API層，而不需要在累贅的為每個業務物件手工建立一個Web API的控制器，非常方便；
動態JavaScript的AJax代理處理，可以自動建立Javascript 的代理層來更方便使用Web Api，這個在Web層使用。