目录
大家好,我是哪吒。
一、前言
微服务已经是Java开发的必备技能,甲方不管项目大小,都想上微服务,感觉上了就高大上了,牛逼了。
微服务确实给我们带来了一定的便利性,但是也带来了麻烦,比如学习成本高,存在很多不可预见的问题。
我是做互联网项目的,刚开始的时候,用的是springboot+vue的单体架构,虽然也用了很多中间件,云服务器,数据库集群等,但终究还是单体服务,存在着一定的限制,随着业务架构的不断扩大,每次功能发布上线,都需要每个开发负责人对代码进行打包,再进行最后的代码合并,这时候,就会遇到各种各样的问题,代码忘记提交了,提交了忘记打包了,提交的时候忘记更新了,代码冲突了,jar包版本不统一、jar包版本冲突等各式各样的问题。
有一次项目部署测试,后台通过SVN提交记录进行增量打包,然后通过xshell进行Linux服务器程序更新,再重启。一套下来,差不多需要半个多小时的时间,而且因为缺少class文件的原因,反反复复更新了三次,我都要崩溃了~
你是否也遇到过同样的问题?
如果也是这样,是时候将架构升级为微服务了。分功能开发,每个小团队负责一个功能,然后部署为微服务,引入Docker容器技术。
系统架构经历了单体服务 -> 微服务架构 -> 容器化应用-> DevOps的发展历程。
微服务的概念是在2014年由Martin Fowler和James Lewis共同提出的,他们定义了微服务是由单一应用程序构成的小服务,拥有自己的进程和轻量化处理,按照业务功能分别处理,以全自动的方式部署,与其它服务使用HTTP API通讯。同时,服务会使用最小规模的集中管理(比如Docker),每个服务可以使用自己的语言和数据库。
二、单体服务的弊端
- 部署成本高,效率低下
- 团队协作开发成本高,两个人同时编写一个类,谁先提交谁舒服,哈哈
- 系统高可用性差,因为所有功能最后都部署在一个war包里,运行在同一个Tomcat进程中,一旦某一功能出现问题,就会导致整个系统的崩盘,虽然还有其它机器提供服务,但因为一个小问题,就挂了一个机器,这不蛋疼吗?
- 线上发布变慢,一般单体服务都是通过人工去更新代码,然后再重启,一个服务部署了16个机器,就要手动替换16次,而且可能还会有更多的服务。
想要解决以上问题,微服务应运而生。
三、微服务化
微服务化,在我看来就是将 传统的单机应用中通过jar包依赖产生的本地调用 改造成 通过RPC远程接口调用。对于一些通用的业务逻辑,想办法将其抽象并独立成专门的模块,因此对代码复用、分小组开发、单业务理解都大有裨益。
在最近的项目经历里,我深有体会,比如将一个项目分为公共模块、注册中心、网关模块、管理模块、某个单业务模块等。一个人一个模块,自己开发自己的,互不干预,每个模块独立开发,独立部署、独立测试、独立上线、独立运维,与其它模块基本上零联系。
可见,通过微服务化,可以解决应用单体膨胀,团队开发耦合度高、测试难、部署难的问题。
四、服务如何拆分?
比较常见的是根据不同的业务去拆分,一条业务线一个服务,这种拆分方式被称为纵向拆分,是从业务维度进行拆分。标准是按照业务关联程度来绝对,关联比较密切的业务适合拆分成一个微服务,而功能相对独立的业务适合拆分成一个微服务。
还有一种拆分方式是横向拆分,核心思想是拆分出通用共用的服务,就像单体服务中的工具类,供每个服务去调用。
无论是横向
五、使用微服务的注意事项
1、服务如何定义
对于微服务而言,每个服务都运行在各自的进程中,通过定义接口的形式去定义服务,约定好接口名、接口参数、接口返回值。
2、服务如何发布和订阅
单体应用时,将整个项目都部署在一个war包中,接口之间的调用属于进程内的方法调用。
在微服务架构中,可以将每个接口注册到注册中心,并由注册中心再对外提供服务。
3、服务如何监控
对于一个接口,我们最关心的是QPS(调用量)、AvgTime(平均耗时)、吞吐量等指标。这时候,需要一个通用的监控方案,能够覆盖所有业务接口,进行数据收集、数据处理、最后到数据展示的全链路功能。
4、服务如何治理
当某个服务有性能问题的时候,依赖的服务也会受到影响,可以根据实际情况设置一个阈值,超过这个时间就进行服务熔断,直接返回。
5、故障如何定位
在微服务中,一次用户请求可能会依赖多个服务,每个服务又部署在不同的节点上,如果用户请求出现问题,需要一种解决方案能够将一次用户请求进行标记,并在多个依赖的服务系统中继续传递,以便串联所有路径,从而进行故障定位。
🏆哪吒多年工作总结:Java学习路线总结,搬砖工逆袭Java架构师。
华为OD机试 2023B卷题库疯狂收录中,刷题++点这里++
刷的越多,抽中的概率越大,每一题都有详细的答题思路、详细的代码注释、样例测试,发现新题目,随时更新,全天CSDN在线答疑。