服务器与系统架构的一点理解

掐指一算，距离上次写东西已经是几个月前了，并不是人懒，而是四月份入职了新公司，也算是互联网界有头有脸的企业了。这段时间一直在熟悉业务和技术架构，时间非常紧张，今天刚好想起来，整理了一下思路，介绍一下当前公司的服务器和系统基础架构技术（不涉密），也算是这段时间的一个小的技术总结了。

1.服务器架构

服务器架构图

• 1.服务器分为两种状态：【在线】和【冷备】。顾名思义，前者指正在生产环境投入使用的服务器，后者指作为备机待命的服务器，用以保证在不测之时也不至于让线上服务宕机；

• 2.使用nginx作为负载均衡服务器，使用Apache业务服务器，每台服务器各自拥有自己的冷备服务器；

• 3.由于【PDF转换】业务会在执行过程中占用大量资源（内存和CPU），故为其单独开设服务器；

• 4.静态文件、高频服务及核心业务的服务器各自独立，一方面避免资源挤占造成业务灾难，另一方面便于针对业务特性进行个性化的定制和优化；

• 5.数据库服务使用独立的服务器集群，便于权限管理、日志记录、问题追踪、个性化定制、定向优化；

• 6.涉及文件的服务（如安装包下载、静态文件存取等），使用独立的服务器，因为峰期大文件的频繁IO会占用大量的内存，我们可以针对这一特性进行优化；

• 7.使用ELK（Elasticsearch , Logstash, Kibana）作为日志分析的载体，这个平台功能很强大，目前还不是很熟悉，考虑日后另开研究（挖坑 x 1）；

• 8.使用TCP\长链接的服务使用独立服务器，因为这类服务追求链接的稳定性与可靠性，需要尽量避免其他进程对其产生干扰；

2.系统架构

系统架构图

• 1.网关Apache均衡策略：相同IP优先访问相同服务器；

• 2.部门内Nginx均衡策略：根据服务器状态随机分发；

• 3.nginx负责调用php-fpm和php-cli，apache负责调用php CGI。这种架构实现了动静分离，nginx负责静态内容，apache负责动态内容，算是各取所长了；

• 4.供内部使用的管理平台，由于来源可控，直接绕过外层网关与服务分发，进行业务交互，同时限制了外部网络无法访问该管理平台，也算是一种变相的权限控制；

• 5.说出来你可能不信，Redis、MySQL和MongoDB都是作为缓存在使用，并不作为可靠的持久化存储，这是出于对数据库特性的考虑，下面细说；

• 6.真正做持久化存储的数据库是PostgreSQL，主要是出于兼容性、稳定性、抗灾能力、易于优化等等特性，优点很多，但是上手比MySQL或Mongo较难，考虑另开文章说明（挖坑 x 2）；

• 7.使用Redis作为缓存，具体不多说了，用途都大同小异。当某项数据量过多（多于数十万）时，使用MySQL存储该数据。此类数据大多为脚本跑出来的临时数据，并不是原始数据，用于在某些业务场景下需要满足该业务需求、但是使用Redis存储的话数据量又过多的情况。结合分表处理，用以提升程序在SQL上的效率，同时避免重度依赖作为持久化存储体的PgSQL，缓解PgSQL的压力；

• 8.使用MongoDB的情形与MySQL差不多，区别是用Mongo存储一些非关系型的数据，如评论等；

• 9.同时使用这四个存储服务，依照各自的特性各行其职，一方面便于开发，另一方面最大限度的优化程序的效率；

• 10.PgSQL主库与同步环境的区别在于，主库只能访问备份库和同步环境，用以持久化存储数据信息，同步环境则可以拥有访问高频库（加工库）、备份库（共享、开发、质检、预发布数据库）和集群的权限。这样把主库和同步环境的权限分离出来，避免一些误操作或者灾难对主库保存的数据源造成影响，算是一种容灾策略；

• 11.PgSQL中的库表做读写分离，Mongo和MySQL做Master-slave；

• 12.由于最初redis只用了一台服务器，但是实际业务是重度以来redis做缓存的，所以出现过业务高峰、代码不规范或redis使用过于随意等原因，把redis打挂了的情况，所以使用了codis做了redis集群，极大的缓解了对redis的压力。codis作为redis的分布式解决方案非常实用且有效，考虑日后另行介绍（挖坑 x 3）；

• 13.将涉及用户信息存储/身份校验的服务独立出来，通过外部服务的形式整合到业务中，整个业务系统不涉及对用户身份的干预。一方面可以使用各种复杂的安全策略来验证和校验用户信息而不影响原有的业务逻辑，另一方面由于用户信息属于涉密敏感信息，实现了用户信息的对内保密；