单体架构首先，要说到微服务架构，那么先来讲讲，大家平时玩儿微服务架构到底是怎么来弄的，其实说来也特简单，以前没有上微服务的时候，可能直接就是spring boot+ssm这一套架构就直接写一个单块新系统就ok了，用spring boot打一个jar包，然后jar包部署到线上系统以后，直接用java -jar命令启动jvm进程运行咱们的代码就行了。 用spring boot的时候一般对外接收http请求的web服务器是内嵌的tomcat，就是spring boot基于main方法启动之后，内嵌启动一个tomcat，tomcat会对外监听一个端口号，然后我们就针对那个端口号发起http请求就可以了，如下图。  微服务架构所以这个时候咱们的系统从本质上来说，他就是一个单块系统，那如果升级到微服务架构的话，应该是怎么样的呢？微服务的话，意思就是说把原来一个单块系统拆分成很多个服务，服务跟服务之间是通过nacos+dubbo这种服务注册中心和rpc框架来进行调用的。 5年以前一般业内常用的微服务基础框架是dubbo+zookeeper的组合，但是3年以前基本都过渡到了spring cloud技术栈做微服务架构，一两年前开始业内基本慢慢过渡到了spring cloud alibaba技术栈，就是说，用nacos作为服务注册中心，用dubbo作为rpc框架。 所以我们就以spring cloud alibaba的nacos+dubbo组合来举例，搞微服务的话，就是说，让各个服务都注册到nacos里去，然后服务要调用别的服务，就通过nacos进行服务发现，接着通过dubbo进行rpc调用，如下图。  就跟这个图一样，其实很多服务互相之间调用，大致可以就先理解为一个微服务的架构了，因为我们的单块系统已经被拆分为了很多的服务了。那么接着来说，我们对于这种微服务架构如何进行服务治理呢？ 服务治理之注册与发现和负载均衡首先要跟大家说的一点是，服务治理的第一个事儿，其实就是服务注册和发现，所以说，通过nacos实现服务注册和发现，就已经干了服务治理的第一个事儿了。好，那么服务治理的第二个事儿是什么呢？其实就是负载均衡，这个负载均衡是什么意思呢？其实就是说，我们每个服务都可以部署多台机器，就有多个服务实例。 那么一个服务可以发现另外一个服务实例的多台机器，到底应该调用哪一台呢？这个时候就得用负载均衡算法了，用算法找到一台机器，然后就可以针对那台机器发起一次rpc调用。这个负载均衡的活儿，就是dubbo给我们干的，如下图。  服务治理之限流熔断接着呢，这个服务治理里面第三个事儿，就是限流熔断，分两块来说，因为限流是用来防止系统被压垮的，熔断是用来防止系统被拖垮的，先说限流，假设你的系统正常最多只能抗每秒1000个请求，结果此时来了每秒2000个请求，会如何？当然会压垮你的系统了，所以此时我们就必须做一个限流，如果每秒超过了1000个请求，后续的请求全部都直接返回禁止访问，如下图。  然后来说熔断，熔断的意思是说，如果你调用一个系统，结果那个系统挂了，然后你每次调用他都是失败失败失败，而且每次失败还得阻塞一会儿那不就把你自己给拖垮了吗？所以这个时候就必须上熔断，如果一旦发现要是在一段时间内频繁调用别人失败，此时就触发熔断，熔断之后，就每次请求过来直接报错返回，如下图。  那么这个限流和熔断是靠谁给你干呢？spring cloud alibaba里的sentinel就可以把这个事儿给你干了，所以限流熔断这块工作是他给干的。 服务治理的下一个活儿是配置中心，就是说，平时咱们系统的配置是不是都是放在src/main/rsource目录下的各种 properties和xml文件？但是如果你要是系统部署上线了，你要修改配置，就只能修改代码里的配置，然后重新打包部署上线，这太麻烦了，对不对。 所以如果引入一个配置中心，系统的一些核心配置直接从配置中心里动态加载，然后如果要修改配置直接在配置中心里修改，接着线上系统直接就感知到最新配置运用就可以了，那就不用每次修改配置都打包重新部署了，这个配置中心的活儿是nacos给我们干的，如下图。  服务治理之服务监控然后服务治理的最后一个环节，就是服务监控，这个监控包括了很多内容，比如说对线上系统部署的各个服务器的cpu、内存、磁盘、网络、io进行监控，以及对线上系统的jvm gc进行监控，包括对线上系统的各个接口的QPS和延迟进行监控，同时还可以对线上微服务系统的各个服务之间进行调用的调用链路进行监控，这些事情通常是用prometheus和skywalking两个监控系统配合完成的。 skywalking通常可以追踪我们的微服务调用链路，prometheus可以对我们的线上系统的服务器、jvm以及接口各个层次进行监控，如下图。  好了，今天给大家介绍的微服务治理的内容到这里就结束了 |
|
|
