下载掌阅APP，畅读海量书库
立即打开
众所周知，架构会随着业务场景而变化，而传统架构单一，无分层概念，模块之间耦合性过高，导致稳定性和扩展性较差，无法满足互联网高速迭代变化的需求。同时，技术架构也会发生很大变化。不同业务系统侧重点不同，例如“百度”侧重于搜索。当系统庞大后，后续会被拆分为多个子系统，部署在不同服务器上，各子系统相互协作，实现业务功能完整性。
以Web为例，搭建电商平台，最初传统结构是单体架构，如图1-1所示。
图1-1 电商整体业务耦合结构图
注意
电商系统用户、商品、订单模块耦合在一块，无分层概念，部署在同一个服务器，为用户提供服务。
如图1-1所示，将应用和数据库部署在一起，一个简单的应用就搭建完成了。随着后续业务的拓展，系统慢慢变得庞大臃肿，此时需要进行优化。优化的方案如下。
1）增加单机的硬件设备，如处理器\内存\磁盘。
2）用物理机替换虚拟机。
3）增加服务器数量。
4）应用和数据库分离。
以上4种方案的优缺点如下。
1）增加服务器硬件设备资源，短时间内可以提高性能，但会留下隐患。
2）虚拟机的配置、性能不如物理机，但物理机费用高昂且不能治本。
3）增加服务器数量后需要做负载均衡才能充分利用资源，但会额外增加技术难度。
4）应用和数据库分离，分为Web服务器和数据库服务器，这样不仅可以提高单机负载，也能提高HA高可用性。
这里采用方案4，分离应用和数据库，结构图如图1-2所示。
图1-2 电商应用和数据库分离结构图
注意
当应用和数据库分别部署在不同服务器上时，应用所处服务器和数据库所处服务器要能正常ping通及访问，即应用可访问数据库获取数据且正常返回。
如图1-2所示，以上结构将应用和数据库分开单独部署，提高了单机负载以及服务器资源利用率，但若后续用户流量继续上涨，会存在安全风险（单机宕机后不能继续提供服务），需提供应用服务备份，结构图如图1-3所示。
图1-3 电商应用主/备结构图
注意
外部流量都是到达主Web服务器，备Web服务器只在主Web服务器出现单点故障时使用，是维持业务正常访问的一种措施。
如图1-3所示，利用应用服务器预防单点故障，可以有效预防因服务器发生故障而不能及时访问的情况。由于外部流量都是访问“主Web服务器”，单台服务器处理能力出现瓶颈时，可以把流量平摊到Web服务器集群的每台服务器中去，提高服务器资源整体利用率。
注意
服务器集群是由多台服务器共同组成的一个虚拟体，对于调用方而言，它是一个大的虚拟集群，而代理服务器中存在多种策略，这里把流量平摊到Web服务器集群的每台服务器中时采用了“轮询”策略。常用策略如下。
采用“轮询”策略将流量分发到主/备服务器，如图1-4所示。
图1-4 电商应用主/备负载均衡结构图
注意
外部流量通过代理服务器Nginx负载均衡分发到主/备服务器上，代理服务器需要ping通且正常访问应用服务器，以防止因网络故障导致不能正常分发流量的情况出现。
如图1-4所示，该结构解决了应用层面服务器单点风险并提高了服务器负载利用率，但数据库层面存在单点风险和连接数瓶颈，故采用“主/从”方式搭配“哨兵”模式进行搭建，如图1-5所示。
图1-5 电商应用/数据库（主/备负载均衡）结构图
注意
应用服务器和数据库之间要ping通且正常访问，主数据库需要同步数据至从数据库，主数据库和从数据库之间也要ping通且正常访问，主数据库用于“写”操作，从数据库用于“读”操作，应用服务器通过“虚拟IP”连接数据库，主从数据库通过“哨兵”控件监控。当主服务器故障宕机时，从服务器会自动切换成主服务器并切换虚拟IP，应用无须改动，虚拟IP会映射成数据库真实的IP，提供读写功能。
到此，应用服务器和数据库都存在多节点，可以合理利用服务器资源，并避免单机风险。