Spring Cloud微服务架构从入门到会用(一)—总览

本教程不定时更新,如果这些文章对你有帮助,请加个关注,谢谢!

本教程仅仅能教会大家怎么使用Spring Cloud的各个组件,没有深挖实现原理,要想精通就就看各位看官老爷们自己了。

微服务框架

在说微服务之前我们先大概了解下框架的演进(此处我们主要讲Java后端开发的演变过程)

1. 单体应用

最初我们使用的都是Spring + MyBatis/Hibernate/JDBC + Struts/SpringMVC + jsp,开发人员即写页面,又写Java逻辑一个人完成整个功能,开发完成后打成一个war包,部署到Tomcat里,然后为用户提供服务。
Spring Cloud微服务架构从入门到会用(一)—总览_第1张图片

2. 前后端分离

接下来Spring发布了SpringBoot,为了紧跟这个技术潮流,我们将开发框架切换为SpringBoot,采用前后分离的开发方式,前端用的是的jQuery,通过ajax与后台进行交互。这个时候我们变成了用nginx+jar的方式,把页面静态资源和后端服务分开了。
Spring Cloud微服务架构从入门到会用(一)—总览_第2张图片

3. 负载均衡

发展到前后端分离,一版情况能满足大部分的企业应用了,毕竟大部分企业应用使用的用户不是很多。但是有一部分企业应用用户量偏大,采用以上的架构,在用户集中使用的时候就会出现问题,比如学校的教务系统,平时大家看看通知,下载个文件,查查分数,但是到了每学期一度的选课,大家集中在一个时间,去登录系统去抢课,这个时候服务器可能就崩溃了,或者是页面一直在加载,刷不出页面。这个时候就要上负载均衡了,nginx的吞吐量很高,这个时候的性能瓶颈是后端服务,也就是部署的那个jar包,比如我们一个jar同时能支持100人,那我启动10个,通过nginx的反向代理,我代理10个jar,这个时候我们也能解决问题。
Spring Cloud微服务架构从入门到会用(一)—总览_第3张图片

4.微服务

采用了负载均衡的方案之后基本上就能满足更大一部分企业了,虽然能满足绝大部分企业了,但是有些企业的管理者觉得互联网公司上了微服务,我们也要上。这个时候我们的架构就要像微服务转变。那我们介绍下什么是微服务?所谓微服务它一定要“微”,也就是单一职责,一个服务只解决一个业务领域的问题;第二个是服务,对外提供我们能处理的业务服务。那么这么做有什么优点呢?

  • 一个服务只负责一个业务领域,影响小,集使某个服务宕机了其他服务还能正常使用
  • 代码量少,易于维护,不会很多人一起开发代码冲突
  • 便于迭代升级,不需要和其他应用一起上线
  • 耦合度低

当然,微服务也是有缺点的

  • 运维成本上升
  • 架构复杂度上升
  • 带来更多的需要解决的问题(不同服务间调用事务问题)

一个微服务架构的系统由几十甚至几百个微服务组成,各个服务直接互相依赖,服务如何拆封,内部接口规范,事务等等问题。尤其是服务拆分,需要团队非常熟悉业务流程,懂得取舍,要保证拆分的粒度服务既符合“高内聚,低耦合”的基本原则,还要兼顾业务的发展以及公司的愿景。

Spring Cloud微服务架构从入门到会用(一)—总览_第4张图片

Spring Cloud都有哪些组件(常用的6个组件)

  • 服务注册发现 —— Eureka
  • 服务网关——Spring Cloud Gateway
  • 客户端负载均衡——Ribbon
  • 熔断器——Hystrix
  • 分布式配置——Spring Cloud Config
  • 服务调用——Feign

以上组件时Spring Cloud官网提供的并建议使用的组件,我们呢要替换其中几个组件,替换为目前使用较多的,评价也比较好的组件

  • 熔断器——Hystrix -> Sentinel
  • 分布式配置——Spring Cloud Config -> Nacos

接下来我们将使用以上组件搭建一个Spring Cloud的工程,供大家参考学习。

在这里我想说一句,没有最好的架构,只有最适合的架构,比如公司要开发一个报销系统,你非得上微服务就没有意义了,增加了开发成本,增加了运维成本。再比如你们公司突然要发展电商,要开发一个商城系统,如果你还用springmvc,弄一个工程部署到tomcat里,那就是不负责任的表现。当然,选择某一个架构不只是根据业务,也要根据公司的实际情况去考虑,公司有没有那么多成本让你搞微服务,或者是暂时先上单体应用,然后慢慢再搞微服务。

你可能感兴趣的:(Spring,Cloud)