微服务保护

一，微服务保护 1.1 雪崩问题 在微服务远程调用的过程中，还存在几个问题需要解决。 首先是业务健壮性问题： 例如在之前的查询购物车列表业务中，购物车服务需要查询最新的商品信息，与购物车数据做对比，提醒用户。大家设想一下，如果商品服务查询时发生故障，查询购物车列表在调用商品服 务时，是不是也会异常？

统一配置管理

一，统一配置管理 到目前为止我们已经解决了微服务相关的几个问题： 微服务远程调用 微服务注册、发现 微服务请求路由、负载均衡 微服务登录用户信息传递 不过，现在依然还有几个问题需要解决： 网关路由在配置文件中写死了，如果变更必须重启微服务 某些业务配置在配置文件中写死了，每次修改都要重启服务 每个微

网关路由

一，网关路由 由于每个微服务都有不同的地址或端口，入口不同，在与前端联调的时候存在问题： 请求不同数据时要访问不同的入口，需要维护多个入口地址，麻烦 前端无法调用nacos，无法实时更新服务列表 单体架构时我们只需要完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息。而微服务拆分后，每个微

OpenFeign

一，OpenFeign 1.1 介绍 我们利用Nacos实现了服务的治理，利用RestTemplate实现了服务的远程调用。但是远程调用的代码太复杂了： 而且这种调用方式，与原本的本地方法调用差异太大，编程时的体验也不统一，一会儿远程调用，一会儿本地调用。 因此，我们必须想办法改变远程调用的开发模式

注册中心

一，为什么需要注册中心 实现了微服务拆分，并且通过Http请求实现了跨微服务的远程调用。不过这种手动发送Http请求的方式存在一些问题，试想一下，假如商品微服务被调用较多，为了应对更高的并发，我们进行了多实例部署，如图： 此时，每个item-service的实例其IP或端口不同，问题来了： item

拆分微服务

一，认识微服务 1.1 单体架构 单体架构（monolithic structure）：顾名思义，整个项目中所有功能模块都在一个工程中开发；项目部署时需要对所有模块一起编译、打包；项目的架构设计、开发模式都非常简单。 当项目规模较小时，这种模式上手快，部署、运维也都很方便，因此早期很多小型项目都采用