第004课 - 项目微服务架构图

最新推荐文章于 2024-12-23 11:26:51 发布
最新推荐文章于 2024-12-23 11:26:51 发布
阅读量1.4k 收藏
点赞数
CC 4.0 BY-SA版权
分类专栏： 谷粒商城 文章标签： 微服务 java 架构
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_41748874/article/details/128480921
本文介绍了项目微服务架构，包括外网与内网部署、客户端请求流程、nginx集群、springcloud gateway作为API网关、sentinel的熔断降级、spring security认证授权、redis与mysql集群、rabbitmq异步解耦、elasticsearch全文检索、日志处理使用ELK栈，以及服务注册与链路追踪等关键技术。

文章目录

项目架构图

image-20221229133837555

image-20221229133909134

外网部署就是面向公众访问的，部署前端项目。

可以有手机app，也可以有web网站。

内网部署后端系统。

客户端发送请求，请求是先来到我们的nginx集群。

nginx将请求转交给我们的后台服务。

nginx是先将请求转交给api网关。

api网关我们使用springcloud gateway。

网关可以根据当前请求，动态路由到指定的服务。

网关可以通过ribbon负载均衡调用服务。

当某些服务出现问题，可以网关级别对服务进行熔断和降级，使用sentinel组件。

网关还有认证授权的功能。

网关还可以进行限流。

请求通过网关到达服务之后，服务就进行处理。我们的服务都是使用springboot编写的。

服务和服务之间进行调用，使用spring cloud的feign组件。

有些请求可能是需要登陆之后才能够处理，我们具有oaut

了解本专栏 订阅专栏 解锁全文 超级会员免费看
微服务架构构建的完整路径：四大系统方法总结
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
12-25 171万+
本文介绍了构建微服务架构的系统方法，重点从四个方面展开讨论：服务模型、实现技术、基础设施和研发过程。首先，通过服务建模方法和服务拆分与集成策略，阐述了如何设计微服务架构。接着，探讨了关键技术实现，包括服务通信、事件驱动、负载均衡、API网关等。基础设施方面，文章涵盖了测试、交付部署、监控与安全等重要内容。最后，本文讨论了微服务架构转型过程中的组织和文化调整，以及如何通过敏捷开发、DevOps等实践推动研发过程的优化。通过这些内容，本文为构建高效、可扩展的微服务架构提供了全面的指导与实用的建议。
分布式秒杀电商-微服务架构图 上帝视角分析
匿名攻城狮
02-06 3533
整个项目采用前后端分离开发，外网部署前台项目、内网部署后台项目。本文以客户使用客户端访问网站，向后台发送请求，这一条线索对上图进行分析。 文章目录一、Nginx集群→API网关二、API网关→服务模块1.Ribbon实现负载均衡2.Sentinel进行熔断降级三、服务模块对请求进行处理四、数据存储解决方案1.存储数据2.消息队列3.全文检索4.OSS云存储五、日志管理六、注册中心&配置中心七、服务追踪八、持续集成&持续部署 一、Nginx集群→API网关 请求首先到达Nginx集群，并由.
关于nginx访问zuul网关到最后调用微服务的过程详解
weixin_42596778的博客
05-27 1716
1.前端js发起请求： http://www.easymall.com/products/pageManage?page=1&rows=1 其中www.easymall.com通过host文件映射，访问到nginx服务器 2.nginx服务器拦截请求： 80端口监听到该次请求，再去查看映射名字是否是www.easymall.com,如果是，就开始location判断请求地址中有 /products 所以匹配成功，于是截取请求，剩下/pageManage?page=1&rows=1，拼接到pr
详细讲解下网络请求到f5和nginx和网关和服务器之前的联系和顺序关系
qq_33192454的博客
10-15 2491
Nginx 则是一种反向代理服务器，用于处理客户端的请求并将请求转发到后端的应用服务器。Nginx 是一个常用的反向代理服务器，用于接收客户端的请求并将请求转发到后端的应用服务器。在一个典型的网络请求流程中，涉及到 F5、Nginx、网关以及最终的服务器。： Nginx 可以对请求进行处理，包括反向代理、负载均衡、缓存、SSL 终结等。： 客户端（如浏览器、移动应用）通过发送 HTTP 请求向服务器请求特定资源（比如网页、图片、数据等）。： Nginx 接收到应用服务器的响应后，将其返回给 F5。
nginx使用指南
limenghhuc的博客
10-31 427
nginx配置文件为 conf/nginx.conf nginx执行的顺序为 server->location->upstream server可以配置多个，匹配规则是根据server-name和监听端口进行匹配server，如果查找不到匹配的，则默认使用第一个server location支持正则表达式，其中可以配置proxy-pass，也可以指定静态文件的路径，指定静态文件时...
服务架构图
Promise的博客
11-16 1782
首先感谢朱大哥提供的图片，受益匪浅，在他的思维导图上进行修改，整理了一份技术上的思维导图，话不多说直接看图。 框起来的打算后续优先使用在自己项目的技术 也没有别的好讲了，后续会对用的到技术一一发布博客进行说明 这边给大家推荐一个思维导图的软件MindMaster,感觉比XMinind功能多，免费版本足足比XMinind好用很多 有需要原图文件可以随时联系我 ...
04、简介-项目微服务架构图
qq_17079255的博客
11-10 328
分为外网（面向用户）和内网，首先通过客户端（手机，电脑等）发送请求，请求先来到NGINX，NGINX将请求转交给后台服务（先转交给API网管spring cloud gateway）。网管可以动态路由看发送过来的请求想要调用的是哪个服务，如果服务有集群部署，那么网管还可以进行负载均衡的调用服务，如果某个服务有问题，也可以在网关级别对服务进行熔断降级（sentinel） 还可以进行认证授权操作，还可以进行限流操作，如果同时又100W个请求到达，那么我们可以只放行过去1W个请求，防止把后台压垮。 当通过网关..
谷粒商城学习笔记-05-项目微服务划分图
epitomizelu的专栏
07-04 1090
这一节介绍了谷粒商城的服务划分，从不同功能的服务的角度介绍了整个项目。原图如下。
软考论文案例-论微服务架构及其应用
missiletcy的博客
04-21 1981
软考论文写作案例：本文结合我的工作实践，以视频云项目开发为例，论述微服务架构及其应用，首先概述我参与管理和开发，并采用微服务架构开发的工作，然后具体描述微服务架构的特点，最后结合项目描述软件的架构，说明该系统是如何采用微服务架构模式的，并说明采用微服务架构模式后，在软件开发过程中遇到的实际问题和解决方案。经过项目组近一年的努力，本产品已顺利开发完成，目前，已在北京、郑州、云南等多省市上线使用，取得客户和公司领导的一致好评。
项目架构图
热门推荐
wulitaot的博客
11-28 2万+
一、架构演进        传统企业架构（垂直架构）：无论项目大小以及业务复杂性，统一在一个项目中实现。 特点：优点：结构简单、易于开发；            缺点：耦合度高（各个模块不易分离、模块间影响较大一个模块出现问题同样也会导致其他模块跟着出现问题，而咱们开发是本着“高内聚、低耦合”的标准进行的。）、不利于扩展、部署不够灵活。        SOA分布式体系架构：是一种支持面向服...
Nginx架构图(学习路线 =基础+进阶+架构)
无
05-04 1294
Nginx架构图(学习路线 =基础+进阶+架构)
Nginx请求匹配服务器的顺序
愤怒的小兵
03-28 1051
1. 根据url匹配ip和port 如 http://pandora128.cn 或 http://180.76.50.64:80 2. 获取请求头的host http://pandora128.cn 的 host 为 pandora128.cn http://180.76.50.64:80 的 host 为 180.76.50.64 3. 将host匹配server_name字段，开头匹配-&g...
gateway和nginx网关的区别
m0_56670140的博客
06-02 1029
网关是介于nignx以及业务应用之间的中间层，主要负责将请求路由到不同的微服务中以及对请求的合法性进行校验。我们目前网关的选型是spring cloud gateway，位置在nignx之后，各个微服务应用之前。为何在已经有nignx的情况下，中间还需要一道负责负载均衡功能的网关呢？一个原因是spring cloud gateway天然集成了注册中心eureka，能实现应用的自动注册与发现，而nginx每增加一个服务应用都需要手动去设置配置文件。
Nignx 网关 和 GateWay网关
m0_60591654的博客
11-24 2943
nginx 和 gateway网关
前后端分离项目服务代理配置的三种组合方式（前端nginx+gateway+后端服务）
高振的博客
09-22 7183
前提条件： 前端config.js访问后端使用相对路径，baseurl为空 前端页面wlgl：localhost：2021 后端portal：localhost：8055 后端代理gateway：localhost：2000 nginx+gateway+后端服务的代理模式就出现了三种组合方式： 1、nginx再最前面，同时代理静态资源和gateway，gateway代理后端 这种情况适合鉴权体系不需要拦截前端页面的情况，好处的静态资源直接被客户机访问，效率较高。 具体配置如下： nginx
前端 HTTP 请求由 Nginx 反向代理和 API 网关到后端服务的流程
青灯文案的博客
12-23 1551
在大型互联网项目中，前端发送请求通过 Nginx 等反向代理和网关组件传递到后端服务的过程是一个复杂且精细的系统流程。从微服务架构的角度，这个过程可以分为以下几个主要步骤，并可能涉及其他中间组件，如监控和日志组件等。
图文解说nginx中server的匹配顺序
LoveSummer
06-02 1342
在开始处理一个http请求时，nginx会取出header头中的host，与nginx.conf中每个server的server_name进行匹配，以此决定到底由哪一个server块来处理这个请求。 server_name与host匹配优先级如下： 1、完全匹配 2、通配符在前的，如*.test.com 3、在后的，如www.test.* 4、正则匹配，如~^.www.test.com$ 如果都不匹配 1、优先选择listen配置项后有default或default_server的
nginx请求的11个阶段
c243311364的博客
06-30 2256
nginx请求的11个阶段
微服务架构图.net 落地
最新发布
09-15
<think> 嗯，用户再次聚焦在微服务架构图的落地实现上，特别指定了.NET技术栈。从对话历史看，用户已经对微服务基础概念有了解（引用[1]-[5]介绍过战术设计、服务编排和基础设施），现在需要更具体的实施指南。 用户可能是个.NET技术负责人，正在做架构选型。深层需求应该是想确认：第一，.NET Core是否真能支撑完整微服务架构；第二，是否有成熟的工具链和最佳实践；第三，如何避免分布式系统的常见坑。 我注意到引用[5]提到.NET Core+Docker+K8s的组合，这正是关键突破点。需要重点展开三点： 1）**核心组件映射**：把用户之前看到的通用微服务架构图（API网关/注册中心等）对应到.NET生态的具体工具，比如用Ocelot替代Spring Cloud Gateway； 2）**特有技术优势**：突出.NET的强类型契约（Protobuf+gRPC）、跨平台容器化能力； 3）**可视化案例**：给出电商场景的简化架构图，标注每个模块的.NET实现方案。 另需警惕用户可能的认知盲区——例如忽略配置中心和链路追踪（引用[4]强调过监控底座）。在相关问题里埋入这些点，引导用户思考全链路设计。 最后用K8s部署图收尾，因为引用[3][5]都显示用户关心运维层面。这个架构图要体现.NET服务在容器集群中的实际分布状态，呼应“落地”诉求。 </think> 以下是基于.NET环境的微服务架构落地方法和案例详解，结合领域驱动设计（DDD）和云原生技术实现： ### 一、.NET微服务架构核心组件图（分层架构） ```mermaid graph TD A[客户端] --> B[API网关] B --> C[身份认证服务] B --> D[订单服务] B --> E[支付服务] C -->|gRPC| F[服务注册中心] D -->|RabbitMQ| G[领域事件总线] E --> H[分布式配置中心] F -.-> I[Consul/Nacos] H -.-> J[Apollo] G -.-> K[MassTransit] ``` ### 二、关键落地技术栈 1. **服务通信** - **RESTful API**：ASP.NET Core Web API + Swagger - **高性能RPC**：gRPC（ProtoBuf契约优先）[^2] - **消息队列**：RabbitMQ + MassTransit（领域事件驱动）[^1] 2. **服务治理** - **注册中心**：Consul（服务发现/健康检查）[^3] - **配置中心**：Apache Apollo（动态配置管理） - **负载均衡**：Nginx + Ocelot（API网关路由） 3. **数据管理** - **数据库隔离**：每个服务独立SQL Server/PostgreSQL - **缓存**：Redis集群（分布式缓存） - **事务处理**：Saga模式（通过Masstransit实现） 4. **容器化部署** ```dockerfile # .NET微服务Docker示例 FROM mcr.microsoft.com/dotnet/aspnet:7.0 WORKDIR /app COPY ./publish . ENTRYPOINT ["dotnet", "OrderService.dll"] ``` - **编排工具**：Kubernetes（通过Deployment管理Pod）[^5] ### 三、电商案例架构落地（参考引用[3]） ```mermaid flowchart LR 网关[Ocelot网关] --> 认证[IdentityServer4] 网关 --> 订单[订单服务] 网关 --> 库存[库存服务] 订单 -->|事件| 支付[支付服务] 库存 -->|gRPC| 商品[商品服务] 支付 --> 审计[审计服务] 所有服务 --> 注册中心[Consul] 注册中心 -.-> 监控[Prometheus+Grafana] ``` ### 四、实施关键点 1. **领域驱动设计落地** - **聚合根**：`Order`作为订单服务的聚合根实体 - **领域服务**：`PaymentDomainService`处理支付逻辑 - **仓储模式**：`IOrderRepository`抽象数据访问[^1] 2. **故障处理机制** - **熔断模式**：Polly库实现重试/熔断 ```csharp services.AddHttpClient("InventoryService") .AddTransientHttpErrorPolicy(p => p.WaitAndRetryAsync(3, _ => TimeSpan.FromMilliseconds(500))); ``` 3. **监控体系** - 日志：Serilog + Elasticsearch - 链路追踪：OpenTelemetry + Jaeger - 指标监控：Prometheus采集.NET Metrics ### 五、典型部署架构 ``` +---------------------+ | Kubernetes集群 | +----------+----------+ | Pod1 | Pod2 | | +------+ | +------+ | | |.NET | | |.NET | | | |SvcA | | |SvcB | | | +------+ | +------+ | +----------+----------+ | Consul Server | | Redis Cluster | | PostgreSQL HA | +---------------------+ ``` --- **参考文献** [^1]: 战术设计中的领域对象（聚合根/实体）直接映射到微服务代码实现，如`Order`实体类包含业务规则验证方法 [^2]: gRPC实现服务间高效通信，.NET支持Proto文件自动生成强类型客户端 [^3]: Consul实现服务注册与健康检查，.NET通过`Consul.AspNetCore`库集成 [^5]: K8s管理.NET容器生命周期，通过Helm Chart实现配置模板化
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值