微服务架构之路1,服务如何拆分?使用微服务的注意事项?

在这里插入图片描述

目录

    • 一、前言
    • 二、单体服务的弊端
    • 三、微服务化
    • 四、服务如何拆分?
    • 五、使用微服务的注意事项
      • 1、服务如何定义
      • 2、服务如何发布和订阅
      • 3、服务如何监控
      • 4、服务如何治理
      • 5、故障如何定位

大家好,我是哪吒。

一、前言

微服务已经是Java开发的必备技能,甲方不管项目大小,都想上微服务,感觉上了就高大上了,牛逼了。

微服务确实给我们带来了一定的便利性,但是也带来了麻烦,比如学习成本高,存在很多不可预见的问题。

我是做互联网项目的,刚开始的时候,用的是springboot+vue的单体架构,虽然也用了很多中间件,云服务器,数据库集群等,但终究还是单体服务,存在着一定的限制,随着业务架构的不断扩大,每次功能发布上线,都需要每个开发负责人对代码进行打包,再进行最后的代码合并,这时候,就会遇到各种各样的问题,代码忘记提交了,提交了忘记打包了,提交的时候忘记更新了,代码冲突了,jar包版本不统一、jar包版本冲突等各式各样的问题。

有一次项目部署测试,后台通过SVN提交记录进行增量打包,然后通过xshell进行Linux服务器程序更新,再重启。一套下来,差不多需要半个多小时的时间,而且因为缺少class文件的原因,反反复复更新了三次,我都要崩溃了~

你是否也遇到过同样的问题?

如果也是这样,是时候将架构升级为微服务了。分功能开发,每个小团队负责一个功能,然后部署为微服务,引入Docker容器技术。

系统架构经历了单体服务 -> 微服务架构 -> 容器化应用-> DevOps的发展历程。

微服务的概念是在2014年由Martin Fowler和James Lewis共同提出的,他们定义了微服务是由单一应用程序构成的小服务,拥有自己的进程和轻量化处理,按照业务功能分别处理,以全自动的方式部署,与其它服务使用HTTP API通讯。同时,服务会使用最小规模的集中管理(比如Docker),每个服务可以使用自己的语言和数据库。

二、单体服务的弊端

  1. 部署成本高,效率低下
  2. 团队协作开发成本高,两个人同时编写一个类,谁先提交谁舒服,哈哈
  3. 系统高可用性差,因为所有功能最后都部署在一个war包里,运行在同一个Tomcat进程中,一旦某一功能出现问题,就会导致整个系统的崩盘,虽然还有其它机器提供服务,但因为一个小问题,就挂了一个机器,这不蛋疼吗?
  4. 线上发布变慢,一般单体服务都是通过人工去更新代码,然后再重启,一个服务部署了16个机器,就要手动替换16次,而且可能还会有更多的服务。

想要解决以上问题,微服务应运而生。

三、微服务化

微服务化,在我看来就是将 传统的单机应用中通过jar包依赖产生的本地调用 改造成 通过RPC远程接口调用。对于一些通用的业务逻辑,想办法将其抽象并独立成专门的模块,因此对代码复用、分小组开发、单业务理解都大有裨益。

在最近的项目经历里,我深有体会,比如将一个项目分为公共模块、注册中心、网关模块、管理模块、某个单业务模块等。一个人一个模块,自己开发自己的,互不干预,每个模块独立开发,独立部署、独立测试、独立上线、独立运维,与其它模块基本上零联系。

可见,通过微服务化,可以解决应用单体膨胀,团队开发耦合度高、测试难、部署难的问题。

四、服务如何拆分?

比较常见的是根据不同的业务去拆分,一条业务线一个服务,这种拆分方式被称为纵向拆分,是从业务维度进行拆分。标准是按照业务关联程度来绝对,关联比较密切的业务适合拆分成一个微服务,而功能相对独立的业务适合拆分成一个微服务。

还有一种拆分方式是横向拆分,核心思想是拆分出通用共用的服务,就像单体服务中的工具类,供每个服务去调用。

五、使用微服务的注意事项

1、服务如何定义

对于微服务而言,每个服务都运行在各自的进程中,通过定义接口的形式去定义服务,约定好接口名、接口参数、接口返回值。

2、服务如何发布和订阅

单体应用时,将整个项目都部署在一个war包中,接口之间的调用属于进程内的方法调用。

在微服务架构中,可以将每个接口注册到注册中心,并由注册中心再对外提供服务。

3、服务如何监控

对于一个接口,我们最关心的是QPS(调用量)、AvgTime(平均耗时)、吞吐量等指标。这时候,需要一个通用的监控方案,能够覆盖所有业务接口,进行数据收集、数据处理、最后到数据展示的全链路功能。

4、服务如何治理

当某个服务有性能问题的时候,依赖的服务也会受到影响,可以根据实际情况设置一个阈值,超过这个时间就进行服务熔断,直接返回。

5、故障如何定位

在微服务中,一次用户请求可能会依赖多个服务,每个服务又部署在不同的节点上,如果用户请求出现问题,需要一种解决方案能够将一次用户请求进行标记,并在多个依赖的服务系统中继续传递,以便串联所有路径,从而进行故障定位。


哪吒多年工作总结:Java学习路线总结,搬砖工逆袭Java架构师

华为OD机试 2023B卷题库疯狂收录中,刷题点这里

刷的越多,抽中的概率越大,每一题都有详细的答题思路、详细的代码注释、样例测试,发现新题目,随时更新,全天CSDN在线答疑。

你可能感兴趣的:(SpringCloud实战教程,架构,微服务,云原生)