前言

服务器架构图多以物理视图呈现，物理视图用于描述系统软件到物理硬件的映射关系，反映出系统的组件是如何部署到一组可计算机器节点上，用于指导系统的部署实施过程。受众多为运维和实施人员。

其实服务器架构如何架设完全根据业务场景，数据量或者用户量等因素进行衡量，并没有什么架设方案是一定的，遵循“两利相权取其重”，经过综合考量后，选择最优方案。

以下根据不同场景进行服务器架构架设进行物理视图展示（以下示例均以物理服务器为节点，不考虑虚拟化分割和容器部署情况）。

一、单台服务器

一般在用户量不多，应用使用频率不高，数据量不太大，业务场景相对简单情况下，单台服务器就可以满足使用。也就是一台服务器上只运行应用容器(如tomcat)和数据库，让系统运行起来，用户能通过网络访问即可，单台服务器不存在应用于数据库网络连接问题，因为应用和数据同在一台服务器，完全的"本地"环境；当然应用访问压力和数据负载压力都由一台服务器承担。其实这种完全单台的情况，一般都用于测试环境或者开发环境，再简单的生产环境至少再多一个灾备服务器会显得更优雅。

二、应用、数据服务器分离

如果随着用户量的增长和数据量的增大，应用服务器与数据服务器分离是迈出"分布"的第一步。只需要应用服务器新增一个远程调用数据库服务器的连接，有效的缓解了应用服务器负载的压力。当应用服务器和数据服务器需要通过网络连接时，则有可能由于两个服务器之间网络问题导致数据传输上丢包或者出现数据丢失情况。不过随着网络技术的发展及解决方案的丰富，当数据量或应用访问不太大的情况下，这种担忧完全可以忽略。

三、应用、数据、文件服务器"三剑客"

随着系统使用，当文件越来越多，对应用服务器的硬盘存储也是一个挑战，让文件集中化管理显得很有必要。应用服务器只管访问的事儿，数据服务器只存储应用数据(数据库数据)，而文件服务器对各种静态文件集中管理，同时释放应用服务器存储空间。

至于文件服务器到底是做成一个FTP协议的"专业"文件服务器，还是只是把文件分服务器存储，依然使用http协议，就看业务需要了，不过对于FTP管理、http管理总结了以下对比，FTP:

1、完全基于网络，具有网络文件的上传与下载特性。如支持断点续传，不受工作组与IP地址限制等。

2、拥有完善的用户权限管理系统，比起网络共享来说，可以详细设置每个用户的权限。如只能上传，不能修改或删除等。

3、安全性高，可以进行数据的加密传输。更好保护个人隐私。

与网络共享(http)对比：使用上感觉不如网络共享方便，网络共享的文件可以像本地文件一样使用。而FTP必须是下载下来才能使用。

应用服务器与文件服务器分离优缺点

优点：由于处于两个服务器，可以做到访问的分流，减少应用服务器压力，正常用户访问和文件下载上传不共享一个服务器带宽，做到分带宽，如果在文件和应用都在一个服务器会存在上传下载时候，其它访问很慢。且分开的话文件统一管理比较整洁。

缺点：由于处于两个服务器，涉及到跨域访问问题，需要先把网络传输搞定。两个服务器互相通信时，可能存在网络丢包现象，需要特殊处理。

备注：如果承载多种类型的文件服务器，可以是文档格式，可以是视频，可以是图片，支持各种类型文件，需要开启多种协议，比如：HTTP，FTP，RTSP，RTMP。流媒体协议主要是三种：HTTP、RTSP、RTMP。

四、应用集群，加入负载均衡

对一个应用，利用负载均衡器部署到多台服务器上(未对业务进行拆分)，优化了访问请求在服务器组之间的分配，消除了服务器之间的负载不平衡，从而提高了系统的反应速度与总体性能，当然负载均衡器也可以调整每台服务器负载的权重。同时负载均衡器也可以也可实现故障转移，当一台服务器崩溃时候，把访问转到另外可用服务器上，提高了系统架构的可靠性。

在此阶段，可以在同一服务器下实现动静分离，也就是最初版的前后端分离，用nginx管理并启动前端静态文件工程，tomcat管理后端应用和动态数据。同时一个nginx服务也可以对多个tomcat服务，tomcat服务之间存在负载均衡和故障转移。

负载均衡器的存在提高了架构的扩展性，简化了管理难度。关于负载均衡故障转移有很多内容要讲，多啰嗦几句，负载均衡可大致分为DNS负载均衡，反向代理负载均衡，基于NAT负载均衡，其中反向代理负载均衡使用较广。当然如果单台负载均衡器感觉不够高可用，也可对负载均衡器进行多台部署，做好灾备。

应用集群加入负载均衡后，需要注意几点问题：①单点登录②使用session+cookie维护用户③当一台服务器或者多台服务器崩溃，所有的请求由原来的均衡分布瞬间集中到一台服务器或少数几台服务器，需要用户请求突然集中化的处理机制，防止服务器集中接收过多请求而瘫痪。

五、数据库集群，读写分离

应用服务器负载均衡后，随着流量和数据的增加，数据库服务器遇到瓶颈，需要对数据库实行集群策略，对数据库访问分流。

实行读写分离同时，可以加入数据库本地缓存策略。如果数据库读写分离，需要注意数据同步问题。

六、加入搜索引擎

加入搜索引擎集群后，需要注意索引数据同步问题：实时增量、定时全量等。

七、加入缓存服务器

目前最常用的缓存数据库是redis，一般加入缓存服务，除了分担读数据库的访问压力之外，缓存服务还有数据限流、高速队列、事件发布订阅等效果。加入缓存，主要需要注意的两个问题：缓存穿透与缓存雪崩。

缓存穿透

缓存只是为了缓解数据库压力而添加的一层保护层，当从缓存中查询不到我们需要的数据就要去数据库中查询了。如果被黑客利用，频繁去访问缓存中没有的数据，那么缓存就失去了存在的意义，瞬间所有请求的压力都落在了数据库上，这样会导致数据库连接异常。

缓存雪崩

缓存雪崩是指缓存不可用或者大量缓存由于超时时间相同在同一时间段失效，大量请求直接访问数据库，数据库压力过大导致系统雪崩。

对于缓存相关问题解决方案，网上有很多方法，此处不做描述。到了这一步，服务架构还不算分布式架构，只能算高可用架构。

八、数据库水平拆分、垂直拆分

比如，商品和用户两个数据库原来处于同一个数据服务器，由于数据量不断增长，把商品和用户两个数据库分别放在两个数据库服务器，这种按业务分割业务数据，其实就是垂直拆分。垂直拆分后，要注意不同服务器之间数据关联与同步问题。

如果当商品服务器又达到性能瓶颈，需要对服务器继续扩展，把同样的商品数据库的数据按条件分到扩展服务器上，这种就属于水平拆分。

九、应用服务器垂直拆分

把应用服务器，按业务进行垂直拆分，A业务服务器只负责A业务，B业务服务器只负责B业务，C业务服务器只负责C业务。并对每个业务服务器做好负载及灾备。

例如，按业务拆分的3个服务器的对应三个域名：

urlA.com，urlB.com，urlC.com

根据不同域名请求访问不同服务器，如果涉及到用户需要查询业务A或业务B，直接在用户服务器里写DAO层查询业务A或业务B数据库表。

此步需要注意的问题：业务服务器之间调用问题

十、前后端服务器分离

当服务器访问量继续加大的时候，可添加专门的用于管理前端工程的服务器，为前后端在一个服务器做访问压力分离。至于前端服务器与后端的应用服务器如何关联，则由实际业务场景判断，本文不做描述。至于更多细节，比如CDN服务器等不做描述。

十一、微服务

到此步就不是web应用服务了，应用服务进一步抽离为服务节点，应用服务通过调用服务节点来实现整体系统，不但让系统充分解耦，又可以使服务之间紧密相连。这一步已经属于微服务了，微服务之间的调用和消息是需要注意的重中之重。架构的选择不需要跟随"潮流"，不是因为微服务火就要把所有项目都做成微服务，要充分判断用户受众及用户量之后，再做架构的选择。要让技术为业务做服务，用技术去驱动业务，驱动发展，而不是要让业务给技术让路。

十二、加入数据中心

到这步，应用层已经架构完毕，为实现数据驱动而加入数据中心，实现数据统一管理。让不断增长的数据价值实际落地。