前后端分离方案去哪儿网内部的最主要的方式

去哪儿网主要有三种前后端的分离方案。第三,前后端职责也更为清晰,因为这时候,界限更为清晰了,后端只负责生产数据,它只提供数据就可以了,至于数据怎么消费,以及怎么用,都由前端去做;如何保证系统的安全性、稳定性和扩展性,怎么保证和我们内部系统做很无缝的去对接,这就要求有很好的扩展性;相信在阿⾥内部对这块已经做了不少优化,所以简单使用的是公司级别的机器监控。

前端分离方案

去哪儿网主要有前后端分离的三种解决方案。

前后端分离方案去哪儿网内部的最主要的方式

第一种方法是项目分离和页面分离。它的特点是简单快捷。前端只需要关注浏览器。在浏览器之外,由后端负责,但是通信成本会非常高,因为在前期,前端需要使用NG,或者使用代理工具进行调试。后面会有一些页面发送到后端,需要新建一个后端对应的路由。这使得来回调试变得非常复杂。当部门跨楼层合并时,这些成本会相应增加。

前后端分离方案去哪儿网内部的最主要的方式

第二种解决方案仍然是项目分离。后端页面放在前端项目中,后端只需要配置路由即可。最终上线时,发布系统负责自动将前端页面同步到后端对应目录。文件里面。当然前期需要前端和后端约定同步路径,否则在后端渲染页面时找不到对应的文件。与第一种方案相比,改进了一点点,通信成本降低了一点点。

前后端分离方案去哪儿网内部的最主要的方式

第三种方案是使用Node.js作为页面渲染层,后端只负责数据生产。这也是去哪儿最重要的方法。它的优点是前端同学可以完全掌控整个页面的生命周期,包括开发调试、部署、上线、监控等,可以做的事情也很多。比如我们不能做SSR,而是使用Node.js。做这件事很容易。

静态资源离线打包解决方案(qp)

在三个方案的演进过程中,为了让用户快速看到页面,我们还设计了静态资源包方案。这是它的整体流程图:

前后端分离方案去哪儿网内部的最主要的方式

第一部分是前端同学的职责,就是制作一些配置文件;

第二部分是包装平台。我们需要读取我们的配置文件,然后将它们打包。在打包的过程中,我们还需要进行数据加密操作,比如使用私钥让qp包生成一个MD5文件并发送给qp服务器。, 最后到客户端,客户端使用私钥再次请求QD的MD5,比较QP服务器返回的MD5的质量。如果通过了,就是我们需要的包,而不是被恶意篡改的包。.

在做客户端的时候,客户端同学需要做很多事情,为什么呢?因为这里涉及到一个网络环境问题,如果用户的环境是WiFi,我们会自动拉取所有离线包,如果是非WiFi网络环境,比如4G、2G等,我们不会自动拉取离线包包。因为为了减少用户的流量,当用户进入我们特定的页面时,会检查我们本地是否有这样的离线包,如果有,我们就使用我们的离线包资源,如果没有,直接上环境,它会在我们后台静默下载,这也是我们客户端需要做的。

那么如何使用项目呢?很简单,只需要在项目根目录下创建一个.yaml配置文件,里面包含几个主要内容:

第二步就是相应的开发,或者QA进入打包平台发布,也很简单,只要添加一些配置项,不需要人工干预。

用户完全透明,不知道离线包。从整个流程来看,你可能会认为一些相关的功能简单并不复杂,但其实要考虑的东西很多:

三是离线强制更新。离线是指当一个qp包出现问题时,我们需要对这个qp包进行离线操作,这样用户就无法访问了。这是当前的离线包。强制更新呢?意思是当某个QP包需要用户或某批用户下载时,我需要做一个强制更新操作,那么它的主要目标就是要下载的包。这两个概念是不同的。

此外,它是为了提高更新率。主要有3种方法:一是减小qp包的大小,即体积;第二,使用协议;第三,尽量使用差分包而不是全包,因为全包非常大,只要不涉及重大更新,不需要发送全包,尽量使用差分包机制.

最后,关于更新率的影响:

前后端分离方案去哪儿网内部的最主要的方式

前后端分离方案去哪儿网内部的最主要的方式

强制更新和普通更新两种机制的实现方式不同,所以其更新效果也不同。强制更新的效果最为明显。它可以在两个小时内达到90%的水平。正常更新有七个。需要八个小时才能稳定到大约 75%。

Node.js 实践

为什么 Node 没有大规模使用?我总结了大概的原因:

Node.js 可以解决哪些问题和痛点?

首先提高开发效率,因为有了Node之后就不用配置了,也不需要配置一些代理工具。所有页面生命周期都由前端统一管理,此时不需要其他人配合。

二、降低通信成本,除接口格式外,无需与后端交互;

第三,前端和后端的职责也更清晰了,因为这个时候,界限更清晰了。后端只负责生产数据。它只提供数据。至于数据怎么消费,怎么用,前端会去做。;

第四,可以同时使用SSR技术,实现首屏渲染,提升用户体验。除了首屏,还可以进行异步加载、SEO等操作。

最后,Node.js 可以提供一些服务,不仅可以供我们使用,还可以提供给外部使用,例如 API,这样我们就不需要依赖后端。

去哪儿采用了基于三年前的解决方案,包括日志收集、监控、模板和异常。

在实际的开发和使用过程中,或多或少存在一些问题,主要体现在以下几个方面:

1. 如何确定项目目录的划分规范和命名规范(view or );

2. 确定规范后,如何保证大家都同意并严格遵守;

3. 如何保证系统的安全性、稳定性和可扩展性,如何保证与我们内部系统的无缝连接,这就需要良好的可扩展性;

4. 守护进程的选择(pm2 或 );

5. 如何保证多环境运行规则(/beta/prod),因为在我们的实际项目中,可能有我们的或Bata或PID的不同规则。如果此时不做这件事,可能会对我们的实际应用造成一定的障碍;

6. 如何利用系统的cpu多核,多进程间通信。

针对这些问题,去哪儿也做了一些改进,开始研究,最终在文档、框架扩展、插件数量、部署流畅度、开发体验等方面选择了Egg.js。

插件开发

同时为了连接我们内部系统,我们也开发了一些不同功能的插件,比如egg-,可以关联我们的前后端版本号,因为它不不管你是Java和Java合作的原始模型,还是现在的Node.js。js,都需要版本号的关联。

既然我们用它来打包,而且打包的是一个MD5字符串,那么如何保证这些字符串是连通的呢?我们做了一个鸡蛋插件;

第二个是egg-,这是内部q系统;

第三个是鸡蛋——它连接到我们的系统。

没有Q的插件是外挂的,比如egg-。对于Java,egg-不需要大家关心,因为他们在NG上做处理,或者在Java自己做处理,但是Node不做处理,需要我们自己做。

还有egg-,是心跳检测的功能,是检测我们的应用程序,或者检测我们的服务器是离线还是在线的过程;

egg- 是检查我们的应用程序是否存活;

最后一个是连接egg-的系统,也就是存储系统,后四个是公共的。

去哪儿网原始部署流程(方法)问题

1. 发布系统中不能使用对应的端口和目录字段,只能硬编码在服务中,不友好

2. 无法区分beta环境和prod环境等多环境策略配置规则不一样

3. 启动过程中出现错误,不方便定位问题,需要在机器上检查

4. 编写系统服务需要了解命令和系统服务格式。对于前端开发的同学来说,成本略高

5. 除了端口、项目路径、运行环境、node.js启动方式外,处理逻辑类似

改进部署

这是 .sh 的一个例子:

前后端分离方案去哪儿网内部的最主要的方式

其次,我们可以安装一些依赖项。

三、启动Node.js,因为我们使用的是egg.js,所以启动逻辑是基于Node.js的启动方式。

SSR实践:

这是一般结构:

前后端分离方案去哪儿网内部的最主要的方式

这是 SSR 实现的结构。

前后端分离方案去哪儿网内部的最主要的方式

即使不使用SSR,我们的项目仍然可以运行。基于这两点,我们使用一些操作。红圈是指我们前端的一段JS代码,然后最后我们做一些异步和同步加载的过程。

前后端分离方案去哪儿网内部的最主要的方式

它是这样写的。

前后端分离方案去哪儿网内部的最主要的方式

SSR遇到的问题共享代码如何处理请求?

前后端分离方案去哪儿网内部的最主要的方式

共享代码如何处理错误

前后端分离方案去哪儿网内部的最主要的方式

获取设备信息的后端代码

前后端分离方案去哪儿网内部的最主要的方式

性能监控

在业绩方面,我们没有做太多,因为我们已经经历了淘宝双十一的洗礼。相信阿富汗这个地区已经做了很多优化,所以我们干脆用公司级的机器监控。

前后端分离方案去哪儿网内部的最主要的方式

在应用方面,我们做了很多。应用分为两个方面,一是应用级错误,二是前端页面级错误。

应用级错误是记录应用用户数,使用后端接口的时间消耗,以及对应的接口异常。

前端页面级错误,如脚本错误、静态资源文件夹错误、异步错误等。

针对这两个错误,我们有两个系统,一个是日志系统,一个是系统,这两个系统协同工作。

前后端分离方案去哪儿网内部的最主要的方式

前后端分离方案去哪儿网内部的最主要的方式

免责声明:本文来自网络用户投稿,不代表本站观点和立场。如有侵权请发送邮件至tzanseo@163.com告知本站删除,本站不负任何责任及承诺。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。

发表评论

登录后才能评论