本教程不定时更新,如果这些文章对你有帮助,请加个关注,谢谢!
本教程仅仅能教会大家怎么使用Spring Cloud的各个组件,没有深挖实现原理,要想精通就就看各位看官老爷们自己了。
微服务框架
在说微服务之前我们先大概了解下框架的演进(此处我们主要讲Java后端开发的演变过程)
1. 单体应用
最初我们使用的都是Spring + MyBatis/Hibernate/JDBC + Struts/SpringMVC + jsp,开发人员即写页面,又写Java逻辑一个人完成整个功能,开发完成后打成一个war包,部署到Tomcat里,然后为用户提供服务。
2. 前后端分离
接下来Spring发布了SpringBoot,为了紧跟这个技术潮流,我们将开发框架切换为SpringBoot,采用前后分离的开发方式,前端用的是的jQuery,通过ajax与后台进行交互。这个时候我们变成了用nginx+jar的方式,把页面静态资源和后端服务分开了。
3. 负载均衡
发展到前后端分离,一版情况能满足大部分的企业应用了,毕竟大部分企业应用使用的用户不是很多。但是有一部分企业应用用户量偏大,采用以上的架构,在用户集中使用的时候就会出现问题,比如学校的教务系统,平时大家看看通知,下载个文件,查查分数,但是到了每学期一度的选课,大家集中在一个时间,去登录系统去抢课,这个时候服务器可能就崩溃了,或者是页面一直在加载,刷不出页面。这个时候就要上负载均衡了,nginx的吞吐量很高,这个时候的性能瓶颈是后端服务,也就是部署的那个jar包,比如我们一个jar同时能支持100人,那我启动10个,通过nginx的反向代理,我代理10个jar,这个时候我们也能解决问题。
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里,那就是不负责任的表现。当然,选择某一个架构不只是根据业务,也要根据公司的实际情况去考虑,公司有没有那么多成本让你搞微服务,或者是暂时先上单体应用,然后慢慢再搞微服务。