跨域问题，解决之道

跨域问题，在平常开发过程当中，是一个很是熟悉的名词。今天的话题，结合我以前的项目场景，讨论下《跨域问题，解决之道》。

原文地址：跨域问题，解决之道
博客地址：blog.720ui.com/

跨域是什么

跨域问题，是因为JavaScript出于安全方面的考虑，不容许跨域调用其余页面的对象。换句话说，只有JavaScript存在跨域问题。

什么状况下会出现跨域

不一样源访问，就算是跨域了哟。那什么才算同源呢？通常来讲，同源，即同一来源，包括主机名、协议和端口号。
例如，

• blog.720ui.com 和 docs.720ui.com ，是不一样的二级域名，存在跨域问题。
• blog.720ui.com 和 blog.720ui.com , 是不一样的协议，存在跨域问题
• blog.720ui.com 和 blog.720ui.com:4000 , 是不一样的端口号，存在跨域问题。
• blog.720ui.com/java/ 和 blog.720ui.com/about/, 虽然文件夹不一样，可是是相同域名下，因此不存在跨域问题。

跨域问题广泛么

在如今先后端分离，微服务化以后，每每咱们就存在许多不一样的域名，这种状况下，就存在很是广泛的跨域问题。所以，跨域问题，在平常开发过程当中，是一个很是熟悉的名词。那么，咱们是如何去解决跨域问题呢？

解决之道

咱们是如何去解决跨域问题呢？来吧，咱们进入正题。

方案一，JSONP（废弃）

很早很早以前，我有个项目曾经使用过JSONP处理跨域问题。简单的理解，jsonp是带有回调函数callback的json，它是一个很棒的方案，可用于解决主流浏览器的跨域数据访问的问题。可是，JSONP方案的局限性在于，JSONP只能实现GET请求。随着如今RESTful的兴起，JSONP显得力不从心了。由于，RESTful不只有GET，还存在POST、PUT、PATCH、DELETE。

方案二，CORS（经常使用）

CORS 全称为 Cross Origin Resource Sharing（跨域资源共享）。整个CORS通讯过程，都是浏览器自动完成，不须要用户参与。对于开发者来讲，CORS通讯与同源的AJAX通讯没有差异，代码彻底同样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，但用户不会有感受。所以，实现CORS通讯的关键是服务端。服务端只需添加相关响应头信息，便可实现客户端发出 AJAX 跨域请求。

值得注意的是，浏览器必须先以 OPTIONS 请求方式发送一个预请求，从而获知服务器端对跨源请求所支持 HTTP 方法。在确认服务器容许该跨源请求的状况下，以实际的 HTTP 请求方法发送那个真正的请求。

咱们绝大多数项目采起这个方案，实现细节，再也不扩展，若是有疑问，能够关注公众号私信，或者评论留言哟。

可是，不幸的是，CORS不支持IE八、IE9，若是产品再也不考虑兼容IE低版本的话，能够忽略，可是若是产品须要兼容目前国内还存在大量低版本的IE市场（百分之二十多），那么这个须要慎重考虑咯。

附图，留念。

方案三，搭建中间转发层（经常使用）

跨域问题的核心是什么？不一样源访问。是啊，若是咱们转换成同源请求，就不存在这个问题啦。

所以，咱们以前有个项目，经过搭建中间层，固然能够是java，也能够是node.js，经过将服务端的请求进行转发，换句话说，就是dispatcher了一层，那么前端请求的地址，就被转发了，因此很好的解决跨域问题。

固然，若是对性能有考量的产品，就须要慎重选择这个方案咯，由于多了一层中间转发，不论是网络开销，仍是性能负载都是有必定的影响。

方案四，Nginx反向代理（经常使用）

首先，产品须要搭建一个中转nginx服务器，用于转发请求。固然，咱们都是基于Nginx做为反向代理，因此固然是水到渠成。

那么，Nginx的思路，就是经过Nginx解析URL地址的时候进行判断，将请求转发的具体的服务器上。

说个思路，可能有点晕，我画个图，你们就理解了。

当用户请求xx.720ui.com/server1的时候，Nginx会将请求转发给Server1这个服务器上的具体应用，从而达到跨域的目的。

总结

跨域问题，在平常开发过程当中，是一个很是熟悉的名词。咱们在开发过程当中，或多或少都与它打过交道，所以，今天的话题，结合我以前的项目场景，以及JSONP、CORS、中间转发层、Nginx反向代理四个方案进行总结，讨论下《跨域问题，解决之道》。

（完）

更多精彩文章，尽在「服务端思惟」微信公众号！