2g2核服务器的最佳负载范围：并发用户与服务器性能的权衡 (2g2核服务器)

如何正确理解软件系统架构的前后端分离？

首先：软件系统架构的前后端分离更多是在近几年伴随互联网的盛行为提高前端与后端交互的响应速率，提升用户的体验进行衍生出了前后端分离架构。

如：Vue、NodeJS与微服务架构结合。

前端页面进行UI展示效果渲染，后端负责编写API服务进行数据提供，也可以引入NodeJS来作为桥梁架接后端API输出的JSON，返回前端进行页面展现。

其次：基于前后端分离架构一方面提升响应速度，将数据计算的过程在中间层处理，前端进行展示；避免传统的大量数据请求服务器的压力基于中间层在内部处理拼接完成，性能得到了提升；以多组件、片段、卡片的模式实现并行的加载、显示，在非WiFI的3G、2G的弱网络环境下优势更为明显，模板并行加载，优先加载优先显示，提升用户的交互体验。

最后：从经典的MVC架构到SSM、SSH的Java框架时代，再到前端框架如：AngularJS、Vue等，虽然技术、架构一直在演变进步本质上均是为了更方便的解决需求，前后端分离架构更多的也是实现解耦的过程，不将前端与后端绑定，这也与SOA的理念是相吻合的，基于企业服务总线实现应用系统对接的松耦合，以插拔的模式将应用、单据、数据进行有效的连通与对接，以组件构建、平台搭建、架构支撑的模式共同铸建企业的信息化建设，以更专业的平台实现其专业领域的工作，助力企业信息化的发展。

nodejs-koa2（mvc模式）前后端分离前端设计

前后端分离，前端nodejs运行环境，使用koa2集成负责资源分配与用户交互，实现token验证用户身份，路由控制。等！

自行网络解决；

program:${workspaceFolder}\

此处就是是将作为启动文件。

${workspaceFolder}代表根目录，vsc启动时会在根目录下找到并加载文件。

参数介绍：name项目名称、version版本号、description项目描述、main项目启动文件、scripts启动快捷设置，author作者，dependencies第3方中间件名称及版本。

最重要的

“dependencies”这里添加一些要用到的包，以上是这次要用到的所有的包，版本自己更改。

“scripts”这里是一些nodejs的便捷命令，上线的时候会用到，直接在终端中，同级目录，执行‘npmstart’即可启动。

别的没啥太大作用瞎写即可。

启动相关配置，封装到config/中，启动文件直接引用即可

3-6-1、项目核心。

异常友好处理方法封装

路由配置

视图渲染

核心集成

3-6-2、项目参数配置。为什么不用json文件因为json不能加注释

3-6-3、项目token相关方法封装。

执行后项目结构会增加两个文件

新增

浏览器访问：

输入值获取token

获取的token如图：

先不用带token进行访问:hello/jiaobaba,被token拦截，返回401

带上token访问：hello/jiaobaba

测试页面渲染，及跳转html页面，直接访问/views

结束！！！！！！

需要源码联系我

前后端分离方案以及技术选型

作者：关开发

一.什么是前后端分离？

理解前后端分离大概可以从3个方面理解：

1.交互形式

2.代码组织形式

3.开发模式与流程

1.1交互形式

前后端不分离

后端将数据和页面组装、渲染好了之后，向浏览器输出最终的html；浏览器接收到后会解析html，解析引入的css、执行js脚本，完成最终的页面展示。

前后端分离

后端只需要和前端约定好接收以及返回的数据格式（一般用JSON格式），向前端提供API接口。

前端就可以通过HTTP请求调用API的方式进行交互。

前端获取到数据后，进行页面组装、渲染，最终在浏览器呈现。

1.2代码组织形式

前后端不分离

在web应用早期的时候，前端页面以及后台业务数据处理的代码都放在一个工程下，甚至放在同一目录下，前端页面夹杂着后端代码。

前、后端开发工程师都需要把整套代码导入开发工具才能开发。

此阶段下前后端代码以及工作耦合度太高，前端不能独立开发和测试，后端人员也要依赖前端完成页面后才能完成开发。

最糟糕的情况是前端工程师需要会后端模板技术（jsp），后端工程师还要会点前端技术，需要口头说明页面数据接口，才能配合完成开发。

否则前端只能当一个“切图仔”，只输出HTML、CSS、以及很少量与业务逻辑无关的js；然后由后端转化为后端jsp，并且还要写业务的js代码。

前后端分离

前后端代码放在不同的工程下，前端代码可以独立开发，通过mock/easy-mock技术模拟后端API服务可以独立运行、测试；后端代码也可以独立开发，运行、测试，通过swagger技术能自动生成API文档供前端阅读，还可以进行自动化接口测试，保证API的可用性，降低集成风险。

1.3开发模式与流程

前后端不分离

在项目开发阶段，前端根据原型和UI设计稿，编写HTML、CSS以及少量与业务无关的js（纯效果那些），完成后交给后台人员，后台人员将HTML转为jsp，并通过JSP的模板语法进行数据绑定以及一些逻辑操作。

后台完成后，将全部代码打包，包含前端代码、后端代码打成一个war，然后部署到同一台服务器运行。

顶多做一下动静分离，也就是把图片、css、js分开部署到nginx。

具体开发流程如下：图略

前后端分离

实现前后端分离之后，前端根据原型和UI设计稿编写HTML、CSS以及少量与业务无关的js（纯效果那些），后端也同时根据原型进行API设计，并与前端协定API数据规范。

等到后台API完成，或仅仅是API数据规范设定完成之后。

前端即可通过HTTP调用API，或通过mock数据完成数据组装以及业务逻辑编写。

前后端可以并行，或者前端先行于后端开发了。

具体开发流程如下：图略

二、前后端分离的好处与坏处。

从上面3个方面对比了之后，前后端分离架构和传统的web架构相比，有很大的变化，看起来好处多多。

到底是分还是不分，我们还是要理性分析是否值得才去做。

从目前应用软件开发的发展趋势来看，主要有两方面需要注意：

·越来越注重用户体验，随着互联网的发展，开始多终端化。

·大型应用架构模式正在向云化、微服务化发展。

我们主要通过前后端分离架构，为我们带来以下四个方面的提升：

·为优质产品打造精益团队

通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。

·提升开发效率

前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。

与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。

如此一来整个应用的开发效率必然会有质的提升。

·完美应对复杂多变的前端需求

如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。

·增强代码可维护性

前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。

应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。

那么前后端分离有什么不好的地方吗？我目前是没有想到，除非你说会增加前端团队的配备，后端工程师会变的不全能。

。

。

二、前后端分离架构方案。

实现前后端分离，主要是前端的技术架构变化较大，后端主要变为restfull风格API，然后加上Swagger技术自动生成在线接口文档就差不多了。

对于目前用于前后端分离方案的前端技术架构主要有两种：

·传统SPA

·服务端渲染SSR

2.1传统SPA

传统SPA指的是单页面应用，也就是整个网站只有一个页面，所有功能都通过这一个页面来呈现。

因为一个人的肉眼，某一个时间点看一个页面，既然如此何必要不同功能做多个页面呢？只保留一个页面作为模板，然后通过路由跳转来更新这个模板页面的内容不就可以了吗？确实如此，现在通过reac全家桶、tvue全家桶，模块化、路由、wabpack等技术轻而易举就能实现一个单页面应用。

单页面应用的运行流程

1.用户通过浏览器访问网站url

2.单页面的html文件（）被下载到浏览器，接着下载html里面引用的css，js。

，js下载到浏览器完成之后，浏览器开始解析执行js向后端服务异步请求数据。

4.请求数据完成后，进行数据绑定、渲染，最终在用户浏览器呈现完整的页面。

2.2服务端渲染

服务端渲染的方案指的是数据绑定，渲染等工作都放在服务端完成，服务端向浏览器输出最终的html。

大家看完这个是不是有个疑问，这不是又回到了前后端不分离的时代了吗？答案是否定的，因为这里的服务端是用来执行前端数据绑定、渲染的，也就是把浏览器的一部分工作分担到了服务端。

而目前具备这只种能力的服务端是NodeJs服务端。

它的原理其实就是在浏览器与前端代码中间插入了一个NodeJs服务端。

浏览器请求前端页面时，会先经过NodeJS服务端，由NodeJs去读取前端页面，并执行异步后端API，获取到数据后进行页面数据绑定，渲染等工作，完成一个最终的html然后返回浏览器，最后浏览器进行展示。

服务端渲染应用的运行流程：

1.用户通过浏览器访问网站url

服务端接收到请求，读取到对应的前端html，css，js。

解析执行js向后端API异步请求数据。

请求数据完成之后，进行数据绑定、渲染，得到一个最终的html。

向浏览器输出html，浏览器进行展示。

PS：其实本质就是把前端编写成一个nodeJs的服务端web应用。

实施服务端渲染后，我们最终运行的是一个Nodejs服务端应用。

而单页面应用是把静态页面部署到静态资源服务器进行运行。

看到这里，你是否又有疑问，为什么要这么麻烦搞服务端渲染呢？

2.3SPA与服务端渲染方案对比

SPA的优点是开发简单，部署简单；缺点是首次加载较慢，需要较好的网络，不友好的SEO。

so，以下就是使用服务端渲染的理由了（摘取vue官方说法）：

与传统SPA(单页应用程序(Single-PageApplication))相比，服务器端渲染(SSR)的优势主要在于：

·更好的SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。

请注意，截至目前，Google和Bing可以很好对同步JavaScript应用程序进行索引。

在这里，同步是关键。

如果你的应用程序初始展示loading菊花图，然后通过Ajax获取内容，抓取工具并不会等待异步完成后再行抓取页面内容。

也就是说，如果SEO对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。

·更快的内容到达时间(time-to-content)，特别是对于缓慢的网络情况或运行缓慢的设备。

无需等待所有的JavaScript都完成下载并执行，才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面。

通常可以产生更好的用户体验，并且对于那些「内容到达时间(time-to-content)与转化率直接相关」的应用程序而言，服务器端渲染(SSR)至关重要。

使用服务器端渲染(SSR)时还需要有一些权衡之处：

·开发条件所限。

浏览器特定的代码，只能在某些生命周期钩子函数(lifecyclehook)中使用；一些外部扩展库(externallibrary)可能需要特殊处理，才能在服务器渲染应用程序中运行。

·涉及构建设置和部署的更多要求。

与可以部署在任何静态文件服务器上的完全静态单页面应用程序(SPA)不同，服务器渲染应用程序，需要处于运行环境。

·更多的服务器端负载。

在中渲染完整的应用程序，显然会比仅仅提供静态文件的server更加大量占用CPU资源(CPU-intensive-CPU密集)，因此如果你预料在高流量环境(hightraffic)下使用，请准备相应的服务器负载，并明智地采用缓存策略。

以vue为例，实施服务端渲染可以查看官方指南：，或选择

2.4预渲染技术

如果你调研服务器端渲染(SSR)只是用来改善少数营销页面（例如/,/about,/contact等）的SEO，那么你可能需要预渲染。

无需使用web服务器实时动态编译HTML，而是使用预渲染方式，在构建时(buildtime)简单地生成针对特定路由的静态HTML文件。

优点是设置预渲染更简单，并可以将你的前端作为一个完全静态的站点。

如果你使用webpack，你可以使用prerender-spa-plugin轻松地添加预渲染。

它已经被Vue应用程序广泛测试-事实上，作者是Vue核心团队的成员。

prerender-spa-plugin:

三、前后端分离技术选型

-artTemplate+bootstrap（不推荐，不算完全前后端分离）

-vue全家桶（推荐）

-react全家桶（推荐，生态全）