怎么选择好的服务器

导语：服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。那么，我们可以怎么选择好的服务器?

怎么选择好的服务器

你需要从不同的角度来决定选择一台什么样的服务器,找到满足技术需要、业务发展和成本控制之间的最佳平衡点,为了做到这一点,绝对还是需要一点智慧。51IDC将在下面为大家介绍一些易于理解,尽可能全面的建议,并帮助你做出决定。

先不要急于决定需要怎样的CPU,几个硬盘,几个G内存,需要多少兆带宽这样的问题,那些是我们最后需要得到的答案。在这之前,先一起梳理几个问题。在下面,我们列出了一些“多少”或“什么样”的问题,拿起你的笔或在Windows记事本里新建一个文件,尝试根据下面四个问题来评估自己的需求:

1.服务器运行什么应用?

2.需要支持多少用户访问?

3.需要多大空间来存储数据?

4.我的业务有多重要?

1：服务器运行什么应用?这是首先需要考虑的问题,在这里你要根据服务器的应用类型,也就是用途,来决定服务器的性能、容量和可靠性需求。我们按照前端服务器+应用程序服务器+数据服务器的常见基础架构来讨论:

1.1Web前端:正常情况下,我们认为大多数Web前端服务器(Front-end)对服务器的要求不大,例如静态Web服务器、动态Web服务器、图片服务器等等,因为在现有的技术框架中,我们有很多方案可以解决前端服务器的性能扩展和可靠性问题,例如LVS、Nginx反向代理、硬件负载均衡(F5,A10,Radware)等。甚至在很多访问量不高(几百个用户同时在线)的应用中,51IDC的经典酷睿服务器就可以满足需求。

1.2应用服务器:由于承担了计算和功能实现,我们需要为基于Web架构的应用程序服务器(Application Server)选择足够快的服务器,另外应用程序服务器可能需要用大量的内存,尤其是基于Windows基础架构的Ruby,Python,Java服务器。这一类服务器至少需要使用单路至强的配置。对于可靠性的问题,如果你的架构中只有一台应用服务器,那肯定需要这台服务器足够可靠,RAID绝对是不能忽视的选项。但如果有两台或更多的应用服务器,并设计了负载均衡机制,具有冗余功能,那我们则不必将每台服务器武装到底。

1.3特殊的应用:除了作为Web架构中的应用程序服务器之外,如果你的服务器是用来处理流媒体视频编码、服务器虚拟化、媒体服务器(Asterisk之类),或者作为游戏服务器(逻辑、地图、聊天)运行,则同样对CPU和内存需求比较高,我们至少要考虑单路至强的服务器。其中服务器虚拟化对存储的可靠性的要求都非常高,因为一个篮子里有十几个鸡蛋,篮子一定要足够牢靠才是。

1.4公共服务:我们指的是邮件服务器、文件服务器、DNS服务器、域控服务器这类服务器。通常情况我们会部署两台DNS服务器作为互相备份,域控主服务器也会拥有一台备份服务器(专用的或非专用的),所以对于可靠性,无需达到苛刻的地步。至于邮件服务器,至少需要具备足够的硬件可靠性和容量大小,这主要是为了对邮件数据负责,因为很多用户没有保存和归档邮件数据的习惯,当他们重装系统后,总会依赖重新下载服务器上的数据。至于性能问题,我们认为需要评估用户数量才能决定。

1.5数据库:我们最后讨论的应用,也是要求最高,最重要的服务器。无论你使用的是MySQL、SQLServer还是Oralce,一般情况下,我们认为它需要足够快的CPU,足够大的内存,足够稳定可靠的硬件。单路至强CPU/4GB内存/Raid1绝对是入门配置。关于准确的配置我们需要再讨论业务需求后才能作决定。

2：服务器需要支持多少用户访问?服务器肯定是为了提供某种服务,而使用这些服务的用户同样是我们必须考虑的因素,有几个具体的问题你需要做出评估:有多少注册用户?正常情况下有多少用户会同时在线访问?每天同时在线访问的最高峰值大概是多少?这些问题,对我们决定采用什么样的CPU,多大的内存有着至关重要的影响。51IDC建议你的技术人员和业务部门坐在一起来讨论这几个问题,最后甚至需要按照特定的技术模型和算法,将这些数字转化为一些更具体的技术数字,例如并发多少个连接(很多时候,用户数与连接数不是一个概念)。同时,你还要对未来的用户增长做一个尽可能准确的预测和规划,你的服务器需要支持越来越多的用户。

3：需要多大空间来存储数据?我们需要从两个角度来计算这个问题,一个角度是有哪些类别的数据,包括:操作系统本身占用的空间、安装应用程序所需要的空间、应用程序所产生的数据、数据库、日志文件、邮件数据等等,如果是Web2.0类的网站,你还要计算每个用户的存储空间另一个角度是从时间轴来考虑,这些数据每天都在增长,你至少要为未来1年(我们建议2~3年)的数据增长做个准确的测算,这可能仍然需要你的软件开发人员和业务人员一起提供足够的信息。最后你仍然需要为计算出来的数字结果乘1.5左右的系数,方便维护的时候做各种数据备份和文件转移操作。

4我的业务有多重要:你需要根据自身的业务领域,来遵循一些要求,我们在下面举几个简单的例子,帮助你理解这些服务器对可靠性、数据完整性等方面的要求:

4.1如果你的服务器用来运行一个WordPress博客,与朋友们分享观点。那么我相信,一台酷睿服务器,1G内存外加一块160GB的硬盘就足够了。就算服务器出现了一点硬件故障,导致几个小时甚至一两天不能提供访问,生活会照常继续,天也不会塌下来。

4.2如果你的服务器用来作为测试平台,那么就不会如生产环境那样,对可靠性有极高的要求,你所需要的可能只是做好例行的数据备份,服务器宕机后,能有个人在今天把问题解决掉就OK了

4.3如果你是一个电子商务公司,服务器正在运行电子商务网站平台,那么请一定要像重视女朋友一样重视服务器,当硬件发生故障而导致宕机,你需要对以下危言耸听的后果做好心理准备:投诉电话被打爆、顾客大量流失、顾客要求退款、市场推广费用打水漂、员工无事可干,公司运营陷入瘫痪、数据丢失(这是最痛苦最灾难的结果,我们经历了太多这样的案例,它甚至会导致一个公司就此消亡)在这里,我们其实只需要简单讨论你的业务对服务器硬件可靠性的要求。换言之,如果你觉得业务不能承担硬盘损坏带来的停机或数据丢失风险,那么一定要选择一个合适的Raid卡,对于冗余电源问题,道理一样。(全面解决这个问题,不单考虑单个服务器的硬件,还需要结合系统架构的规划设计和运维管理来分析,这部分我们将单独撰写文章来讨论。)

在完成以上问题后,我们接下来就可以决定这些具体选项:

选择什么CPU?

回忆一下上面”服务器运行什么应用?“和“需要支持多少用户访问?”两个问题的答案,这将帮助我们来选择合适的CPU。毫无疑问,CPU的主频越高,其性能也更高两个CPU要比一个CPU来得更爽,至强肯定比酷睿更生猛。但我们究竟需要选择怎样的CPU?我们在这里为你提供一些常见情况下的建议:

(1)如果你的业务刚刚起步,预算不是很充足,建议你选择一款经典酷睿服务器,毕竟51IDC的E5300服务器最便宜只需要450块钱一个月。而且,以后你可以根据业务发展情况,随时升级到更高配置的服务器。

(2)如果你需要在一台服务器同时运行多种应用服务,例如.Net+Exchange+SQLServer,那么一个单路至强(例如X3330)或新一代酷睿I3/I7(双核四线程)将是最佳的选择。虽然从技术角度,这不是一个好主意,但至少能够帮你节约一大笔成本。

(3)如果你的服务器运行SQLServer、MySQL或者Oracle,而且目前有几百个用户同时在线,未来还会不断增长,那么你至少应该选择安装一个E5504(或更高主频)的至强服务器。当半年后负载越来越大的时候,可以选择增加一个CPU。

(4)如果你需要一台游戏服务器,那么我们建议你选择一台单路或双路的至强服务器。需要注意的是,使用双路CPU需要应用程序的支持,如果应用程序本身没有对双路CPU进行代码优化,就不会带来性能的显著提升,而且将造成投资的极大浪费。

需要多大的内存?

同样,”服务器运行什么应用?“和“需要支持多少用户访问?”两个问题的答案,也将帮助我们来选择合适的内存容量。相比于CPU,我们更认为内存(RAM)是影响性能的最关键因素。因为在相当多正在运行的服务器中,我们发现CPU利用率一般都在10%~30%之间,甚至更低。但我们发现由于内存容量不够而导致服务器运行缓慢的案例比比皆是,如果服务器不能分配足够的内存给应用程序,应用程序就需要通过缓慢的硬盘接口来交换读写数据,这将导致网站慢的令人无法接受。内存大小主要取决于服务器的用户数量,当然也和应用软件对内存的最低需求和内存管理机制有关系,所以,最好由你的程序员或软件开发商给你最佳的内存配置建议。我们同样在下面给出了一些常见应用环境下的内存配置建议:

(1)无论是Windows下的`IIS还是Linux下的Apache,一般情况下Web前端服务器不需要配置特别高的内存,尤其是在集群架构中,1GB-2GB就已足够。只有当几千个并发用户,并运行动态脚本的时候,我们才会考虑使用4GB或更高的内存。

(2)对于运行Tomcat、Resin、WebLogic、Websphere或.Net这样的应用服务器,2GB内存应该是基准配置。更准确数字需要根据用户数量和技术架构来确定。

(3)数据库服务器的内存由数据库实例的数量、表大小、索引、用户数来决定,一般建议配置4GB以上的内存,我们甚至在很多的客户案例中使用了24GB到48GB的内存。

(4)诸如Imail、Notes、Exchange这样的邮件服务器对内存的要求也并不高,1GB-2GB就可以满足了。

(5)对于一台文件服务器,1GB内存可能就足够了。

(6)还有一些特殊的服务器,我们需要为之配置尽可能高的内存容量,包括Squid,Varnish这样的缓存服务器,和Memcached Server。事实上,上面的数字已经足够慷慨,由于内存技术的不断进化和价格不断降低,我们才得以近乎奢侈的讨论4G、8G、16GB这些曾经不可想象的内存容量。早在2000年的时候,我面对的大多数服务器都是256MB、512MB内存,1GB已经算是高配,而那时同样也需要满足大量用户的访问。所以,除了花钱购买内存来满足应用程序的贪婪之外,系统优化和内存管理仍然是我们需要重视的问题。需要怎样的硬盘存储系统?硬盘存储系统的选择和配置是整个服务器系统里最为复杂的一部分,我们需要考虑硬盘的数量、容量、接口类型、转速、缓存大小,以及是否需要Raid卡,Raid卡的型号和Raid级别等问题。甚至在一些高可靠性高性能的应用环境中,我们还需要考虑使用怎样的外部存储系统(SAN、NAS或DAS)。

网卡的问题：

如果你的基础架构是多服务器环境,而且服务器之间有大量的数据交换,那么我们建议你为每台服务器配置两个或更多的网卡,一个用来对外提供服务,另一个用来做内部数据交换。如果你对安全的要求特别高,我们甚至可以单独安装一个用于系统管理和日常维护的网卡。至于网卡端口的速率问题,这主要取决于你对带宽流量的评估。大多数情况下,百兆网卡足够用来对外提供服务,而内部数据交换建议使用千兆网卡。但话说回来,除了经典酷睿服务器之外,我们现在很难找到百兆接口的服务器主板了。还有一种情况需要注意,如果你选择51IDC的数据备份服务(Managed Backup Service),则需要一块单独的网卡连接到专有的数据备份网络中,进行每天的数据备份,这会带来几个好处:不会占用宝贵的外网带宽、保证数据传输的安全、提供快速的数据备份速度。我们非常希望这篇文章能够帮助你为服务器选择合适的硬件配置,如果你阅读后发现有不正确的地方,请在评论中指出来,我们会及时更新并感谢你的热情指正。

作者：关开发

一.什么是前后端分离？

理解前后端分离大概可以从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文件（index.html）被下载到浏览器，接着下载html里面引用的css，js。

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

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

2.2 服务端渲染

服务端渲染的方案指的是数据绑定，渲染等工作都放在服务端完成，服务端向浏览器输出最终的html。大家看完这个是不是有个疑问，这不是又回到了前后端不分离的时代了吗？答案是否定的，因为这里的服务端是用来执行前端数据绑定、渲染的，也就是把浏览器的一部分工作分担到了服务端。而目前具备这只种能力的服务端是NodeJs服务端。

它的原理其实就是在浏览器与前端代码中间插入了一个NodeJs服务端。浏览器请求前端页面时，会先经过NodeJS服务端，由NodeJs去读取前端页面，并执行异步后端API，获取到数据后进行页面数据绑定，渲染等工作，完成一个最终的html然后返回浏览器，最后浏览器进行展示。

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

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

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

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

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

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

PS：其实本质就是把前端编写成一个nodeJs的服务端web应用。实施服务端渲染后，我们最终运行的是一个Nodejs服务端应用。而单页面应用是把静态页面部署到静态资源服务器进行运行。

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

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

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

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

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

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

请注意，截至目前，Google 和 Bing 可以很好对同步 JavaScript 应用程序进行索引。在这里，同步是关键。如果你的应用程序初始展示 loading 菊花图，然后通过 Ajax 获取内容，抓取工具并不会等待异步完成后再行抓取页面内容。也就是说，如果 SEO 对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。

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

无需等待所有的 JavaScript 都完成下载并执行，才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面。通常可以产生更好的用户体验，并且对于那些「内容到达时间(time-to-content) 与转化率直接相关」的应用程序而言，服务器端渲染 (SSR) 至关重要。

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

· 开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数 (lifecycle hook) 中使用；一些外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应用程序中运行。

· 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境。

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

以vue为例，实施服务端渲染可以查看官方指南： https://ssr.vuejs.org ，或选择Nuxt.js

2.4 预渲染技术

如果你调研服务器端渲染 (SSR) 只是用来改善少数营销页面（例如 /, /about, /contact 等）的 SEO，那么你可能需要预渲染。无需使用 web 服务器实时动态编译 HTML，而是使用预渲染方式，在构建时 (build time) 简单地生成针对特定路由的静态 HTML 文件。优点是设置预渲染更简单，并可以将你的前端作为一个完全静态的站点。

如果你使用 webpack，你可以使用 prerender-spa-plugin 轻松地添加预渲染。它已经被 Vue 应用程序广泛测试 - 事实上，作者是 Vue 核心团队的成员。

prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin

三、前后端分离技术选型

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

- vue全家桶（推荐）

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

在 Application Virtualization Server Management Console 中创建服务器组之后，可以使用以下过程向该组中添加服务器。注意 服务器组中的所有服务器必须连接到相同的数据存储。

如果您有一个数据库的使用频率非常高，而且由于这些数据库经常发出更新请求而导致群集复制器过载的话，您需要考虑使用多个群集复制器。在一个服务器中运行多个群集复制器，可以同时将新的更改复制到其它服务器中。

如果一个群集复制器在把更改复制到一个数据库时太忙，会有另外一个群集复制器把更改复制到其它的服务器。这样，通过共同分担复制负荷的方式，多个群集复制器使得数据得到快速的更新并能严格的保持同步。

---