美团酒店前端在应用Node进行全栈开发的过程中摸索前行的一些心得

前后端分离的背景“前后端分离”显然不是什么新话题。Zakas于2013年10月发表博客《Node.jsandthenewwebfront-end》在Node背景下讨论新时代的前端。毫无疑问，Node的出现给JavaScript语言带来了新的活力，也给前端开发者带来了更多的可能。从表面上看，前后端分离似乎是一项“圈地运动”，但从本质上讲，前后端分离是为了解决以往发展模式的一些批评和痛点，也是迎合大行业趋势的明智举措。我所在的美团酒店业务部于去年7月成立，新的业务和新的开发团队使我们的前后端分离得到了彻底的推广。到目前为止，前端承载的所有业务和在线服务都是基于Node的，生产环境中有近20台服务器。这种新的前后端合作模式可以让专业人士做专业的事情，无论前端和后端都可以比以前更专注于他们擅长的方面。传统的技术栈开发模式和技术栈开发模式只需专注于多终端的呈现(浏览器，WebView）。现在，浏览器只是前端的一部分，延伸了Node端的架构和服务的运维能力。上图显示了我们目前的服务架构：Nginx位于Node服务之前，用于负载平衡、服务调度、Gzip压缩等。然后是Node服务。我们通过PM2.5部署和平衡Node服务的Cluster(充分利用多核优势)，并负责路由作为轻中间层。Controllers、Views、以及视图渲染，通过RESTfulAPI接口采用JSON格式交互获取数据。后端只负责业务逻辑、数据存储、Models，并为前端提供JSON数据。这种变化后，Node端可以优化页面加载，如第一屏渲染。页面渲染后，后续的交互和渲染将由浏览器端的JavaScript代码完成。大多数情况下，Node端的模板与浏览器端的模板相同，因此我们需要考虑模板的重用。我们用Juicer取代了Express框架的默认模板引擎，Juicer是一个高效、轻量级的前端。(Javascript)模板引擎，效率和易用性是其追求的目标。此外，它还可以在Node中运行.在js环境中。Node端和浏览器端的模板和Helper复用问题可以通过Juicer解决。此外，在前后端分离的工程架构下，前端代码仓库与后端隔离，前端独立负责前端静态资源文件、模板文件和controller的维护和发布。在重新定义前端和后端分工后，前端可以做更多的事情，如微信SDK访问，因为使用微信JSSDK需要在服务端签名，所以现在我们不需要后端干预，前端可以独立完成微信SDK访问。此外，我们内部和商家端SSO登录逻辑的访问完全由前端独立完成。对于前端技术选型，我们始终保持理性、拥抱的态度。我们不会为了盲目创新而引入新技术。技术选择是针对我们目前大团队的场景，以解决以往合作过程中发现的一些痛点和不足。例如，引入Node是为了提高前后端的工作流程和效率，提高前后端的开发体验。另一个例子是我们项目中使用的Angularr、为了提高开发效率，提高代码的可维护性，React也针对特定的业务场景。在我们的业务应用中，Angular可以显著提高商家和后台的开发效率，而React目前只在用户的PC端项目中进行一些尝试和实践。这种分工和架构模式带来的挑战不仅给前端带来了更多的可能性和便利，也带来了巨大的挑战。与传统的前端角色相比，我们需要更加关注在线服务、过程内存占用、CPU占用和在线异常监控的状态。在拥抱Node的同时，对前端能力的要求更高。一个看似正常的JS代码，在浏览器端和Node端两个不同的操作环境中，可能会暴露一些以前没有注意到的问题，比如内存泄露:一个封闭的包或一个用于缓存数据的对象，与浏览器不同，Node对内存泄露非常敏感，因为在线应用程序有成千上万甚至数百万的流量，所以即使是一个字节的内存泄露也会导致内存积累。因此，垃圾回收过程耗时增加，应用响应缓慢，知道过程内存溢出，应用重启或崩溃。内存泄漏问题的定位是我们在生产环境中遇到的一个案例：最近，我们发现在线服务的内存占用在服务重启后会呈线性增长。过程启动18小时后，内存占用约1.6G，很快就会超过V8的内存限制，导致服务重启。从图中可以看出，内存使用在修复前随时间定期波动，波动的原因是在线Node过程不断重启。从图中可以看出，内存使用在修复前随时间定期波动。波动的原因是在线Node过程的不断重启。众所周知，在V8垃圾回收机制下，一般代码很少出现内存泄漏，但一旦出现内存泄漏，往往很难调查。但内存泄漏的根本原因只有一个，那就是应该回收的对象没有正常回收，成为老一代的常驻对象。幸运的是，使用一些常见的调查工具可以帮助我们定位内存泄漏的具体原因：-v8-profiler-node-heapdump-node-mtrace-dtrace-node-在这里，我们使用node-heapdump在模拟访问的条件下生成堆内存的snapshot，并通过Chrome的开发者调试工具对生成的snapshot文件进行分析。通过比较服务和AB模拟并发访问一段时间后，heapdump信息可以更容易地定位内存泄漏问题点：因为Juicer默认打开cache，默认缓存编译模板，因此随着访问和并发请求的增长，cache对象将继续增长，不回收，所以关闭cache并重新部署在线恢复正常。因为它在浏览器场景中运行的时间很短，并且在用户的机器上运行，即使内存使用过多或内存泄漏，也只会影响用户的终端。由于浏览器场景运行时间短，在用户机器上运行，即使内存使用过多或内存泄漏，也只会影响用户终端。而且运行时间短，内存会随着过程的退出而释放，内存管理的必要性很小。但同一代码在Node端可能会暴露问题。除了代码仓库的分离和开发合作的分离外，在线服务的运维和监控前后端的分离还涉及到在线服务的独立发布和单独部署。当然，前端如何更好地操作、维护和监控在线服务，我们的SA将更加关注在线服务的整体指标和可用性，前端希望了解在线Node的过程状态和异常情况。PM2是一种优秀而开源的Node进程管理工具。我们在PM2的基础上进行了一些改造，部署了云中的数据收集和实时数据获取服务，形成了PM2.5，我们已经应用于在线Node部署监控平台。它可以在云中处理和可视化在线Node服务流程级的细粒度信息，PM2.5能够监控Nodeserver和过程的指标状态，并且可以在各个终端配置报警和报警（Web、iPhone、AppleWatch）展示。PM2.PM2.5的服务架构简要介绍：PM2.5CLI部署了生产环境中的Node服务，PM2.5CLI将继续向PM2.5云报告Node过程的所有数据。PM2.PM2.5的服务架构简要介绍：PM2.5CLI部署了生产环境中的Node服务，PM2.5CLI将继续向PM2.5云报告Node过程中的所有数据。云收到报告的数据后，将处理原始数据并存储到MongoDB。Web端和iOS应用程序将通过WebSocket服务从服务端获取实时数据流，然后通过前端显示可视化信息。PM2.当Node过程通过PM2.5启动时，PM2的内部实现.5CLI会同云服务握手，握手成功后数据会不断上报。报告时，AES256将首先加密数据，然后使用TCP通信向服务器报告数据。这里使用开源Axon。云服务器收到数据后，将数据存储在MongoDB中，并扫描监控报警。如果当前数据符合用户订阅的监控报警条件，报警信息将通过云Push服务推送到IOS客户端。WebSocket服务同时在云中运行，为多个终端(Web平台、iOS应用)提供实时数据推送。值得一提的是，PM2.5的客户端是基于React-Native开发的。目前已提交Applestore审核。审核通过后，可从Applestore下载。客户端提供服务和流程基本指标查看，可配合Web平台监控报警设置实现7x24小时服务监控。为了确保在线服务的可靠性和稳定性，我们还访问了其他监控设施和日志平台，以便跟踪、分析和定位在线错误和访问日志。ZabbixZabbix是一种分布式系统监控和网络监控功能的企业级开源中间件，主要用于运维。Zabbix主要用于心跳检测和监控服务的指标。当某些指标异常或超过设定阈值时，应报警短信、大象和电子邮件。Sentry错误日志收集Sentry是一个错误的日志服务器，可以集中捕获程序错误的细节。SDK还为业务接入提供各种常见语言。但是Sentry在服务器端会有采样，一般不能取代实时错误日志报警的监控。日志监控平台日志监控平台是美团内部的日志收集系统。目前，美团统一使用flume收集日志。flume有能力接收scribe格式日志，日志监控平台也采用scibe格式日志收集。日志以原始日志和分析日志两种形式存在于整个收集过程中。目前，我们主要使用日志监控平台报告访问日志的格式化数据，然后我们可以通过Hive/Presto查询访问数据。性能监控平台性能监控平台为美团平台和产品线提供简单易用的端到端性能数据服务。SDK还为业务接入提供了各种常见语言。主要用于分析Node端的接口响应，以及浏览器端的页面载入性能。综上所述，以上是美团酒店前端在应用Node开发全栈的过程中探索前进的一些经验，也是介绍。主要介绍了我们酒店业务部门的前后端分离架构、在线内存泄漏的调查以及使用的Node服务监控平台PM2.5。以后我会分享更多关于我们Node的实践，以及PM2.5监控平台背后的实现，希望对大家有所帮助。也欢迎您参与前后端分离和Node相关技术点的共同交流。

以上就是关于美团酒店前端在应用Node进行全栈开发的过程中摸索前行的一些心得的相关介绍，更多美团酒店前端在应用Node进行全栈开发的过程中摸索前行的一些心得相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对美团酒店前端在应用Node进行全栈开发的过程中摸索前行的一些心得有更深的了解和认识。