nodejs应该学习哪些框架？（一个SAAS系统服务平台前后端？）

nodejs应该学习哪些框架？

分享nodejs几个好用的框架

独山ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18980820575（备注：SSL证书合作）期待与您的合作！

第一名： express 50.4k （2010年1月发布）目前star 和下载量最高的老牌框架。Express 是一款基于Node.js以及Chrome V8引擎，快速、极简的JS服务端开发框架，它提供了用来开发强壮的 Web/移动应用，以及 API 的所有功能。并且开发人员还能够方便地为它开发插件和扩展，从而增加 Express 的能力。

第二名：meteor 42k （2012年发布）Meteor是一个基于nodejs和mongodb数据库的实时web框架。你可以用js搞定客户端、服务端的开发。另外，客户端、服务端的界限被极大的模糊。客户端的界面跟服务端的数据是双向绑定的，修改服务端的数据，用户界面会随着更新；你也可以在客户端直接修改服务端的数据库。

meteor/meteorgithub.com

第三名： nest.js 30.8k （2017年11月发布）作为目前上榜框架中发布最晚，也是star 最高且增长最快的 typescript 后端框架。Nest 是一个用于构建高效，可扩展的 Node.js 服务器端应用程序的框架。它使用渐进式 JavaScript，内置并完全支持 TypeScript（但仍然允许开发人员使用纯 JavaScript 编写代码）并结合了 OOP（面向对象编程），FP（函数式编程）和 FRP（函数式响应编程）的元素。

Nest 框架底层 HTTP 平台默认是基于 Express 实现的，所以无需担心第三方库的缺失。 Nest 旨在成为一个与平台无关的框架。 通过平台，可以创建可重用的逻辑部件，开发人员可以利用这些部件来跨越多种不同类型的应用程序。 从技术上讲，Nest 可以在创建适配器后使用任何 Node HTTP 框架。 Nest 提供了一个开箱即用的应用程序架构，允许开发人员和团队创建高度可测试，可扩展，松散耦合且易于维护的应用程序。

中文文档docs.nestjs.cn

第四名： koa 30k （2013年11月发布）Koa框架由Express原班人马打造，它的核心是 ES6 的 Generator。Koa 使用 Generator 来实现中间件的流程控制，使用try/catch 来增强异常处理，同时在 Koa 框架中你再也看不到复杂的 callback 回调了。Koa框架本身非常小，只打包了一些必要的功能，但是它本身通过良好的模块化组织，让开发人员可以按照自己的想法来实现一个扩展性非常好的应用。

第五名： sails 21.6k （2012年7月）Sails 作为一个非常稳固的 Node.js 框架，提供了建立任何规模的 Web 应用所需要的所有功能。

Sails.js 在底层使用了 Express框架来提供对 HTTP 请求的处理，同时使用 框架来处理WebSocket 请求。同时作为一个前端应用开发框架，它允许开发人员选择他/她熟悉的技术来开发应用。

同时 Sails.js 也通过 waterline 框架实现了 ORM 功能。通过这个功能，你的应用程序可以在不进行大的修改的前提下，就可以从一个后端数据库，切换到另外一个后端数据库（也可以是一个NoSQL数据库）。

Sails 特别适合用来开发对数据的实时更新有较高要求的应用，比如多人棋类游戏，单页Web应用等等。如果你对 Ruby， Django 或者 Zend 有一定的了解，那么你将非常容易理解Sail中的概念。

第六名：Egg 16.2k （2016年7月）Egg是基于Koa，由阿里Node.js团队封装的企业级Web应用解决方案，以约束和规范化团队开发，帮助开发团队和开发人员降低开发和维护成本为核心设计理念的优秀解决方案。Egg已经被用在阿里多条产品线（包括蚂蚁）上，已经证明它的安全和可靠性，可以放心用。

第七名： fastify 16k （2016年10月）目前性能最好的 node.js 框架。Fastify是一个高度专注于以最少开销和强大的插件架构，使用简单，扩展灵活，包含了基于扩展的开发， 同时官方为了方便开发plugin，提取了通用部分，方便模块化，同时我们可以在路由中添加schema 方便的进行数据的校验（基于json schema），生态也很不错，已经提供了很多扩展插件。

第八名： loopback 13.2k （2013年6月）LoopBack开发框架是一套Node.js模块集，可以用独立使用或整合使用来快速开发REST API接口程序。背后是IBM的子公司在支持。

LoopBack应用可以通过模型API来跟数据交互，本地通讯在Node.js内部完成，远程通讯使用REST客户端API，如与原生客户端iOS、Anroid和Html5等进行通讯。

第九名： hapi 12.8k （2012年8月）HapiJS是一个开源的、基于Node.js的应用框架，它适用于构建应用程序和服务，其设计目标是让开发者把精力集中于开发可重用的应用程序的业务逻辑，向开发者提供构建应用程序业务逻辑所需的基础设施。

第十名： polemo 11k （2012年12月）网易开源的游戏后端框架。pomelo是一个游戏服务器框架，与以往单进程的游戏框架不同， 它是高性能、高可伸缩、分布式多进程的游戏服务器框架，并且使用很简单。它包括基础开发框架和一系列相关工具和库，可以帮助开发者省去游戏开发中枯燥的重复劳动和底层逻辑工作，免除开发者的重造轮子，让开发者可以更多地去关注游戏的具体逻辑，大大提高开发效率。Pomelo支持所有主流平台的客户端，并提供了客户端的开发库。

觉得有帮助就一键三连哦~

一个SAAS系统服务平台前后端？

该问题非常好，因为它代表了纯粹开发技术类科技，但同时也从技术向运营服务的延伸。

任何SaaS系统的最终目的都是为入驻到SaaS系统的客户服务，为客户提供价值的，而任何开发架构都是为了让SaaS能更好的实现、提供更好的服务的。

从系统开发需要达到的目的，我们追踪溯源，列出SaaS平台需要实现的目标：

实现入驻客户的功能需求满足SaaS系统本身的运营需求实现SaaS可扩展性

明白需要实现的目标后，我们再将相关技术框架做个归纳列表：

限于篇幅，每个技术框架介绍请读者自行查阅网上资料。此处只介绍选择最佳框架的思路。

1、根据SaaS系统入驻客户规模和可能的数据量大小，来选择技术开发架构

SaaS开发系统技术开发架构，首先需要考虑系统的可扩展性，作为SaaS系统，本身具有行业特性，不仅仅是为某一单独客户的自定义，而是需要考虑一类主要需求都相同的客户，实现大家的共性需求，如：CRM的SaaS平台，财务管理的SaaS平台，销售管理的SaaS平台等，在此基础之上，如果有特别特殊的客户，在根据客户的个性化需求，提供企业自定义功能。

同时SaaS系统需要根据技术发展、行业需求演化等因素，能通过最小的代价实现版本升级迭代，大家都知道，只要在技术架构不变更的情况下，其他技术功能的升级迭代成本相对都是比较小的。如何选择一个合适的技术开发架构，以满足将来一段时间内的用户需求，就是SaaS系统设计时需要考虑的问题。可从以下几个方面来选择：

（1）先明确后台采用

.Net

技术还是Java技术；

（2）确定表现形式后，选择前端框架。Web前端是必须得，如果SaaS系统需要移动端，则前端还需要选择移动端开发框架；

（3）后端框架目前主流采用Java框架居多，有助于将来框架升级和自定义维护；

（4）前端框架如果涉及移动端，建议采用原生 + 混合的，对一些需要动态Web页面，采用H5相应的框架；

2、根据入驻客户功能需求，选择对应的框架

入驻SaaS系统客户，都属于同类功能需求的用户，但根据客户规模不同，对SaaS设计和框架选择不同：

（1）如果用户量大，对性能要求高，建议后端增加Redis框架，做好内存管理；

（2）如果SaaS系统在提供服务前一年时间，系统需要修改或增加的地方会相对多一些，此时建议后端加上Log4j，有效管理输出日志，根据日志快速定位和分析功能点情况；

（3）如果客户离散化程度较高，行业非标准，建议在Spring的基础上，采用目前主流的Spring Boot微服务技术框架；

（4）如果采用Java开发，选择Maven框架作为项目管理、自动部署的技术框架，可大大提高开发便捷性；

3、技术框架的选择，要尽量满足SaaS系统运营服务要求

SaaS系统的核心是后一个S（即：Service），在满足系统功能开发的基础上，需要一整套和前端功能相匹配的SaaS系统运营服务系统，该系统对任何SaaS运营来讲都是不同的，不同的行业需要针对提供不同的服务，但有以下几点需要在选择技术架构时考虑：（1）需要有开放接口功能，便于对接第三方系统，如：呼叫中心、服务器监控平台等；

（2）对于运营系统，客户服务及时性和有效性比较重要，需要在消息机制上进行优化，建议后台加入RabbitMQ框架，对用户的咨询、投诉和其他服务做好消息队列处理；

（3）SaaS后台服务由于属地关系，可能会设立各地方的服务团队，因此，系统会涉及到分布式部署的问题，此时Dubbo分布式服务框架就可以很好的解决将来SaaS系统大规模分布式的情况。

以上三个方面权衡后，还需要考虑是否需要中台，根据笔者经历，普通规模（如：入驻用户量在10万以下）的SaaS系统，使用中台的价值并不大，但大规模系统，是有必要开发自己的中台的，关于中台的开发和选择，技术开发商和前后端开发是相似的，此处不再深入。

服务器三大框架？

从系统架构来看，目前的商用服务器大体可以分为三类，即对称多处理器结构(SMP：Symmetric Multi-Processor)，非一致存储访问结构(NUMA：Non-Uniform Memory Access)，以及海量并行处理结构(MPP：Massive Parallel Processing)。

一、SMP(Symmetric Multi-Processor)

所谓对称多处理器结构，是指服务器中多个CPU对称工作，无主次或从属关系。各CPU共享相同的物理内存，每个 CPU访问内存中的任何地址所需时间是相同的，因此SMP也被称为一致存储器访问结构(UMA：Uniform Memory Access)。对SMP服务器进行扩展的、使用更快的CPU、增加CPU、扩充I/O(槽口数与总线数)以及添加更多的外部设备(通常是磁盘存储)。

SMP服务器的主要特征是共享，系统中所有资源(CPU、内存、I/O等)都是共享的。也正是由于这种特征，导致了SMP服务器的主要问题，那就是它的扩展能力非常有限。对于SMP服务器而言，每一个共享的环节都可能造成SMP服务器扩展时的瓶颈，而最受限制的则是内存。由于每个CPU必须通过相同的内存总线访问相同的内存资源，因此随着CPU数量的增加，内存访问将迅速增加，最终会造成CPU资源的浪费，使 CPU性能的有效性大大降低。实验证明，SMP服务器CPU利用率最好的情况是2至4个CPU。

二、NUMA(Non-Uniform Memory Access)

由于SMP在扩展能力上的限制，人们开始探究如何进行有效地扩展从而构建大型系统的技术，NUMA就是这种努力下的结果之一。利用NUMA技术，可以把几十个CPU(甚至上百个CPU)组合在一个服务器内。

NUMA服务器的基本特征是具有多个CPU模块，每个CPU模块由多个CPU(如4个)组成，并且具有独立的本地内存、I/O槽口等。由于其节点之间可以通过互联模块(如称为Crossbar Switch)进行连接和信息交互，因此每个CPU可以访问整个系统的内存(这是NUMA系统与MPP系统的重要差别)。显然，访问本地内存的速度将远远高于访问远地内存(系统内其它节点的内存)的速度，这也是非一致存储访问NUMA的由来。由于这个特点，为了更好地发挥系统性能，开发应用程序时需要尽量减少不同CPU模块之间的信息交互。利用NUMA技术，可以较好地解决原来SMP系统的扩展问题，在一个物理服务器内可以支持上百个CPU。比较典型的NUMA服务器的例子包括HP的Superdome、SUN15K、IBMp690等。

但NUMA技术同样有一定缺陷，由于访问远地内存的延时远远超过本地内存，因此当CPU数量增加时，系统性能无法线性增加。如HP公司发布Superdome服务器时，曾公布了它与HP其它UNIX服务器的相对性能值，结果发现，64路CPU的Superdome (NUMA结构)的相对性能值是20，而8路N4000(共享的SMP结构)的相对性能值是6.3。从这个结果可以看到，8倍数量的CPU换来的只是3倍性能的提升。

三、MPP(Massive Parallel Processing)

和NUMA不同，MPP提供了另外一种进行系统扩展的，它由多个SMP服务器通过一定的节点互联网络进行连接，协同工作，完成相同的任务，从用户的角度来看是一个服务器系统。其基本特征是由多个SMP服务器(每个SMP服务器称节点)通过节点互联网络连接而成，每个节点只访问自己的本地资源(内存、存储等)，是一种完全无共享(Share Nothing)结构，因而扩展能力最好，理论上其扩展无限制，目前的技术可实现512个节点互联，数千个CPU。目前业界对节点互联网络暂无标准，如 NCR的Bynet，IBM的SPSwitch，它们都采用了不同的内部实现机制。但节点互联网仅供MPP服务器内部使用，对用户而言是透明的。

在MPP系统中，每个SMP节点也可以运行自己的操作系统、数据库等。但和NUMA不同的是，它不存在异地内存访问的问题。换言之，每个节点内的CPU不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的，这个过程一般称为数据重分配(Data Redistribution)。

但是MPP服务器需要一种复杂的机制来调度和平衡各个节点的负载和并行处理过程。目前一些基于MPP技术的服务器往往通过系统级软件(如数据库)来屏蔽这种复杂性。举例来说，NCR的Teradata就是基于MPP技术的一个关系数据库软件，基于此数据库来开发应用时，不管后台服务器由多少个节点组成，开发人员所面对的都是同一个数据库系统，而不需要考虑如何调度其中某几个节点的负载。

需要掌握哪些技能？

我见过的架构师有两种，一种是码农一步步成长蜕变成的架构师，一种是PPT架构师。

我希望大家都能成为前者。

我现在差不多能算半个架构师，为啥是半个，因为本身是要带项目的，但是也会负责产品线内其他项目的架构设计和评审工作，姑且算是半个吧。我分享一下我的看法，如果有不对的地方欢迎大家留言指正。

技术

单位中，不管是我这种半个架构，还是转职的架构，都是技术出身的，甚至现在也会写一些代码，所以技术能力是必不可少的。

深入了解一门语言，对其他的一些编程语言也了解过一些。

编码能力一定要过关，有些时候甚至会要求架构师亲自上阵写代码的。

深入的学习过一些主流的框架，有些甚至需要研究到源码的级别。架构嘛，技术一定得是要过关的。成长的道路上，谁还没研究过一些源码。

熟悉大多数流行的框架、中间件，达不到深入研究源码的程度，但是至少使用过、优缺点是什么、使用场景是什么。这样在架构设计的过程中，可以根据实际的需要，选择合适的技术。

业务

在一个业务领域，有着一定的业务知识储备。比如一个银行业务的机构师，去一个电商网站做架构设计，肯定玩不转哟。

需求分析能力：所有的机构设计，都是在了解用户的业务流程之后，才开始做的。要充分的理解用户到底想要什么功能，再去设计怎么实现这些功能。甚至有些时候用户自己都不知道要什么，需要架构帮他们去思考、去设计。

业务抽象能力：业务功能最后要是要用代码来实现，架构师需要对系统中的各种子系统、模块，以及它们之间的关系、如何交互等行为，进行抽象；用知识和经验来解决实际的业务问题。

其他

沟通能力：和用户、需求沟通，和领导沟通，和项目经理沟通，和开发人员沟通。

文档和画图能力：沟通明白了，还是要落实在文档上，特别是画图的能力，很重要，赶紧下一个Visio好好练练。

提出问题、提出质疑的能力：我就属于听到用户的需求，容易说“行行行，好好好，可以实现”。其实用户提的需求不一定合理，可能花费大量的时间去实现，最后却不是他们真正想要的东西，要多质疑他们，给他们提更好的解决方案。

学习能力：保持一定的技术敏感度，需要不断的学习新的技术。比如十年前项目缓存都用的是ehcache，现在都用memcached、redis，说不定再过几年又有更好的解决方案了。

希望我的回答能够帮助到你！

新闻名称：nodejs应该学习哪些框架？（一个SAAS系统服务平台前后端？）
链接地址：http://www.csdahua.cn/qtweb/news29/552679.html

网站建设、网络推广公司-快上网，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 快上网