前后分离 axios 接 api 跨域问题如图： 解决办法： 1. npm start 本地开发环境解决： 在webpack配置文件 /config/index.js 里找到 proxyTable 开启代理 changeOrigin:true, 2. npm run build 把 dist 放线上后解决： nginx 的 配置文件 xx.conf 的 server {} 里加如下： 支付 ¥4.99 购买本节后解锁剩余7%的内容 微信支付 如已付费购买，请免登录验证。

结论，简单理解为：代理的地址在端口以后如果有东西(包括目录或者/),转发地址会去除location匹配的目录(根据匹配的字符，如果是/api则去除api，如果是/api/则去除/api/) 如果代理地址到端口就没了(没有目录或/),那么转发地址会保留匹配目录 后期对照 alias与root的区别 参考一 ：proxy_pass 1.location和proxy_pass都带/，则真实地址不带location匹配目录 location /api/{proxy_pass http://127.0.0.1:8080/;}…

最大的区别：Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于TCP 协议传输的，配合以 Hession 序列化完成 RPC 通信。 而 SpringCloud 是基于 Http 协议+Rest 接口调用远程过程的通信，相对来说，Http 请求会有更大的报文，占的带宽也会更多。但是REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖。

Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的优势之上，两个框架在开始目标就不一致，Dubbo定位服务治理、Spirng Cloud 是一个生态。

dubbox 基于dubbo上做了一些扩展，如加了服务可restful调用，更新了开源组件等。

Dubbo 通过 Token 令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo 还提供服务黑白名单，来控制服务所允许的调用方。

Dubbo在调用服务不成功时，默认是会重试两次的。

Random LoadBalance: 随机选取提供者策略，有利于动态调整提供者权重。截面碰撞率高，调用次数越多，分布越均匀； RoundRobin LoadBalance: 轮循选取提供者策略，平均分布，但是存在请求累积的问题； LeastActive LoadBalance: 最少活跃调用策略，解决慢提供者接收更少的请求； ConstantHash LoadBalance: 一致性 Hash 策略，使相同参数请求总是发到同一提供者，一台机器宕机，可以基于虚拟节点，分摊至其他提供者，避免引起提供者的剧烈变动；缺省…

默认使用 NIO Netty 框架。

Dubbo 采用全 Spring 配置方式，透明化接入应用，对应用没有任何API 侵入，只需用 Spring 加载 Dubbo 的配置即可，Dubbo 基于Spring 的 Schema 扩展进行加载。