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