什么是ENode

ENode是一個(gè).NET平臺(tái)下，純C#開(kāi)發(fā)的，基于DDD,CQRS,ES,EDA,In-Memory架構(gòu)風(fēng)格的，可以幫助開(kāi)發(fā)者開(kāi)發(fā)高并發(fā)、高吞吐、可伸縮、可擴(kuò)展的應(yīng)用程序的一個(gè)應(yīng)用開(kāi)發(fā)框架。

ENode框架特色

1. 一個(gè)DDD開(kāi)發(fā)框架，完美支持基于六邊形架構(gòu)思想的開(kāi)發(fā)

2. 實(shí)現(xiàn)CQRS架構(gòu)思想，并且框架提供C端命令的處理結(jié)果的返回，支持同步返回和異步返回

3. 內(nèi)置Event Sourcing（ES）架構(gòu)模式，讓C端的數(shù)據(jù)持久化變得通用化

4. 聚合根常駐內(nèi)存，in-memory domain model

5. 聚合根的處理基于Command Mailbox, Event Mailbox的思想，類似Actor Model, Actor Mailbox

6. 嚴(yán)格遵守聚合內(nèi)強(qiáng)一致性、聚合之間最終一致性的原則

7. Group Commit Domain event

8. 基于聚合根ID+事件版本號(hào)的唯一索引，實(shí)現(xiàn)聚合根的樂(lè)觀并發(fā)控制

9. 框架保證Command的冪等處理

10. 通過(guò)聚合根ID對(duì)命令或事件進(jìn)行路由，做到最小的并發(fā)沖突、最大的并行處理

11. 消息發(fā)送和接收基于分布式消息隊(duì)列EQueue，支持分布式部署

12. 基于事件驅(qū)動(dòng)架構(gòu)范式（EDA，Event-Driven Architecture）

13. 基于隊(duì)列的動(dòng)態(tài)擴(kuò)容/縮容

14. EventDB中因?yàn)榇娣诺亩际遣豢勺兊氖录?，所以水平擴(kuò)展非常容易，框架可內(nèi)置支持

15. 支持Process Manager（Saga），以支持一個(gè)用戶操作跨多個(gè)聚合根的業(yè)務(wù)場(chǎng)景，如訂單處理，從而避免分布式事務(wù)的使用

16. ENode實(shí)現(xiàn)了CQRS架構(gòu)面臨的大部分技術(shù)問(wèn)題，讓開(kāi)發(fā)者可以專注于業(yè)務(wù)邏輯和業(yè)務(wù)流程的開(kāi)發(fā)，而無(wú)需關(guān)心純技術(shù)問(wèn)題

晚上把公司應(yīng)用的架構(gòu)結(jié)合之前研究的東西梳理了下，整理了一張架構(gòu)規(guī)劃圖，貼在這里備份

下面是個(gè)人理解的做架構(gòu)的幾個(gè)要點(diǎn)：

1、系統(tǒng)安全

這是首要考慮的，以這張圖為例，網(wǎng)絡(luò)劃分為3個(gè)區(qū)：

a) DMZ區(qū)可以直接公網(wǎng)訪問(wèn)，也可以 與App Core區(qū)互通，但不能直接與DB Core區(qū)互通 (通常這里放置 反向代理Web服務(wù)器)

b) App Core區(qū)能與DMZ區(qū)、DB Core區(qū)互通，但是無(wú)法直接從公網(wǎng)訪問(wèn) (通常這里放置 應(yīng)用服務(wù)器、中間件服務(wù)器之類)

c) DB Core區(qū)僅與App Core區(qū)互通 (通常這里放置 核心數(shù)據(jù)庫(kù))

2、盡量消除單點(diǎn)故障

上圖中，除了“硬件負(fù)載均衡”節(jié)點(diǎn)外，其它節(jié)點(diǎn)都可以部署成集群（DB有點(diǎn)特殊，傳統(tǒng)RDBMS要實(shí)現(xiàn)分布式/集群還是比較困難的，要看具體采用的數(shù)據(jù)庫(kù)產(chǎn)品，并非所有數(shù)據(jù)庫(kù)都能方便的做Sharding），Jboss本身可以通過(guò)Domain模式+mod_cluster實(shí)現(xiàn)集群、Redis通過(guò)Master/Slave以Sentinel方式可以實(shí)現(xiàn)HA、IBM MQ本身就支持集群、FTP Server配合底層儲(chǔ)存陣列也可以做到HA、Nginx靜態(tài)資源服務(wù)器自不必說(shuō)

3、成本

盡量采用開(kāi)源成熟產(chǎn)品，jboss、redis、nginx、apache、mysql、rabbit MQ都是很好的選擇。硬件負(fù)載均衡通常成本不低，但是效果明顯，如果實(shí)在沒(méi)錢，域名解析采用DNS輪詢策略，也能達(dá)到類似效果，只不過(guò)可靠性略差。

4、Database問(wèn)題

常規(guī)企業(yè)應(yīng)用中，傳統(tǒng)關(guān)系型數(shù)據(jù)仍然是主流，但是no-sql經(jīng)過(guò)這幾年發(fā)展，技術(shù)也日漸成熟了，一些非關(guān)鍵數(shù)據(jù)可以適當(dāng)采用no-sql數(shù)據(jù)庫(kù)，比如：系統(tǒng)日志、報(bào)文歷史記錄這類相對(duì)比較獨(dú)立，而且增長(zhǎng)迅速的數(shù)據(jù)，可以考慮存儲(chǔ)到no-sql db甚至HDFS、TFS等分布式開(kāi)源文件系統(tǒng)中。

如果系統(tǒng)數(shù)據(jù)量級(jí)達(dá)到單機(jī)RDBMS的上限，盡早考慮Sharding方案，目前mysql在這方面比較成熟，其它數(shù)據(jù)庫(kù)就不好說(shuō)了。

5、性能

web server、app server這些一般都可以通過(guò)集群實(shí)現(xiàn)橫向擴(kuò)張，滿足性能日常增長(zhǎng)的需求。最大的障礙還是DB，如果規(guī)模真達(dá)到了DB的上限，還是考慮換分布式DB或者遷移到“云”上吧。