整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

没有最好,只有合适-选择服务器框架也是如此

网站构建一个稳定、高效的后台服务器程序是一件非常重要的事情。要达到这样的目的,选择一款快速、高效的后台程序款框架是我们必须要考虑清楚的。一个后台框架是一系列工具、代码包以及其他软件模块的集合,利用这些基础设置你就可以快速的开发出功能全面的服务器后台程序。这些框架在设计之初就考虑到了将来的服务器程序要面临的需求,并且提供了比较合理全面的解决方案。我们只需要根据我们的需求,对应到这些框架的不同模块,利用这些模块实现我们的业务代码即可。

本人掌握了包含市面上大部分常用的编程语言以及相关的框架,也都使用过这些框架开发出了 server 程序。在2021年,我罗列出目前常用的几个框架与大家分享交流。

Laravel

编程语言:PHP

laravel是一个免费、开源的PHP开发框架,它是基于MVC程序结构设计的。对于常年使用PHP语言做项目的人来说,laravel是普遍的首选方案。我以前接手的一些项目,云服务器平台是客户早年就在使用的,比如GoDaddy、Hostinger 等等,这些云平台对PHP语言的支持非常好,那么考虑到入乡随俗,要使用云服务里的PHP环境,那么用laravel就是非常合适的了。

laravel提供了权限管理、API 设计、后台缓存、日志管理、测试等多种功能。它的文档也非常的全面易懂。laravel 非常适合用来开发博客网站、门户网站、电商网站的后台。

不过时过境迁,由于现在更多更好的框架的出现,PHP语言以及laravel变得有些过时和年迈,很多人会暂时放弃PHP以及laravel,会尝试使用其他的选择。

Flask vs Django

编程语言:Python

我把这两个框架放在一起进行说明。几年前我在自学完Python语言后,就去寻找基于Python的服务器开发框架,flask和Django是两个常用的。在玩过了这两个框架之后,我明确的选择了Flask。因为我个人的开发风格和习惯是前后端分离的,用Angular或者Vue去专心开发前端页面,用框架细致的开发后端服务器的一些功能,前后端之间的通信和数据交换使用 Restful API 来实现。

Django也是一款比较强大的框架,但是它对前后端分离风格的开发者不太友好。在开发的时候很多时候需要将前端的HTML、JavaScript和后端的Python进行联合开发,代码可能会比较混乱。但是事情都有两面性,反过来讲Django的封装性更好一些,很多功能都是拿来即用的,只要根据自己的需求稍加修改,就可以快速的实现一些功能,比如form表单。

而 Flask 是纯粹的前后端分离的风格,属于微型框架。你在用Flask写代码的时候,可以完全不需要考虑前端。可以专心的开发服务器程序。最后提供一些 API 访问链接地址给前端即可。所以Flask 框架会比Django更小,使用flask也需要开发者去处理和开发更多的功能逻辑。

Express.js vs Koa2

编程语言:JavaScript / TypeScript

得益于node.js的流行和广泛使用,历史悠久、可爱的JavaScript语言终于可以涉足到后台服务器程序开发领域了。一般的,在安装好node.js后,很少有人会直接用JavaScript原生的开发服务器代码,而是会选择一款框架。那么express.js和koa2就是目前比较流行的两款框架了。

他们都可以用 JS 快速的开发出 API 程序,也都能通过安装其他的模块实现与后台数据库的连接。我个人在多年的编程经历中,面对中小型的项目,对性能要求不高的时候,都会考虑使用这两个框架。一般会很快的写好 Restful API 程序和数据库的CRUD程序。另外部他们两个的部署也比较方便,Linux上装好node.js,然后服务器程序文件放在一个地方,用 pm2 这种基于 node.js 的命令工具启动即可向前端提供服务了。

这两个框架其实是同一班人的作品。express.js问世的较早,koa2其实是express.js的改进,代码更加精炼紧凑,都是不错的选择。

Spring

编程语言:Java

聚光灯照顾来,欢呼尖叫响起,superstar 到来了。没错,spring是这几年服务器开发框架里的明星。基于Java这几十年的稳健发展,已经有了太多的处理各种问题和需求的Java第三方包。再结合spring的优良品质,比如常见的权限控制、Restful API 开发、SQL/NoSQL 数据库操作这种常见的功能以外,还可以想象一下利用spring结合hadoop生态来开发big data 应用,那会是另外一片天空了。

我个人在2020年指导了几个本科大学生的毕业设计项目。他们告诉我,他们的老师不仅要求他们写论文,还需要他们开发一个完整的Web项目,要有网站、服务器,后面还要挂个数据库。值得注意的一点是,导师们要求他们必须用spring框架实现服务器。这些学生当然连前端三剑客 HTML/CSS/JavaScript 都还没有玩会,后台抽象的代码更是小白一个。他们说导师也只是知道有这种技术,但是也没法完全指导他们,所以我就有了雪中送炭的机会。

另外,现在很多中大型网站的后台的主要业务逻辑,就是用java的spring来实现的,并结合其他技术向外提供服务。比如国内的一些电商平台就是这样的设计。

其他

上面我只是列举了几个典型的方案,其实还有很多,我基本上都玩过。比如 hapi(JavaScript)、Golang(Go)、Slim(PHP)等等。大家可以根据自己的需求和实际情况,了解这些框架后进行选择。

如何选择合适的框架

和择偶很类似,选择适合的才是明智之选。大家都说她好,包括你的父母都很欣赏那个人,但是你就是不喜欢。所以强扭的瓜不甜。下面是几条选择框架的方针,供大家参考:

  • 要明确自己开发的服务器后台的目的,以及将来的后台的规模,数据量或业务量的大小,峰值是多少。拿着这些需求和目的,去和众多的框架去对照,选择能够真正解决你的需求的框架。
  • 框架的安全性如何。毕竟服务器程序不是儿戏,前端其实只是个交互操作界面,大部分真正的数据和处理逻辑都在后台服务器。我曾经用了一个小时,就很快的模仿开发出了微信App的程序,但是这没有什么可炫耀的,微信厉害的地方其实在它的后台!
  • 随着时间的推移,一般的,对于后台服务器程序的访问量、数据流量、数据读写的 I/O 效率都会有更高的要求。那么我们要仔细考虑一款框架的适应性如何,是否能够随着业务的增长同样能够提供相同的性能。
  • 易于部署、配置和维护。这时毋庸置疑的,我在以往的涉猎过程中,体验到了基于Go语言的后台项目是最易于部署的,只要基于不同的OS(Windows,LInux)将代码编译好之后,直接放在操作系统里并启动即可。需要编译的方案,运行起来速度会更好,比如Java的框架。有些是不需要编译,是解释运行的,比如JavaScript / node.js的框架,部署可能方便,但是运行效率可能会有些折扣。不过由于现在的硬件机能已经比20年前有了指数级的发展,所以在没有特殊要求下,基本上哪个方便不麻烦就用哪个吧。
  • 开发文档的质量。现在很多人学习计算机还迷恋与哪一本书,哪些视频教程。在十几年前倒是可以这样考虑,因为以前互联网并不发达,网速、内容资源都比较差,买书学习就成了首选。现在就不同了,现在你如果买了书,可能书里的内容可能很快就会过时,就会和实际情况有了差距。有些人也会去报培训班,大家请擦亮眼睛,培训班也是要走流量的,公司要求一波学生必须在4~5个月结业,如果时间太长,他们占用了教室、教师资源,公司就很难再继续招收新的学生了,那么他们的现金流量就可想而知了。所以培训班的老师讲课都是非常快的,非常刻板的,他们每天都有进度的要求。这样填鸭式的教学效果我就不用多说了。说回来,一款框架肯定都有他们自己的官方文档,这几年我还发现这些网站对中文的支持也很好了,以前基本上没有中文版的官方开发文档。那么好好利用这些官方文档来学习是最靠谱的。大家能自学就不要去请教别人,自己琢磨、钻研、尝试后得到的收获对自己的技术更加有帮助,而且成本更低。
  • 学习曲线。也就是学习的难度和周期。这点就要和编程语言有所结合了,比如JavaScript、Python更加容易上手,Java稍微难一些复杂一些。这一点其实仅仅是针对初学者或者入行时间不长的人的,像我这种已经熟练掌握了至少4门语言,能玩转10多门语言的人,学习曲线基本上可以不用考虑。
  • 社区。这一点也很可观。一款框架用的人多,他们遇到的问题也就会多,那么他们在网络上查询问题、询问问题也就多,那么就会有更多的人给出各种问题的解决方案来。慢慢的就形成了社区,现在很多成型的编程社区网站就是这样建立起来的。典型的就是 stackworkflow,我经常能在这里找到灵感。个人意见啊,我建议读者们但凡有一点英文能力,就去英文网站找解决方案。国内的百度搜出来的结果一般都很烂,没啥帮助,有些人就算给出方案也能看出来是敷衍的写的,要么语言表述不清,要么代码胡乱粘贴。能翻墙就翻墙用Google,不能翻墙就用Microsoft bing(国际版),一般搜出来的都是国外网站,里面有很多有识之士给出的解答更加有帮助,甚至立竿见影。

送给大家一句话:

择偶时,没有最好的,只有合适的。选择框架也是一样的 !

一个学期前小编也是对前端知之甚少,现在嘛,差不多弄懂了一些,来讲讲自己的理解吧ヽ( ̄▽ ̄)ノ 因为学习的深度不是很深,有错误的地方欢迎指正~如果没有学会建站,小编教你如何简单快速搭建网站,喜欢的收藏哦~~不要错过

首先我们要知道访问网站的流程是什么?大家每天也访问。

假设大家在浏览器地址栏输入这个问题的地址

https://www.头条.com/question/22689579


HTML 与 CSS

当自己的电脑得到一个 html页面 (图中HTTP 响应中 body 里的内容)之后,就会对它进行解析。HTML 就是一种超文本标记语言。给大家举一些实例看看:

  • [img]图片[/img] 用来粘贴图片
  • [url]超链接[/url] 用来粘贴地址

服务器返回给你的html文件,写的是一些代码,大概是这样的:

浏览器拿到这些代码之后,将分析渲染好页面显示出来,如果不用css,效果如下图,按照浏览器默认的样式显示出表格,超链接等。

大家有么有觉得默认样式有点ε(┬┬﹏┬┬)3……所以很多情况我们需要自定义这些样式,目前通用的样式语言就是CSS,我们用CSS写一些自定义样式的代码,之后在 HTML 文件里用一个<link>标签把这些规定样式的 CSS 与表达内容语义的 HTML 代码链接起来,然后大家就能看到以往所谓的正常的页面,是不是很厉害呢~~~


CSS 代码的基本格式

属性:值

比如头条的分布框架排版,它的 CSS ,截图大体如下

把第一个属性对应的代码翻译一下的话,背景图像位置偏移量(background - position)在图像距离页面内左上角水平1px垂直2px处,浏览器会规规矩矩的地实现代码要求的效果,所以当大家在页面上下滚动时,顶上那个导航条都会牢牢地黏在窗口顶部固定的位置,不发生偏移。

再讲讲其他几个属性解释一下:

  • left 为240px 说明这个模块需紧贴着窗口的左240px处

  • width 和 height 指定模块的宽和高

  • border 指明这个模块的边界范围

换句话说,就是浏览器就会根据这些 CSS 代码,自动描绘出对应的样式。


HTML 5 与 XHTML

像语言一样,大家在网页里的 发现的HTML 代码也不一定是标准的,就好比有时候发音不太标准,别人就会去猜测你说的是什么一样,sometimes,程序猿不小心写错了一个 HTML代码,浏览器也会试图猜测这些人类原来到底想写什么,之后做出对应的处理,而这里的猜是要有一个常识做依据的。加上有些浏览器的功能不一,有的支持一些标签,有一些又不支持,还有一些混乱的情况。

为了防止大家混淆,我们要对 HTML 代码里的标签,标签how写,标签可以hava属性这些东西,建立一个符合的标准,HTML5 就是其中一个比较新的标准。其中新加了很多可以用的标签和属性,然后各大浏览器也大刀阔斧的按这个标准去实现了很多新标签和属性。

本来前端程序员要写一堆代码去实现的效果,现在浏览器都给实现了,只需程序猿写两三行,调用一下浏览器就给搞定了,十分简单,所以很多人都愿意去推广这个标准~(当然新标准也不可能是完美的,也会有一些问题,有兴趣的朋友可以去查查)

至于 XHTML,就是 HTML 的表亲,XML 和 HTML 自己的杂交系列,对语法要求十分的严格,为了兼容 XML,在语法上与 HTML 有一些不同。


JavaScript 与浏览器脚本

有了表示内容和语义的 HTML,规定样式的 CSS,得到的是静态的页面,没什么动画,虽然用 CSS 可以有一些动画,需要刷新数据才可以,这么呆板单调的网页怎么能展现我大智人种族的创造性!于是我们创造了 Javascript(JS) 来给页面添加一些动态的效果,比如头条的发表的标签,鼠标移上去会弹出一个小窗口,这个就是 JS 实现的效果啦。

浏览器都会帮大家实现一些Javascript可以用的工具(函数,对象等),只要写一些 JS 的代码,保存在 xxx.js 里,在 html 文件中用 <script> 关联进来就可以用了,像上图这个效果应该就包括了

  1. 鼠标悬停到标签上时创建一个新的 <div> 小窗口

  2. 用 JS 向头条服务器发送一个请求,得到这个小窗口应该显示的数据,放在这个小窗口里(这就是所谓的AJAX,不用刷新就能与服务器进行交互,更新页面的一小部分~)

浏览器拿到这样的代码,就会解析并实现出相应的效果。其实用来写浏览器脚本的,也不是非得JavaScript 不可,不过是各大浏览器都默认了:请用 JS 写这些动态效果的代码给我解析~


以上就是前端部分的内容,下面简述一下后端的东西吧> <

Web Server 和 Web Services

浏览器给服务器发一个请求,服务器不是一看就知道怎么响应的。首先这些请求和响应要有一个通用的写法,也就是要有一个协议,常用的是 HTTP 协议。

像最前面的图,服务器的响应写了一个状态码 200 OK ,是 HTTP 协议里约定俗成的一个东西,服务器写 200 OK 在响应里,表示“你请求的这个东西我有”,如果是404 Not Found,就是“你请求的这个东西我这里没有”。

HTTP 响应里还包括很多东西,比如 Content-type 表示服务器发过来的文件类型是什么(文本?动画?图片?音频?),这样发过去了人家浏览器好知道怎么展示给用户看。人家服务器怎么知道按协议要写什么东西进去呢,这就是 Web Server 干活的时候了。

形象化一下HTTP响应,大概就长这样:

再上个锤子,浏览器和服务器之间请求响应的过程大致是长这样的,右下角的那些东西就是由 Web Server 生成的(服务器脚本可以做一些改动,但这些一般是 Web Server 的份内活):

再比如说很多时候你访问一个网站,浏览器里输的地址并没有写明你请求的文件,比如这个问题的地址是:

http://www.头条.com/question/22689579

但头条的服务器其实返回了一个html给你,服务器怎么知道这个地址对应要返回什么样的 html 代码给你的?也是 Web Server 干的活。

除了浏览器输地址敲回车这种赤裸裸的访问,客户端与服务器的交互还有很多种,比如:

  • 前面提到的用 JS 完成的 AJAX,有点像浏览器和服务器之间的悄悄话~

还有其他应用软件与服务器的交互,比如:

  • 微信、QQ 与腾讯的服务器的交互

  • 网游客户端与网游公司服务器的交互

  • 搜索引擎用来搜集网页信息的程序(爬虫)与各种各样的网站服务器的交互

  • 只要你知道用什么地址访问、怎样访问人家的服务器,并且有相应权限,你也可以自己写一些程序去和他们的服务器交互(比如用微博API - 新浪微博API获取微博,开发第三方应用或者做数据分析)。

从这些例子里可以看出,客户端与服务器的交互的主体、客体、载体是五花八门的:

  • 服务器可以是大型机也可以是个人电脑,只要能跑相应的程序就行

  • 客户端像前面举的栗子里一样,可以是各种软件,而且这些软件不一定运行在个人电脑上,也可以是手机、平板、智能穿戴设备等等

  • 有时候不是传生成好的 HTML 或者其他服务器上已经有的文件,而是传输经过一定逻辑处理后生成的字符串或者其他各种封装好的数据

像前面提到的 HTML 需要有一定标准一样,为了防止混乱和鸡同鸭讲,我们又需要先对这些机器需要怎么交互达成一定共识,再让它们进行交流。人与人之间通信,需要先有一种大家都认识的写法(比如简体字/繁体字)和一种彼此都懂的语言(比如普通话/广东话)。

要让这些形形色色的机器能够通过网络进行交互,我们就需要指明一种协议(比如 HTTP/HTTPS)和一种数据封装格式(比如 HTML/XML),Web Server 提供的 Web Service,指的就是这种协议+格式的交流体系。不过 Web Service 的生态系统和 HTML 的标准不一样,用户可以选择的协议和数据封装格式更多,普通的网站访问用的 HTTP + HTML 只是其中一种,一些封闭系统内的交流还可以自己定义一个协议和格式来用(比如 QQ)。

Web Service 传输的数据再经由本地客户端(浏览器、QQ/微信,网游客户端等)的分析渲染,就能够以普通人能够理解的形式展现出来。此外还有一些 Web Service 并不是为普通用户设计的,像前面提到的微博API,是用来给程序猿进行二次开发的~

除了提供 Web Service, Web Server 还会兼顾很多功能,包括提供缓存,平衡负载,这样在访问量比较大的时候能有有条不紊地接客。常见的现成的 Web Server 有开源的 Apache、Nginx和微软的IIS,你也可以用一些工具(比如 Node.js )自己定制一个。因为 Web Server 需要比较好的性能,所以投产时用的 Web Server 通常是C/C++/Java写的,但是其实很多语言都可以写,而且配合上语言底层的优化和好的模型,其他语言写的 Web Server也可以有不错的表现。

PHP ,服务器脚本,Web Framework

开头那张图里服务器接到请求之后可以给访客发送对应的文件,但21世纪的服务器怎么可能只会“接请求-发文件”这么弱智的一招呢,人家还可以处理你上传来的文件的!还可以接受你发过来的各种请求,去操作服务器本地的文件or数据库的!要干这些事,自然服务器那边也少不了要有代码了,这些代码就是服务器脚本。前面说的 Web Service 传输的数据,主要也是由服务器脚本生成,再交由 Web Server ,按照某种协议套好整个响应的格式,返回给客户端的。

同一个网址,每个人看到的页面不一定是一样的,比如头条的网址都是

http://www.toutiao.com/

但是没登陆和登陆之后看到的东西不一样,登陆之后每个人看到的导航栏的用户信息,关注的动态,都不一样。服务器脚本可以对这些不同的状态,生成不同的页面,交给 Web Server 返回给浏览器。

知乎的主页给大家看到的 html 整体来说是差不多的,都有导航栏,左边是关注的动态,右边是广告和边栏,每一块的整体构造大同小异,只是一些地方内容有所区别。服务器脚本就是利用已知的数据,在这些因人而异的地方填入相应的内容,生成给每个人看的页面。

比如我的主页,导航栏右边的头像和名字跟别人看到的不一样,就是因为这块地方有一个放图片的<img>标签和一个写名字的<span>标签,服务器脚本在查询本地的数据之后给我返回的页面里<img>的标签填了我头像的图片链接,<span>标签里填了我的头条名,给别人的页面就填其他链接、其他名字,这样每个人看到的页面就不一样了。

PHP 就是一种常见的用来写服务器脚本的语言,其实只要是能拿来写大家传输数据的通用接口(CGI)的语言都可以用来写服务器脚本(也就是说几乎所有编程语言都可以写 = =b),只是因为现成工具的丰富程度和专攻程度不一样,所以有一些语言在写服务器端脚本的时候会比较热门。

为了方便,我们在写服务器脚本的时候,通常还会用个同语言写的 Web Framework 来处理各种细节,防御一些常见的攻击,提供跨站认证(比如用已有的微博账号注册其他网站)的接口,利用cookie处理登陆状态和用户设置,生成网页模版之类的。如果你用 C# 或者 Visual Basic 写服务器脚本,就可以用 http://ASP.NET 这个框架实现这些功能,帮你省点麻烦。不过现在不少人是反过来为了一个好用的 Web Framework 去选择它对应的服务器脚本语言的。

一个普通网站访问的过程

简单概括一下,对于我们普通的网站访问,涉及到的技术就是:

  1. 用户操作浏览器访问,浏览器向服务器发出一个 HTTP 请求;

  2. 服务器接收到 HTTP 请求,Web Server 进行相应的初步处理,使用服务器脚本生成页面;

  3. 服务器脚本(利用Web Framework)调用本地和客户端传来的数据,生成页面;

  4. Web Server 将生成的页面作为 HTTP 响应的 body,根据不同的处理结果生成 HTTP header,发回给客户端;

  5. 客户端(浏览器)接收到 HTTP 响应,通常第一个请求得到的 HTTP 响应的 body 里是 HTML 代码,于是对 HTML 代码开始解析;

  6. 解析过程中遇到引用的服务器上的资源(额外的 CSS、JS代码,图片、音视频,附件等),再向 Web Server 发送请求,Web Server 找到对应的文件,发送回来;

  7. 浏览器解析 HTML 包含的内容,用得到的 CSS 代码进行外观上的进一步渲染,JS 代码也可能会对外观进行一定的处理;

  8. 用户与页面交互(点击,悬停等等)时,JS 代码对此作出一定的反应,添加特效与动画;

  9. 交互的过程中可能需要向服务器索取或提交额外的数据(局部的刷新,类似微博的新消息通知),一般不是跳转就是通过 JS 代码(响应某个动作或者定时)向 Web Server 发送请求,Web Server 再用服务器脚本进行处理(生成资源or写入数据之类的),把资源返回给客户端,客户端用得到的资源来实现动态效果或其他改变。

注意这只是小网站里比较常见的模型,大网站为了解决规模问题还会有很多处理,每个环节都会有一些细微的差异,中间还会使用各种各样的工具减轻服务器的压力,提高效率,方便日常维护~

延伸阅读 —— 那些看花眼的名词

为了方便调试,很多 Web Framework 会自带一个简单的 Web Server,或者有些 Web Server 会自带一个简单的 Web Framework ,实际部署到服务器上开放使用的时候为了性能或者安全等多方面的考虑,可以把内置的 Web Server 换成其他的,比如 Apache 或者 Nginx (举个栗子,知乎用的是 Tornado 做 Framework,Server 换成了 Nginx,见知乎使用了哪些框架和开源库?)。如果是开源的东西,还可以在遵守开源协议的前提下自己改一下再用~

因为后端不像前端已经有 HTML + CSS + JS 这样的既定事实标准,服务器脚本与 Web Framework 的选择很多,所以新手会听到很多眼花缭乱的技术名词的地方多在这里~ 举一些栗子,早年常见的服务器端语言有:

  • 开源的 PHP

  • Sun 公司的 JSP 中使用的 Java

  • 微软的 ASP 中使用的 VBScript

现在在这方面的应用热起来的语言有

  • Python,对应常见的 Framework 包括知乎和Quora有用到的 Tornado(其实是自带 Framework 的 Web Server),社区很成熟的 Django (用户包括 Instagram、Pinterest)等

  • Ruby,一般都用 Rails 这个 Framework,用户包括 Github、早期的 Twitter 等

  • 逆天的 JavaScript,有了 Node.js 这个平台,Web Server、服务器脚本和浏览器脚本全都可以用 JavaScript 来写……Node.js上最常用的 Framework是Express

  • 微软家的则跟着 http://ASP.NET 转移到了C# 或者 Visual Basic

  • Erlang,擅长大规模的并发,不少游戏公司拿来写服务器,靠几十个工程师支撑几亿用户的WhatsApp也是用的这个~

几种常见的架构包括:

  • LAMP = Linux + Apache + MySQL + PHP(P还可能是Python或Perl。有时候L会改成W=Windows。),也就是服务器上的操作系统是 Linux,Web Server 用 Apache,数据库用 MySQL,服务器脚本用 PHP,这些都是开源技术,网站起步时用起来的成本会比较低,所以是普通网站里非常常见的架构(虽然对于发展得很大的网站会遇到很多瓶颈),Facebook就是这种,淘宝也曾经是。

  • J2EE,Java 世界的架构,通常是企业用的(银行、大型公司,.etc),比较常见地还会搭配一种 UNIX 做操作系统,Apache 做 Web Server,Tomcat 转换 JSP 到 Java 给服务器程序用(其实它也自带 Web Server),Oracle 数据库等等。不一定拿来建站,常常用来提供企业里的各种需要用到网络的业务。我们学校教务系统就是用J2EE做的=。= 淘宝现在也是从LAMP转型到了这个。关于tomcat等之前的文章也有提及环境的配置。

  • http://ASP.NET,微软家的架构,通常会搭配 Windows Server 操作系统,SQL Server 数据库,IIS 做 Web Server。StackOverflow和京东(曾经)就是这个架构。

  • 神奇的MEAN架构,MongoDB做数据库,Express做 Web Framework,Angular 做前端的 JavaScript 框架,Node.js 用于编写 Web Server。神奇之处在于这几个东西的语言都是 JavaScript (MongoDB的实现不是,但与外界沟通用的语言是)。因为是比较新的架构,还有待时间的考验,不过被很多人(尤其是靠 JavaScript 吃饭的前端程序猿们)热切关注。

  • 一般来说重点不在技术而且在乎成本的新网站比较喜欢用 LAMP,重视安全稳定和速度的企业和机构喜欢 J2EE,想省事的网站喜欢 http://ASP.NET,比较 Geek 的网站和创业公司喜欢折腾各种 Python、Ruby、Node.js世界的东西,Google 这样现成的技术都解决不了需求的超大型网站就自己折腾解决方案。

虽然可以用的语言和所属体系五花八门,其实服务器端程序要做的事情本质上都差不多的,就好比自然世界中要表达“吃过了没”这句话的意思,你可以用各种各样的语言在各种各样的场景里表达出来~

如果大家喜欢,欢迎收藏,多多关注小编呐~ 还有会更多精彩的分享

家好, 我是可爱的排骨

目录一. speedtest 简介.
二. 安装到 Windows. 难度 ★★
三. 安装到 Linux. 难度 ★★★★★
四. 安装到 群晖 DSM. 难度 ★
五. 使用 Docker 镜像部署. 难度 ★★★
六. 总结

一. speedtest 简介.

1. 作者简介.

喝井不忘挖水人, speedtest 的作者不是排骨, 是下面这位.

speedtest 是由意大利的一位90后爱打游戏爱跳舞机的逗B码农 Federico Dossena (见下图) 发布的一个开源项目 (https://github.com/adolfintel/speedtest).

2. 原理简介

speedtest 以 HTML 和 JavaScript 为主, 利用客户端的浏览器通过上传和下载垃圾数据来测试 HTTP 传输速度, 和大家常用的 speedtest.net 差不多.

speedtest 使用任意操作系统上的任意 Web 服务器作为服务端, 所以理论上它支持 Windows/MacOS/Linux/Unix 等系统, IIS/Nginx/Apache/lighttpd 等服务器.

任意浏览器作为客户端如 Chrome/Firefox/IE11/Edge/Safari/Opera?

speedtest 默认使用 PHP 作为服务端, 目前也有 node.js 版本, 也可以只用纯静态服务器.

本文所说的 speedtestOokla 公司的 speedtest.net相关测速 app 没有任何关系, 没何关, 没关, .

**二. 安装到 Windows. 难度 **★★

在 Windows 上安装 speedtest 应该是绝大多数普通用户, 为了照顾没有相关经验的用户, 这里排骨写的步骤较多较细, 但是已经最大化的精简了.

本文以 Windows 10 为例, Windows 7 也适用, 不过某些地方有不同, 排骨会注明.

1. 安装 IIS 服务器.

使用 Win+R 打开运行窗口, 输入 **OptionalFeatures **打开 Windows 功能.

必须选择 IIS 管理控制台/静态内容/默认文档/CGI 4个选项. 默认文档不是必需的.

2. 下载并安装 PHP Manager for IIS.

PHP Manager for IIS 是微软官方推荐的一个 IIS 插件, 可以最大化的简化 IIS 上配置 PHP 的过程. 如果不用这个插件, 在 Windows 上配置 PHP 会比 Linux 上更麻烦.

下载地址: https://www.iis.net/downloads/community

Win7 系统安装** PHPManagerForIIS-1.2.0**

Win10 系统安装 PHPManagerForIIS_V1.5.0, 这里排骨以 Win10 为例.

如果出现 SmartScreen 提示, 请按上面的图继续.

安装过程就是一路 Next.

3. 下载 PHP 包并解压

x64版下载: https://windows.php.net/downloads/releases/php-7.2.6-nts-Win32-VC15-x64.zip

x86版下载: https://windows.php.net/downloads/releases/php-7.2.6-nts-Win32-VC15-x86.zip

将下载好的 zip 包解压到任意路径, 如 F:\php

4. 为 IIS 配置 PHP.

使用 inetmgr 命令扫开 IIS 管理器.

打开 PHP Manager.

通过 “Register new PHP version” 设置 PHP 引用路径.

上一次我们把 PHP 的文件解压到了 F:\php.

使用 Check phpinfo() 测试 PHP 配置是否成功.

如果看到这个紫色页面, 就说明 PHP 配置成功了.

5. 下载 speedtest 包并解压.

speedtest 包下载: https://github.com/adolfintel/speedtest/archive/4.5.5.zip

解压到 C:\inetpub\wwwroot, 熟悉 IIS 配置的用户可以解压到其它地方.

注意所有文件都在压缩包里的子目录中!

6. 测试 speedtest.

用浏览器 (推荐 Chrome) 访问 http://localhost/example-pretty.html. 如果出现下图这样的测试结果则表达 speedtest 运行成功.

7. 防火墙开启入站 80 端口.

这一步是可选的. 如果内网的其它电脑或手机无法访问这台 Windows 上的 speedtest, 可能是被 Windows 防火墙挡了.

将 Windows 入站端口 80 打开后, 内网的其它设备才能访问刚刚安装好的 speedtest.

以管理员身份运行 cmd 打开命令行窗口. 使用下面的命令行给防火墙开启 80 端口.

netsh advfirewall firewall add rule name=“speedtest” dir=in action=allow protocol=TCP localport=80

Win7命令为

netsh firewall add portopening TCP 80 “speedtest”

最后用手机或其它电脑访问 http://192.168.1.91/example-pretty.html 开始测速吧 (假设安装 speedtest 的电脑 IP 为 192.168.1.91).

**三. 安装到 Linux. 难度 **★★★★★

一般用户家中没有 Linux 电脑, 不过排骨考虑到使用 OMV 等系统作 NAS 的用户和自购有 VPS 的用户, 顺便也写一下 Linux 上安装 speedtest的步骤. 用 Linux 系统的用户基础都不会太菜吧?

下面 ubuntu 18.04 为例, 其它 Linux 版本的用户请自行调整.

1. 安装 nginx 和 php-fpm

sudo apt install nginx php-fpm

2. 修改 nginx 站点配置

sudo nano /etc/nginx/sites-available/default

以下面为修改配置文件内容, 注意 /var/run/php/php7.2-fpm.sock 的路径是不是正确.

server { listen 80 default_server; root /var/www/html; index index.html; server_name _; location / { try_files $uri KaTeX parse error: Expected 'EOF', got '}' at position 19: …/ =404; }̲ locatio… { include snippets/fastcgi-php.conf; fastcgi_pass unix:/var/run/php/php7.2-fpm.sock; }}

重启 nginx.

sudo service nginx restart

3. 下载 speedtest 并解压

speedtest 包下载: https://github.com/adolfintel/speedtest/archive/4.5.5.zip

sudo wget https://github.com/adolfintel/speedtest/archive/4.5.5.zip

解压到 /var/www/html.

sudo unzip 4.5.5.zip -d /var/www/html/sudo mv /var/www/html/speedtest-4.5.5/* /var/www/html/

4. 防火墙开启入站 80 端口

这步也是可选的.

sudo ufw allow 80

安装配置完成. 开始测速吧!

**四. 安装到 群晖 DSM. 难度 **★★

在群晖系统上安装 speedtest 是个非常好的选择, 也是最简单的方案. 与 Linux 上安装 speedtest 类似, 群晖的管理系统本身就是基于 Linux 和 nginx 的.

1. 下载 speedtest 并上传到群晖.

speedtest 包下载: https://github.com/adolfintel/speedtest/archive/4.5.5.zip

将 speedtest 包中的文件上传到群晖共享文件夹的某个目录, 如下图

2. 安装 Web Station 和 PHP 7.0.

从群晖套件中心可以找到, PHP 7.0 可能在安装 Photo Station 时一并安装好了.

3. 设置 PHP 和 虚拟主机.

打开 Web Station 套件, 选择 PHP 设置, 编辑默认PHP配件文件. 勾选 openssl.

选择 虚拟主机, 点击 新增, 然后按下图配置虚拟主机. 其中 端口文档根目录 按实际情况设置.

安装配置完成. 开始测速吧!

**五. 使用 Docker 镜像部署. 难度 **★★★

用 Docker 部署 speedtest 是最简易快速的方法, 但是对用户来说起点也是最高的.

排骨专门给 speedtest 制作了 Docker 镜像 (6MB), 比原作者的镜像 (158MB) 小很多很多很多.

1. 下载 speedtest 镜像.

docker pull cuteribs/speedtest

2. 创建 speedtest 容器.

docker run -d --name speedtest -p 80:80 cuteribs/speedtest

安装配置完成. 开始测速吧! 2行命令就搞定了, 是不是简单得要死而绝大多数人又不会?

六. 总结

按上面任一方法搭建好 speedtest 服务器后, 就可以愉快的测速了.

不论是测内网还是外网

不论是测 路由器, AP, 网卡还是VPS

不论是测 有线 NAT, 2.4G/5G WiFi 还是 SS等软件转发

只要打开浏览器, 输入 speedtest 地址就行了.

speedtest 测速的优点:

  1. 测试简单暴力. 浏览器就能测, 无需别装 app.
  2. 界面简洁明了. 直观且无广告不收费.
  3. 上行下行兼顾. 不用双向测试, 不像 iperf3 只能单向.

speedtest 测速的缺点:

  1. 用户技能要求. 需要自己安装测速服务器, 希望本贴能解决这个问题.
  2. 测速协议片面. 基于 HTTP 协议测速, 有些片面. 不过95%的用户有90%的网络使用都是 HTTP. (纯瞎说的 哈~)
  3. 性能瓶颈要求. 因为基于 Web 服务器和 JavaScript, 所以服务器和客户端性能不能太差. 测试 2.5/5/10 千兆可能力不从心.