微服务架构体系
架构的演进
-
(1)单体应用:在第一阶段的单体应用很好理解。
-
(2)垂直应用:接着随着业务量增大, 将应用拆成互不相干的几个应用,Web框架(MVC) 是关键。
-
这一步,前后端分离、使用缓存、数据库和应用服务分离都会做, 但服务间是独立的无法调用,且可能存在重复代码。
-
(3)分布式应用:垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务。这时用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
-
集群、读写分离、反向代理、加速、分布式数据库、nosql、服务拆分都会处理、消息。
-
实现了服务调用,代码复用
-
(4)弹性流动计算:服务越来越多,容量评估,资源的使用等问题逐渐显现,需要调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的 资源调度和治理中心(SOA 面向服务架构) 是关键。
-
这时候要有一个注册中心,调用关系不需要自行维护了。
-
Dubbo 就是SOA的概念了,更关注RPC和服务治理。
-
(5)微服务:最后是通俗含义的微服务,使用 SpringCloud编码,使用Docker、K8S等,解决微服务软运维问题。
-
微服务本身也算是面向服务架构(SOA),它是SOA发展道路上的优化选择,关注的是服务拆分力度,即:如何将服务合理的拆的更细、更小
-
微服务需要关注点又更多,监控、日志、安全、调度、弹性容错等
微服务和SOA
-
微服务相比于SOA更加精细,微服务更多的以独立的进程的方式存在,互相之间并无影响,不再需要协调其它服务部署对本服务的影响;
-
微服务提供的接口方式更加通用化,如HTTP RESTful,各种终端都可以调用,无关语言、平台,所以技术可以更随意,只需要提供API
-
微服务更倾向于分布式去中心化的部署方式,数据的去中心化,也可以使用更不同的数据库技术;
-
微服务运维使用docker,k8s 可以自动化部署,集中管理
Spring Cloud 和 Dubbo
传输方式:
-
Dubbo底层用Netty这样的NIO框架,基于TCP协议传输的,配合以Hession序列化完成RPC通信;
-
SpringCloud基于Http协议+rest接口调用远程过程的通信,
-
相对来说,Http会有更大的报文,占的带宽也更多。但是REST相比RPC更灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更为合适,至于注重通信速度还是方便灵活性,具体情况具体考虑。
模块区别:
Dubbo 主要分为服务注册中心,服务提供者,服务消费者,还有管控中心;
SpringCloud则是一个完整的分布式一站式框架,服务注册中心,服务提供者,服务消费者,管控台,断路器,分布式配置服务,消息总线,以及服务追踪等;
架构 SpringCloud
流程:
-
请求统一通过 API 网关(Zuul)来访问内部服务。
-
网关接收到请求后,从注册中心(Eureka)获取可用服务。
-
由 Ribbon 进行均衡负载后,分发到后端具体实例。
-
微服务之间通过 Feign 进行通信处理业务。
-
Hystrix 负责处理服务超时熔断。
-
Turbine 监控服务间的调用和熔断相关指标。
架构 Dubbo
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 没有源码,如何修改代码逻辑?
· PowerShell开发游戏 · 打蜜蜂
· 在鹅厂做java开发是什么体验
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战