近年来,前后端拆散曾经成为中大型软件我的项目开发的最佳实际。
在技术层面,前后端拆散指在同一个 Web 零碎中,前端服务器和后端服务器采纳不同的技术栈,利用规范的 WebAPI 实现协同工作。这种前后端拆散的 ” 混合开发 ” 模式下,前后端通常会部署到不同的服务器上,即使部署在同一台机器,因为宿主程序(如后端用 Tomcat,前端用 nginx)不同,端口号也很难对立。
(图片起源网络)
这意味着位于 A 域(如 https://foo:80/website)的页面,须要调用 B 域的 WebAPI(如 https://bar:8080/webservice),这是一个典型的跨域拜访,浏览器默认会断定该操作有平安危险。如果不进行解决,则会回绝这次 WebAPI 调用,提醒对应的谬误。
(跨域申请导致的谬误)
当初如何该怎么解决跨域的问题呢?目前有 4 个支流技术计划:
JSONP
如果你须要解决的申请只有 GET,能够思考 JSONP。
JSONP 的原理就是利用 \<script\> 标签没有跨域限度的特点,通过 \<script\> 标签 src 属性,发送带有 callback 参数的 GET 申请,服务端将接口返回数据拼凑到 callback 函数中,返回给浏览器,浏览器解析执行,从而前端拿到 callback 函数返回的数据。
(JSONP 的调用流程)
这种做法很惯例,然而你须要为前端提供 JSONP 的响应,其余终端调用时提供不带 JSONP 的响应,因而会带来额定的开发和测试工作量。
iFrame
通常状况下,前后端拆散带来的跨域拜访都局限在同一个主域的不同子域(如 a.foo.com 和 b.foo.com)之间。所以,你能够利用 iFrame 加载位于被调用 WebAPI 所在域的页面,而后将两个页面的 document.domain 设置为主域名(如 foo.com),就通过 iFrame 中的子页面申请 WebAPI 了。
(图片起源网络)
这种做法比拟麻烦,咱们须要为 WebAPI 配套开发起直达作用的页面,但对于开发者而言仍旧有很大的开发工作量。
CORS
和前两种计划相比,CORS(跨域资源共享)是一个 ” 一劳永逸 ” 的计划。
咱们不须要为每个 WebAPI 做额定的解决,而是须要在后端程序启动时,减少一些解决工作。支流的后端服务都有解决 CORS 的类库,这里就不再做开展介绍了。
这个计划的外围原理,是在发动正式的申请前,先发送一个 OPTIONS 谓词的 HTTP 申请,询问发动申请的页面是否有调用该域服务的权限;如果后端说 OK,浏览器就持续申请,否则提醒谬误。
应用这种计划的开发工作量小,如果间接应用成熟类库的话,开发和测试的工作量甚至能够忽略不计。不过,因为每个跨域的申请都会触发一次往外的 OPTIONS 申请,对服务器会造成额定的开销和压力。
反向代理
反向代理机制,把前端的 A 域和后端的 B 域合并成一个 C 域,从根本上解决跨域问题。
这个计划仅需配置,对前后端的程序没有侵入;同时内网中的反向代理通常也不会带来额定的性能开销。
(图片起源网络)
总体来说在编码开发的时代,上述四种计划都有实用的利用场景,各有优缺点。进入低代码开发时代后,前后端拆散的利用面更广,如应用 JavaScript 编码开发前端、配合低代码构建的后端,或应用 Java 编码开发后端,供低代码构建的前端调用。
(低代码时代的前后端拆散,来自 低代码沙龙)
低代码开发的外围价值在于节俭开发投入,晋升开发效率,所以,计划 1(JSONP)和计划 2(iFrame)曾经很少被用到低代码混合开发畛域。相比于计划 3(CORS),计划 4(反向代理)因为性能开销较小,利用场景会更多一些。
上面,咱们将以活字格 +nginx 为例,介绍利用 nginx 解决跨域问题,实现前后端拆散的具体做法。
(反向代理的架构示意图)
利用 nginx 解决跨域问题
- 开始配置之前,咱们应用活字格开发两个利用,仅蕴含前端页面的 frontend 和蕴含后端 WebAPI(服务端命令)的 backend,并将其别离公布到物理机或云主机上,利用的端口设置为 8081 和 8080。咱们能够通过以下地址拜访这两个利用:
- 后端:http://host\_name:8080/backend
- 前端:http://host\_name\_2:8081/frontend
- 装置 nginx,并在配置文件 /conf/nginx.conf 中 HTTP 节点配置前后端的服务器,即 upstream 节点:
upstream backend {server host\_name:8080;}
upstream frontend {server host\_name\_2:8081;}
- 在 HTTP 节点下的 server 节点,配置监听端口和转发策略,这样就能够将 http://host\_name:8080/backend 映射为 http://proxy\_name:8000/backend,http://host\_name\_2:8081/frontend 映射为 http://proxy\_name:8000/frontend
listen 8000;
server\_name proxy\_name;
location /frontend {proxy\_pass http://frontend/frontend ;}
location /backend {proxy\_pass http://backend/backend ;}
- 上述操作后,用户拜访的域名对立成了 http://proxy\_name:8000,跨域问题解决了。然而,不要焦急。活字格默认会启用 Http Referer 验证机制,不容许跨域调用内置服务。所以,你还须要关上前端利用所在的服务端的治理控制台 http://host\_name\_2:22345/UserService/ManagementPage/WebSecurity
在 HTTP Referrer 容许列表中增加 nginx 代理服务器的地址(也就是用户理论应用的地址,记得在前面加一个 * 号适配)。
- 配置实现后,你能够就能够在前端页面中通过【发送 HTTP 申请命令】,调用后端的 WebAPI 了。
(在前端调用后端 WebAPI 并弹窗显示返回后果)
特地提醒:如果你须要将前端、后端和 nginx 部署在同一台机器上,能够将上述 proxy\_name、host\_name、host\_name\_2 对立替换为你的机器名或 IP 地址。
作为一款弱小的反向代理和 Web 服务器,nginx 的用处十分宽泛,本文仅仅应用到了它的反向代理性能。除此之外对于负载平衡的解决 nginx 也有很优良的体现,在后续内容中咱们会为大家做更加深刻的介绍。
如需具体理解如何应用低代码开发前后端拆散的企业级利用,疾速转型全栈工程师,能够查看:
https://gcdn.grapecity.com.cn/forum.php?mod=viewthread&tid=146511&extra=page%3D1%26filter%3Dtypeid%26typeid%3D272
除此之外如果你对更多低代码行业现状与发展趋势感兴趣能够查看:
https://help.grapecity.com.cn…