拆分系统(我设计了一套微服务系统，可是上了生产环境直接崩溃…)

Posted 2023-05-27

篇首语：没有拆不散的夫妻，只有不努力的小三。本文由小常识网(cha138.com)小编为大家整理，主要介绍了拆分系统(我设计了一套微服务系统，可是上了生产环境直接崩溃…)相关的知识，希望对你有一定的参考价值。

拆分系统(我设计了一套微服务系统，可是上了生产环境直接崩溃…)

单体架构
微服务架构
服务治理之注册与发现和负载均衡
服务治理之限流熔断
服务治理之服务监控

今天给大家分享一个话题，是关于微服务架构的服务治理的，很多小伙伴可能都觉得自己玩儿过微服务架构，然后可能也听说过服务治理，但是服务治理到底是什么，有哪些东西，服务治理到底应该怎么来做，这个可能就一头雾水了。

所以今天就给大家聊聊这个微服务架构下的服务治理。

单体架构

首先，要说到微服务架构，那么先来讲讲，大家平时玩儿微服务架构到底是怎么来弄的。

其实说来也特简单，以前没有上微服务的时候，可能直接就是 SpringBoot+SSM 这一套架构就直接写一个单块新系统就 ok 了，用 SpringBoot 打一个 jar 包，然后 jar 包部署到线上系统以后，直接用 java -jar 命令启动 JVM 进程运行咱们的代码就行了。

用 SpringBoot 的时候一般对外接收 Http 请求的 Web 服务器是内嵌的 Tomcat，就是 SpringBoot 基于 main 方法启动之后，内嵌启动一个 Tomcat，Tomcat 会对外监听一个端口号，然后我们就针对那个端口号发起 Http 请求就可以了。

如下图：

微服务架构

所以这个时候咱们的系统从本质上来说，他就是一个单块系统，那如果升级到微服务架构的话，应该是怎么样的呢？

微服务的话，意思就是说把原来一个单块系统拆分成很多个服务，服务跟服务之间是通过 Nacos+Dubbo 这种服务注册中心和 RPC 框架来进行调用的。

5 年以前一般业内常用的微服务基础框架是 Dubbo+Zookeeper 的组合，但是 3 年以前基本都过渡到了 SpringCloud 技术栈做微服务架构。

一两年前开始业内基本慢慢过渡到了 SpringCloud Alibaba 技术栈，就是说，用 Nacos 作为服务注册中心，用 Dubbo 作为 RPC 框架，所以我们就以 SpringCloud Alibaba 的 Nacos+Dubbo 组合来举例。

搞微服务的话，就是说，让各个服务都注册到 Nacos 里去，然后服务要调用别的服务，就通过 Nacos 进行服务发现，接着通过 Dubbo 进行 RPC 调用。

如下图：

就跟这个图一样，其实很多服务互相之间调用，大致可以就先理解为一个微服务的架构了，因为我们的单块系统已经被拆分为了很多的服务了。那么接着来说，我们对于这种微服务架构如何进行服务治理呢？

服务治理之注册与发现和负载均衡

首先要跟大家说的一点是，服务治理的第一个事儿，其实就是服务注册和发现，所以说，通过 Nacos 实现服务注册和发现，就已经干了服务治理的第一个事儿了。

好，那么服务治理的第二个事儿是什么呢？其实就是负载均衡，这个负载均衡是什么意思呢？其实就是说，我们每个服务都可以部署多台机器，就有多个服务实例。

那么一个服务可以发现另外一个服务实例的多台机器，到底应该调用哪一台呢？

这个时候就得用负载均衡算法了，用算法找到一台机器，然后就可以针对那台机器发起一次 RPC 调用。这个负载均衡的活儿，就是 Dubbo 给我们干的。

如下图：

服务治理之限流熔断

接着呢，这个服务治理里面第三个事儿，就是限流熔断，分两块来说，因为限流是用来防止系统被压垮的，熔断是用来防止系统被拖垮的。

先说限流，假设你的系统正常最多只能抗每秒 1000 个请求，结果此时来了每秒 2000 个请求，会如何？

当然会压垮你的系统了，所以此时我们就必须做一个限流，如果每秒超过了 1000 个请求，后续的请求全部都直接返回禁止访问。

如下图：

然后来说熔断，熔断的意思是说，如果你调用一个系统，结果那个系统挂了，然后你每次调用他都是失败失败失败，而且每次失败还得阻塞一会儿那不就把你自己给拖垮了吗？

所以这个时候就必须上熔断，如果一旦发现要是在一段时间内频繁调用别人失败，此时就触发熔断，熔断之后，就每次请求过来直接报错返回。

如下图：

那么这个限流和熔断是靠谁给你干呢？SpringCloud Alibaba 里的 Sentinel 就可以把这个事儿给你干了，所以限流熔断这块工作是他给干的。

服务治理的下一个活儿是配置中心，就是说，平时咱们系统的配置是不是都是放在 src/main/rsource 目录下的各种 properties 和 xml 文件。

但是如果你要是系统部署上线了，你要修改配置，就只能修改代码里的配置，然后重新打包部署上线，这太麻烦了，对不对。

所以如果引入一个配置中心，系统的一些核心配置直接从配置中心里动态加载，然后如果要修改配置直接在配置中心里修改。

接着线上系统直接就感知到最新配置运用就可以了，那就不用每次修改配置都打包重新部署了，这个配置中心的活儿是 Nacos 给我们干的。

如下图：

服务治理之服务监控

然后服务治理的最后一个环节，就是服务监控，这个监控包括了很多内容，比如说对线上系统部署的各个服务器的 CPU、内存、磁盘、网络、IO 进行监控，以及对线上系统的 JVM GC 进行监控，包括对线上系统的各个接口的 QPS 和延迟进行监控。

同时还可以对线上微服务系统的各个服务之间进行调用的调用链路进行监控，这些事情通常是用 Prometheus 和 Skywalking 两个监控系统配合完成的。

Skywalking 通常可以追踪我们的微服务调用链路，Prometheus 可以对我们的线上系统的服务器、JVM 以及接口各个层次进行监控。

如下图：

好了，今天给大家介绍的微服务治理的内容到这里就结束了。若有收获，就点个赞吧！

------------- END -------------

另外推荐儒猿课堂的1元系列课程给您，欢迎加入一起学习~

互联网Java工程师面试突击课（1元专享）「链接」

SpringCloudAlibaba零基础入门到项目实战（1元专享）「链接」

亿级流量下的电商详情页系统实战项目（1元专享）「链接」

Kafka消息中间件内核源码精讲（1元专享）「链接」

12个实战案例带你玩转Java并发编程（1元专享）「链接」

Elasticsearch零基础入门到精通（1元专享）「链接」

基于Java手写分布式中间件系统实战（1元专享）「链接」

基于ShardingSphere的分库分表实战课（1元专享）「链接」