微服务架构学习与思考(03):微服务总体架构图解

微服务架构学习系列文章:

一:进行服务分层

分层:是一种很常见的架构方法。比如我们常见的网络协议TCP/IP的分层。分层之后,各层各司其职,相互隔离开来。

最简单的服务分层

服务分层

第一层:接入层

外部设备访问的统一接入层。

第二层:聚合服务层

对下层的基础服务做一些聚合,剪裁的工作,适配上层不同设备的数据输出。

第三层:基础服务层

比较细粒度的微服务层,提供基础的核心服务,公共服务。

有了下面的基础服务层,还有上面的聚合层干什么呢?

比如:有时候PC端和APP端的数据显示不一样,手机屏幕比较小,可能显示的数据少些,而PC端显示的数据多些,这样就需要对不同的接入层设备的数据做一些裁剪的工作。

比如:下面的基础服务层,分的服务粒度可能比较细,接入层APP需要一个功能时,有时需要访问几个基础服务,之后APP在聚合这些服务数据,这样效率就很差,不如我们在服务端直接聚合服务,然后把聚合好的数据直接发给APP,这样访问效率就可以提升,从而提升用户体验。

上面只是一个最基本的服务分层,可以在这个基本分层结构之上进行扩展。

二:微服务总体架构图

学习杨波老师的《微服务架构》里面的一张图,稍微做了一些修改:

微服务总体架构图

上面的总体技术架构图一共分了6层

  • 1.接入层

也可以叫负载均衡层,把外部的流量引入到系统中来。一般负载均衡软件有nginx,lvs,还有各大云服务厂商自己的负载均衡服务。

  • 2.网关层
    内部接口的一些认证、安全、鉴权、过滤、限流等服务,一般处于这一层。这一层把内部的服务接口做一层安全隔离,保护内部服务,同时也可以实现一些其他需求,比如前面讲的鉴权、黑名单过滤等等需求。所以这一层在微服务架构中是很重要的一层。

  • 3.业务服务层

基础服务和聚合服务

  • 基础服务:根据业务特点又可以分为核心基础服务、公共服务、中间层服务等。

  • 聚合服务:把下面细粒度的基础服务再进一步封装、关联,组合成新的服务,供上层调用。这一层可以实现多变的需求。
    上面的这种划分是根据逻辑来划分,各个公司可以根据自己实际的业务需求来进行划分。

  • 4.支撑服务层

微服务能够成功实施落地,这一层与下一层CI/CD的配套设施是非常重要。微服务不是把上面的业务服务写完就完事了,在服务治理的过程中需要很多配套设置支持。
这一层包括注册服务中心,配置中心,监控报警服务,日志聚合服务,调用链监控几大服务,后台服务涉及的服务有消息队列,定时任务,数据访问等内容。

  • 5.平台服务层

这一层是实施业务弹性治理的关键。集群的资源调度:扩展和减少。业务量上来时,可以弹性增加资源。
在微服务建设过程中,可能会遇到一些突发事件。比如微博明星热点事件,会导致访问量暴增,这就需要能实时增加服务资源应对这种突发情况,热点过后,又要减少资源。
镜像管理和发布系统配合使用可以应对出现的这种情况。所以很多团队后面会引入docker+k8s,容器,镜像管理,容器服务编排。此外,基于CI/CD的DevOps也是构建在这一层能力。

  • 6.基础设施层

这个是最底层的基础设施,网络,存储,硬盘,IDC的部分。
laas 这个概念就是针对这一层。

上面的这个架构图,还可以有其他的表现形式,比如把支撑系统服务画在2侧面,只要能正确表达出架构思想。

每家公司业务模型,开发人员,都不尽相同,所以架构设计也可能不同,上面的当作一种参考设计。请务必根据自家情况来设计架构,适合自己的才是最好的。


也可以到我的公众号讨论此文:九卷技术录,微服务总体架构图解

三:参考

### Spring Cloud 微服务架构工作原理及组成结构 #### 工作原理 Spring Cloud 的核心目标是通过一系列工具和服务协调整个微服务生态系统。其主要功能包括但不限于配置管理、服务发现、断路器、路由以及分布式事务处理等[^1]。这些功能共同作用,使得开发者能够轻松构建和维护复杂的分布式系统。 具体来说,当一个请求到达网关层时,Spring Cloud Gateway 或 Zuul 负责将该请求转发到相应的后端服务实例上。在此过程中,Eureka 或 Consul 等注册中心用于动态查找可用的服务节点,并确保负载均衡策略得以实施。如果某个服务发生异常,则 Hystrix 断路器机制可以防止级联失败的发生,从而提升系统的整体可靠性[^2]。 此外,在实际运行环境中还需要考虑日志聚合、链路跟踪等问题,这可以通过 Sleuth 和 Zipkin 来解决;而对于大规模部署场景下的统一配置需求则由 Config Server 提供支持[^3]。 #### 组成结构 以下是构成 Spring Cloud 微服务架构的主要模块及其职责: 1. **Config Server**: 集中式外部化配置文件存储解决方案,允许不同环境间共享相同的代码库但采用不同的参数设置。 2. **Service Registry (Eureka/Consul)**: 实现自动化的服务注册发现过程,简化客户端调用逻辑的同时增强了高可用性和弹性扩展能力。 3. **API Gateway(Zuul/Spring Cloud Gateway)**: 承担入口角色,对外暴露单一访问点并对内部资源加以隔离保护。 4. **Circuit Breaker(Hystrix/Resilience4j)**: 当依赖项不可达或者响应超时时主动切断连接以避免阻塞其他操作。 5. **Distributed Tracing(Sleuth/Zipkin)**: 记录每一次跨多个独立进程的完整交互路径以便于排查性能瓶颈或定位错误源头。 6. **Load Balancer(Ribbon/Nginx)**: 均衡分配流量至健康的目标服务器群组成员之中,优化用户体验并减少延迟时间。 7. **Message Broker(Kafka/RabbitMQ)**: 支撑异步消息传递模式下各组件间的松耦合协作关系建立。 8. **Fault Tolerance & Resiliency Tools(Sentinel/Prometheus+Grafana)**: 监控指标数据采集分析平台配合限流降级措施一起运作来增强业务连续性表现水平[^4]. ```python from spring_cloud import EurekaClient, CircuitBreaker, ApiGateway def handle_request(request_data): try: service_instance = EurekaClient.find_service('example-service') response = ApiGateway.route_to(service_instance.url, request_data) return response except ServiceUnavailableException as e: fallback_response = CircuitBreaker.fallback_logic(e) return fallback_response ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值