.Net微服务实战之技术架构分层篇(二)

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: .Net微服务实战之技术架构分层篇(二)


横向拆分(横向分层)


首先我按照分层架构的思想以纵向维度拆分,通俗点就是按照自定向下的按照各层职责进行分解,主要共分5层,UI层、聚合API服务层、基础业务API服务层、基础设施层、数据库层

     

调用链路自顶往下,用户-->UI-->API网关-->聚合API服务-->Consul+Consul Template+Nginx-->业务API服务-->数据库


UI层


依赖于聚合API服务层,操作与接口11对应,主要负责可见即可得的工作:数据展示、交互动画等。


入站API网关


主要负责聚合API服务层内外网隔离、入站规则控制,防止外部大流量冲垮内部服务。


聚合API服务层


UI层依赖,依赖于基础业务API服务层,主要负责基础业务API服务层的接口的逻辑组合,不直连数据库,可通过API网关暴露给UI层调用。


注册服务中心


记录基础业务API服务层的服务IP列表,内网使用,衔接聚合API服务层基础业务API服务层


基础业务API服务层,


聚合API服务层依赖,依赖于数据库层,可做具体的数据库读写处理,内网使用,同层服务之间不互相依赖引用。


数据库层


包括非关系型数据库与关系型数据库。


基础设施服务层


可被所有层都依赖,如果被UI层依赖则通过API网关暴露,如果被内网服务依赖则通过注册发现,可直连数据库。


出站API网关


主要负责基础设施服务层内外网隔离,转发第三方开放API请求,出站规则控制,防止被无法把控的第三方服务而拖垮内部服务。

 

向拆分(纵向切割)


接下来,我们可以通过DDD进行服务的切割,通俗点描述就是将同一个较大的服务拆解成为多个较小的服务。


那么究竟要根据什么样的信息和过程进行拆解呢?有一个工作坊叫作"事件风暴",事件风暴是一个从拆解到整合的过程,过程中需要领域专家(需求提出者)技术实践者协作完成领域建模。


一般采用场景分析用例分析尽可能分解出领域对象(实体、命令、事件),可以从交流的过程中提取出领域专家(需求提出者)口中的名词、动作、触发事件等,这是一个拆解的过程。


将以上沟通后的结果进行重新梳理,寻找他们的关系进行汇聚,形成聚合与界限上下文,这就是一个整合的过程。


一个微服务粒度可以粗与界限上下文一致,粒度可以细化到一个聚合。

举个例子:

 

我们平台拥有三种不同业务领域的系统:客户中心、企业管理系统、内部管理系统


那么,聚合API服务层则拥有客户系统API服务、企业管理系统API服务,内部管理系统API服务。

  

客户中心的拥有客户信息管理、支付、订单管理等业务模块。


企业管理系统拥有订单管理、权限管理、支付、仓储等业务模块。


内部管理系统拥有权限管理、报表、账户管理等业务模块。


所有系统涉及到自定义订单号、消息推送等业务。


从以上得知,核心域包括仓储、订单业务、客户信息。通用域包括权限管理、账户认证、支付模块、消息推送等。支撑域包括自定义订单号。


因此基础业务API层可以划分:仓储API服务、订单API服务、客户API服务、权限API服务、认证API服务,支付API服务。


基础设施API层可以划分:ID发号API服务,消息推送API服务。


后来多次跟产品经理沟通后得知,仓储服务在某个场景下需要把修改订单服务的状态,那么这里有个触发事件,而且是跨微服务的,因此引入了基于消息的最终一致性的分布式事务进行解决。


如果随着业务继续扩大,团队人数增多,则可以更加的细分,例如仓储拆分成快运、集运等。支付拆分成微信支付、支付宝等。


项目示例


上一篇《.Net微服务实战之技术选型篇》我整理了我们公司使用的框架开源到了github,这次我拿了部分业务项目作为示例并上传了。


https://github.com/SkyChenSky/Sikiro


首先想说明几点:


1.这个不是标准,只是针对我们公司情况取舍后的结果,每个公司的业务有复杂有简单大家视情况完善自己的项目。


2.为了保护公司原有的业务隐私,我做了部分逻辑的删除,所以大家如果看到不完整的逻辑是正常现象。


3.希望大家把思维放高,不要死抠细节,求同存异。


  4.代码在原有的基础上修改了名称和引用路径会有变化,如果有问题随时在评论和github反馈给我。


image.png

目录
相关文章
|
1月前
|
运维 监控 Go
Go语言微服务实战与最佳实践
【2月更文挑战第14天】本文将深入探讨使用Go语言进行微服务实战中的最佳实践,包括服务拆分、API设计、并发处理、错误处理、服务治理与监控等方面。通过实际案例和详细步骤,我们将分享如何在Go语言环境中构建高效、稳定、可扩展的微服务系统。
|
2月前
|
负载均衡 关系型数据库 应用服务中间件
高可用系列文章之二 - 传统分层架构技术方案
高可用系列文章之二 - 传统分层架构技术方案
|
3月前
|
开发框架 前端开发 .NET
七天.NET 8操作SQLite入门到实战 - (1)第七天BootstrapBlazor UI组件库引入
七天.NET 8操作SQLite入门到实战 - (1)第七天BootstrapBlazor UI组件库引入
|
23天前
|
Java fastjson 数据安全/隐私保护
【Dubbo3技术专题】「云原生微服务开发实战」 一同探索和分析研究RPC服务的底层原理和实现
【Dubbo3技术专题】「云原生微服务开发实战」 一同探索和分析研究RPC服务的底层原理和实现
38 0
|
1月前
|
数据安全/隐私保护 Windows
.net三层架构开发步骤
.net三层架构开发步骤
11 0
|
1月前
深入.net平台的分层开发
深入.net平台的分层开发
50 0
|
1月前
|
开发框架 移动开发 JavaScript
SpringCloud微服务实战——搭建企业级开发框架(四十六):【移动开发】整合uni-app搭建移动端快速开发框架-环境搭建
正如优秀的软件设计一样,uni-app把一些移动端常用的功能做成了独立的服务或者插件,我们在使用的时候只需要选择使用即可。但是在使用这些服务或者插件时一定要区分其提供的各种服务和插件的使用场景,例如其提供的【uni-starter快速开发项目模版】几乎集成了移动端所需的所有基础功能,使用非常方便,但是其许可协议只允许对接其uniCloud的JS开发服务端,不允许对接自己的php、java等其他后台系统。
138 2
|
1月前
|
分布式计算 API 数据处理
Flink【基础知识 01】(简介+核心架构+分层API+集群架构+应用场景+特点优势)(一篇即可大概了解flink)
【2月更文挑战第15天】Flink【基础知识 01】(简介+核心架构+分层API+集群架构+应用场景+特点优势)(一篇即可大概了解flink)
57 1
|
2月前
|
Java API 调度
从Spring Cloud 开始,聊一聊微服务架构的设计与实战
随着互联网的发展,网站应用的规模也在不断的扩大,进而导致系统架构也在不断的进行变化。
367 1
从Spring Cloud 开始,聊一聊微服务架构的设计与实战
|
2月前
|
存储 自然语言处理 前端开发
软考实践之分层架构思想的理论和应用实践
软考实践之分层架构思想的理论和应用实践
218 0