tack_back的博客

目录：1、为什么需要链路追踪2、链路追踪技术对比选型3、集成skywalking4、skywalking原理为什么需要链路追踪当我们把一个系统拆分为一个个的微服务之后，那么一个请求就可能需要多个服务协同才能完成。比如用户下单这个请求，就可能会涉及到商品服务、订单服务、支付服务、仓储服务。假如整个流程是这样的：在这个流程中无论哪个服务处理失败，都会导致下单这个操作不成功。那么如何能快速定位在哪个服务中发生了异常？这就需要链路追踪了。链路追踪对比选型目前使用的比较多的有：1、cat——大

目录：1、为什么需要监控中心2、监控中心对比选型3、集成Prometheus4、Prometheus原理为什么需要监控中心在我们开发完一个系统部署上线后，经常会遇到机器的CPU、内存、磁盘、IO、网络等资源负载过高的问题。那我们总不能说天天对着这些机器，通过一些命令去观察这些机器资源使用的情况。所以我们就需要一个这样的控制中心用来监控我们机器和系统的资源使用情况，通过图形化的界面来直观的去观察这些信息，同时也能设置一些阈值，当资源使用率达到阈值时能进行自动预警。监控中心组件对比选型目前比较主

目录：1、为什么需要配置中心2、配置中心组件对比选型3、集成Apollo4、Apollo原理为什么需要配置中心假如我们系统的系统要去调用另一个系统的接口，于是我们在配置文件里面配置了如下一行配置。guiji.company.url = 118.118.118.18/sendMoney突然有一天，调用的这个系统地址变了。那么这个时候我们就需要去调整我们配置文件里面的这个地址了，而且调整了之后需要重启才能够生效。在白天的时候流量比较大，不能进行重启。所以只能等到凌晨1、2点的时候，把这个配置

目录：1、为什么需要熔断降级2、熔断降级框架对比选型3、集成Sentinel4、Sentinel原理为什么需要熔断降级在微服务化的系统中会存在一个比较严重的问题，叫做服务雪崩。服务雪崩是怎么发生的呢？如上图，假设一个用户进行一个下单操作，商品服务需要调用订单服务添加订单数据，下单成功后，订单服务又需要调用积分服务给下单成功的用户增加一些积分。要是有一天，积分服务突然挂了。这时一个下单请求过来的话，在订单服务调用积分服务时，因为积分服务挂了。请求一直卡在这里，等到过了设置的超时时间，才返回请

目录：1、什么是分布式事务2、分布式事务解决方案3、集成seata4、seata原理什么是分布式事务在服务拆分之后，完成某一个功能可能需要横跨多个服务，操作多个数据库。之前操作单一的数据库，只需要保证在这个数据库中执行的操作要么一起成功，要么一起失败。这种事务叫做本地事务。而操作多个数据库，要保证多个数据库里的操作一起成功或失败的事务就是分布式事务。上图中有库存服务和订单服务，库存服务和订单服务都有自己单独的数据库。在一个下单操作中，需要先调用库存服务减去相应的库存，然后再调用订单服务

目录：1、为什么需要RPC框架2、RPC框架对比选型3、RPC框架使用4、RPC框架原理为什么需要RPC框架在没有使用微服务之前，我们所有的代码都在一个项目中，都部署在同一个tomcat里，所有的调用都是本地调用，就用不上RPC框架。但是当我们把一个系统拆分成多个服务之后，每个服务都独立部署。服务之间要相互调用，就需要通过远程调用了。RPC（Remote Procedure Call）远程过程调用，其实就是一个服务调用另一个服务提供的接口。比较典型的就是HTTP接口调用了，一个服务对外提供一

目录：1、为什么需要注册中心2、注册中心技术组件选型3、注册中心搭建4、注册中心原理为什么需要注册中心将一个项目拆分成多个服务之后，服务之间就可能会相互进行调用通讯，来完成一个完整的功能。如果A服务要调用B服务，那么A服务是如何知道B服务的地址和端口的呢？总不能在配置文件里面写死吧。这样的话要是B服务增加一个实例，那不是就要去修改这个配置。或是B服务有个实例挂掉了，由于配置文件没有修改，A服务还一直在调用这个挂掉的实例。所以这就需要配置中心了。所有服务启动后都会把地址和端口等相关的信息注册到注册

目录：1、单体应用的缺点2、微服务的出现3、微服务带来的问题单体应用的缺点在之前我们开发一个应用，就是在我们本地把功能实现好，然后把整个应用打成一个war包，部署到一个web容器里面，这样在浏览器里面就能够访问我们的项目了。这样的一个应用我们称之为单体应用。这种应用开发简单，所有的功能都在本地，没有调用消耗。但是随着业务的发展，应用功能不断增加，几年之后这个应用变的又大又复杂。这个时候这种应用的缺点就凸显出来了。单体应用架构如下：缺点：1、效率低：可能这个项目由10几个开发在维护，所有人都