简介服务器知识介绍是一份面向网络运维入门者、计算机专业学生及中小型企业IT人员的文档资料系统梳理服务器的定义、发展由来、硬件特性与常见操作系统帮助读者理解服务器在C/S网络中的核心角色以及“四性”可用性、可利用性、可扩展性、可管理性的具体含义。资源包内仅包含1个PPT文件大小约707KB属于轻量级知识讲解型文档便于快速通读与课堂培训使用。目前已有182人学习适合用作网络基础课程辅助材料或企业内部分享的入门课件。PPT结合日常PC与专用服务器的对比从可用性强调7×24小时不间断运行从可利用性说明SMP多处理器与高速内存的配置思路再从可扩展性和可管理性介绍冗余、备份与远程诊断等设计能够帮助读者建立服务器选型与维护的基本判断框架为后续深入学习Windows Server、Linux等服务器操作系统打下基础。1. 服务器不是一台大号台式机从买来能干吗开始网盘里躺着一份《服务器知识介绍.ppt》的时候大多数人第一反应是这玩意儿到底和家里那台台式机差在哪这个问题的答案直接决定你要不要买、买多贵、后面运维怎么干。PPT 里往往只讲 CPU 几核、内存多大、磁盘多快而我拿到一台服务器先问的不是参数而是它要在哪儿扛活。本文就按我实际接触服务器的顺序来讲先判断选型和需求再装系统、开远程、踩坑排错最后把日志和时间同步这种看不见的功夫补上。适合刚接到服务器任务的运维新人、准备自建服务的开发者也想给手头旧机器找一条活路的人。2. 选硬件还是选云几核CPU、多少内存、磁盘阵列等级怎么定2.1 核数、主频、内存服务器性能参数的认知顺序PPT 上最喜欢罗列一串参数双路至强、64G 内存、8 块 2.4T SAS 硬盘。这些数字单独看都没意义因为性能瓶颈从来不是参数表里最显眼的那个数字。我一般先把业务量换算成负载一个日请求量十万级的 Web 应用4 核 8G 起步没有问题但你要是把数据库也放在同一台机器上内存建议直接给到 16G 以上——数据库才是吃内存的大户CPU 反而容易闲着。选择服务器配置我建议按下面的顺序看参数。关注顺序参数项判断依据1内存容量Swap 一旦启动整机响应立刻变差内存宁大勿小2磁盘类型与 IO数据库和日志类的随机读写SSD 和机械盘是两种体验3网络带宽公网业务看带宽峰值内网业务看网卡吞吐4CPU 核心数多核适合并发单核性能影响单线程应用延迟5主频与缓存对计算型任务有影响对普通 Web 业务影响很小这个顺序背后的逻辑很简单服务器上最贵的是不可用的代价而内存和磁盘 IO 恰恰是让系统变卡的第一现场。别一上来就追核数和主频预算有限时优先保内存和 SSD。如果你拿到的是一台旧台式机改装的家用服务器内存往往只有 8G那就老老实实把它当轻量应用服务器用别硬塞虚拟机玩集群跑起来之后 swap 狂转连 SSH 都敲不动。2.2 RAID 等级的选择数据安全不是靠感觉服务器磁盘阵列是服务器知识里绕不开的一块。RAID 的本质是把多块物理盘包装成一个逻辑盘用容量换冗余或用冗余换速度。家用台式机为什么很少有 RAID因为主板上的接口和芯片组不支持或者只支持最基础的软阵列。而服务器主板和阵列卡是标配这也是它和台式机最本质的差距。常见等级就四个别被厂商宣传绕晕RAID 等级最少磁盘数可用容量冗余能力适合场景RAID 02100%无坏一块全没缓存、临时数据RAID 1250%坏一块不丢系统盘、数据库日志RAID 53(n-1)/n坏一块可重建文件服务器、冷数据RAID 10450%每组坏一块不丢数据库、生产应用我一般给新手的建议是没搞明白需求之前系统盘用 RAID 1数据盘用 RAID 10RAID 5 写性能一般而且重建时间越长风险越大。磁盘阵列的具体操作常见做法是开机按阵列卡提示进配置界面创建 Virtual Disk把热备盘指定好再退出重启装系统。比如戴尔服务器热搜里的 Dell R740 这类增加硬盘时新盘如果之前在别的机器上用过阵列卡会识别到外来配置需要先进配置界面导入或清除否则装系统时根本不认盘。国产整机比如五舟服务器的操作路径不同但逻辑一样先让阵列卡认盘再谈分区。2.3 从五舟、Dell R740 到云主机采购和部署路径对比很多人纠结自建整机还是云主机我给三种路径拉了张直白的对比表。路径优点缺点典型用途自购整机五舟等国产品牌成本可控、硬件可扩展需要机房环境、出问题自己扛内网业务、数据量大的存储品牌服务器Dell 等有保修、BMC 带外管理好用贵采购周期长生产环境、核心数据库云服务器阿里云等分钟级交付、快照方便长期成本高、带宽贵公网业务、弹性伸缩服务器虚拟化和服务器集群是 PPT 里最爱画大饼的两个词但实际落地逻辑很简单虚拟化是为了把一台物理机拆成多台隔离的虚拟机集群是为了让应用挂在一台机器上时不死。新手别一上来就搭集群先把单机搞稳定。热搜里家里电脑当服务器可以部署小程序吗——可以用内网穿透类工具把端口映射出去就能跑通 demo但生产环境我还是建议云主机原因只有一个快照。本地机器坏了盘数据恢复费用远超一台云主机云上几分钟就能回滚到故障前的状态。至于免费云服务器当学习环境没问题拿来跑生产的坑后面会说到。3. Linux系统安装与初始化分区、交换分区和SSH加固3.1 安装前的分区策略拿到一台裸机或刚开通的云主机第一步不是急着敲命令而是定分区策略。这一步决定你半年后磁盘满的时候还有没有后悔药。我常用的分区方案很朴素/boot单独分 1G/给 20-50G/var单独分出来留给日志和缓存/home单独分剩余空间全部交给 LVM 留作扩展。这样做的原因是日志能把磁盘写满如果/var和/混在一起系统一满连 SSH 都登不上分开了顶多服务报错还能通过清日志救回来。数据库服务器还要额外注意swap分区的大小。老的教科书说 swap 是内存两倍那是物理内存只有 2G 时代的做法。现在物理内存普遍 16G 往上swap 给 4-8G 就够它的作用只是防止内存瞬间打满时进程被系统直接杀掉而不是用来长期顶着跑。装完系统后你可以用free -h和lsblk看一眼实际布局# 查看内存和 swap 使用情况 free -h # 查看磁盘分区和挂载点 lsblk -o NAME,SIZE,TYPE,MOUNTPOINTfree -h里的-h参数表示以人类可读的单位输出重点看Swap行的总量lsblk的-o参数指定要显示的列MOUNTPOINT是关键的挂载点信息。如果发现某个分区没有独立挂载而你又要跑数据库或日志量大的应用趁数据量还小的时候重新分区越晚越难迁移。3.2 系统装完后的初始化脚本系统装完第一件事永远是加固 SSH 和装基础工具。我习惯把初始化动作写成一个脚本每台新机器跑一遍省得手敲漏掉。下面是一个适用于 Debian/Ubuntu 系的最小初始化脚本CentOS 系要用yum替换apt#!/usr/bin/env bash set -euo pipefail # 1. 更新软件源并安装基础工具 apt update apt install -y vim curl wget htop ufw fail2ban # 2. 创建普通用户并加入 wheel 组 useradd -m -s /bin/bash deploy echo deploy ALL(ALL) NOPASSWD:ALL /etc/sudoers.d/deploy mkdir -p /home/deploy/.ssh chmod 700 /home/deploy/.ssh # 3. 配置 SSH禁止 root 登录修改端口只允许密钥认证 sed -i s/^#Port 22/Port 2222/ /etc/ssh/sshd_config sed -i s/^#PermitRootLogin prohibit-password/PermitRootLogin no/ /etc/ssh/sshd_config sed -i s/^#PasswordAuthentication yes/PasswordAuthentication no/ /etc/ssh/sshd_config systemctl restart sshd # 4. 启用防火墙默认拒绝外部访问只放行 SSH 端口 ufw default deny incoming ufw allow 2222/tcp ufw --force enable这段脚本每一步都有明确目的。第一步装fail2ban是防止 SSH 被暴力扫描第二步创建deploy用户而不是直接用 root 干活哪怕密钥泄露也只是普通用户权限第三步把 SSH 改到 2222 端口并禁用密码登录能直接过滤掉九成以上的自动化攻击。改端口前先确认你本地机器能连上 2222否则改完发现自己被拒之门外就尴尬了。第四步用 ufw 做默认拒绝注意先放行新 SSH 端口再启用防火墙顺序反了界面直接失联。3.3 调整服务器时区云主机和海外机房机器最常出现的诡异问题就是时间对不上这其实不是服务器坏了而是时区没设。国内业务要把时区统一成北京时间# 查看当前时间和时区 timedatectl # 设置时区为北京时间Asia/Shanghai timedatectl set-timezone Asia/ShanghaiLinux 系统时间分两部分硬件时钟和系统时钟。timedatectl显示的就是系统时钟与时区的合成结果。如果执行完命令后应用日志还是差 8 小时问题大概率出在应用或数据库读取的是UTC时间而不是系统时区。这时一方面检查timedatectl输出的Local time和Universal time另一方面确认你的 Java、Python、MySQL 进程有没有自带时区配置。服务器时区是最典型的看着简单、坑在后面的项目我吃过一次亏日志时间全是 UTC排查线上问题总比用户迟 8 小时后来才想起来是装系统时选错时区这种小事折腾了一天才定位到。4. 远程管理落地SSH连接、SFTP传输与Windows服务器替代4.1 SSH连接的正确姿势装完系统后你面对一台没有显示器的机器SSH 就是唯一的手。我见过太多人直接用rootIP密码登录然后被暴力破解脚本盯上。正确的连接姿势是密钥对 config 文件。先在本地生成密钥# 本地机器执行生成 ed25519 密钥对 ssh-keygen -t ed25519 -C your_email_or_nickname # 把公钥推到服务器服务器上首次连接时会提示确认指纹 ssh-copy-id -p 2222 deployyour_server_ip-t ed25519指定密钥类型为 ed25519比传统的 RSA 更安全且长度短-C是注释方便你认出这把钥匙是谁的。ssh-copy-id会自动把公钥追加到服务器的~/.ssh/authorized_keys不需要手动编辑。之后在本地新建~/.ssh/config把连接参数固化下来Host myserver HostName your_server_ip Port 2222 User deploy IdentityFile ~/.ssh/id_ed25519配置好后直接ssh myserver就能连接。VSCode 的 Remote-SSH 连远程服务器也是读这个 config你只要在扩展设置里选中这份配置文件就能在编辑器里直接改服务器代码日志也能实时看。首次连接时出现指纹确认提示一定要核对如果以前连过但提示指纹变了说明服务器重装了系统或有人动了 SSH 密钥别急着输入yes先确认是不是自己干的。4.2 SFTP与数据传输服务器之间搬文件最常见的两张牌是scp和rsync。单文件用scp简单直接但目录同步、断点续传、增量备份必须用rsync。我每次同步代码或备份数据库都走 rsync# 把本地目录同步到服务器-a 保留属性-v 输出过程-z 传输时压缩 rsync -avz --progress --exclude .git --exclude node_modules \ ./myapp deploymyserver:/home/deploy/apps/ # 从服务器拉取文件到本地--delete 表示把本地多余文件删掉 rsync -avz --delete --exclude *.log \ deploymyserver:/home/deploy/apps/data/ ./backup/-a归档模式保留权限和时间戳-z压缩适合文本文件--exclude排除大目录能省大量时间第二行里的--delete是本地的后悔药——它会保证目标目录和源目录完全一致但如果写错路径后果很严重。所以我的习惯是第一次先用--dry-run跑一遍看看它要删什么rsync -avz --delete --dry-run deploymyserver:/home/deploy/apps/data/ ./backup/--dry-run只输出将要执行的操作不实际改动文件。这个参数我用过几百次一次误删都没发生过强烈建议你在任何带--delete的命令前先试运行。4.3 Windows服务器的远程桌面替代Windows Server 的远程桌面默认监听 3389 端口把它直接暴露到公网是运维事故的高发区——扫描器一分钟能扫十几个网段弱口令撑不过一晚上。我处理这类需求的标准做法RDP 只允许内网访问并通过自建跳板机连接。常见做法是用 RustDesk 这类开源远程桌面套件自建服务只在内网部署办公网和机房之间用它中转不开任何公网映射。同时用防火墙把 3389 钉死在内网网段# 在 Windows 防火墙高级设置里新建入站规则仅允许来源地址为办公网段 # 远程桌面 - 属性 - 作用域 - 远程 IP 地址 - 添加指定 IP 范围 # 例如 192.168.1.0/24其余来源一律拒绝如果你已经有一台 Linux 跳板机更通用的做法是ssh -L做端口转发公网 SSH 到跳板机把远程的 3389 映射到本地空白端口再用远程桌面客户端连接本机端口。这样公网上根本看不到 3389攻击面只剩 SSH 一个入口配合第 3 章的 fail2ban基本没人能摸进来。Windows 服务器上如果同时开了 IIS 和 SQL Server还要注意服务账号和防火墙端口的配置IIS 调用另一台服务器数据库时往往不是 SQL 连不上而是防火墙没放行 1433 端口这类跨服务器调用问题优先查防火墙而不是查数据库权限。5. 服务器运维避坑连接失败、时区错乱和敏感信息泄漏5.1 现象远程连接突然失败某天早上到办公室SSH 连不上网页也打不开机房面板上机器还亮着。原因最常见的不是系统挂了而是三件事——DHCP 租约到期导致 IP 变了、SSH 端口被防火墙策略误拦、机器进入奇怪的待机状态。解决服务器必须使用静态 IP这在装系统阶段就要配好如果已经进不去系统走带外管理BMC/IPMI看控制台。戴尔服务器有 iDRAC国产整机也几乎都有类似的管理网口。这个教训是我的血泪经验一台五舟服务器用 DHCP 跑了半年一次机房网络重构后 IP 换了我是在机房现场接键盘才知道新地址。5.2 现象应用日志时间总是差8小时业务方说用户凌晨 1 点的订单日志时间不对你查服务器date明明是对的。原因应用容器比如 Java 的 JVM默认使用 UTC 时区或者数据库连接串里没指定时区。系统时区只是第一层应用层才是真正的黑匣子。解决先去timedatectl确认系统层面正常再改应用启动参数。Java 加-Duser.timezoneAsia/ShanghaiMySQL 连接串加serverTimezoneAsia/ShanghaiPython 程序用os.environ[TZ] Asia/Shanghai。注意改完需要重启进程光改配置文件不重启没用。最好把时区检查和时钟同步写进服务器巡检脚本开机自动执行一次。5.3 现象400错误页面把服务器信息暴露给用户访问一个 Nginx 站点的非法请求路径浏览器直接返回一页写着nginx/1.18.0 (Ubuntu)的 400 错误页。原因默认错误页把 Web 服务器软件名和版本亮给外界了攻击者可以用这些信息去匹配已知漏洞库等于把家门钥匙挂在门上。解决关闭版本号显示并自定义错误页。Nginx 配置里加server_tokens off;Tomcat 在server.xml关掉Server头再自定义 400/403/404/502 的返回页面。热搜里的400错误返回了服务器信息就是这个场景。这也是 web 服务器安全里最不起眼但又最常见的一类漏洞我每次上线前都会拿 curl 探一遍错误码确认没有服务端指纹信息。5.4 现象pgAdmin4报无法连接服务器本地 pgAdmin4 连数据库报无法连接服务器服务器上psql又能正常查数据。原因三大嫌疑依次是listen_addresses没放开、pg_hba.conf认证方式不对、防火墙没放行 5432 端口。默认安装的 PostgreSQL 只监听 localhost这是安全设计但很多人不知道要改。解决编辑/etc/postgresql/*/main/postgresql.conf和pg_hba.conf# 查看 PostgreSQL 实际监听的地址 ss -tlnp | grep 5432 # 修改 postgresql.conf允许所有网卡监听 # listen_addresses * # 修改 pg_hba.conf允许特定网段用密码认证 # host all all 192.168.0.0/16 md5改完记得重启数据库服务。ss -tlnp如果输出127.0.0.1:5432说明监听没放开如果监听是*:5432但仍然连不上那就去查防火墙和 pg_hba。这个排查顺序我固定在每次数据库连不上的第一课至少省一半时间。6. 运维界的后悔药日志、时间同步与自启动服务6.1 日志排查三板斧服务器出了问题第一反应不是重装系统而是看日志。systemd 系统的服务日志和内核日志全在 journald 里# 查看某个服务最近 1 小时日志并持续跟踪 journalctl -u myapp --since 1 hour ago -f # 查看最近的系统启动日志重点看有没有磁盘或网络报错 journalctl -b # Nginx 之类的传统日志直接 tail配合 awk 统计 5xx 数量 tail -f /var/log/nginx/access.log | awk {print $9} | sort | uniq -c这三个命令覆盖了 80% 的排障场景-u指定服务单元-b表示本次启动-f是 follow 模式。日志是运维的后悔药——你永远找不到比日志更忠实的目击者。开源的服务器维护软件很多我的建议是先不用大而全的监控平台把 journald 和/var/log看明白再说。6.2 国内时间服务器与 chrony 配置服务器时区设对了日期还会慢慢漂移机械盘机器一天漂几秒很正常。生产环境要做时间同步现代 Linux 默认走 chrony配置国内时间服务器比默认源延迟更低更稳# 编辑 /etc/chrony/chrony.conf替换或追加以下服务器配置 pool ntp.aliyun.com iburst pool ntp.tencent.com iburst # 重启服务并验证同步状态 systemctl restart chrony chronyc sources -vpool关键字不要求固定单个服务器可用整组源iburst让首次同步快速完成。chronyc sources -v输出的^*表示当前已同步长时间停在^-说明源不可达。时间服务器是基础设施里的隐形核心证书校验、日志时间戳、分布式系统的一致性全都依赖它。6.3 systemd 自启动服务服务器重启后服务没有自动恢复这是运维事故的高频来源。把所有业务进程交给 systemd 管理重启机器后才能自愈。一个最小服务单元长这样# /etc/systemd/system/myapp.service [Unit] DescriptionMy Application Server Afternetwork-online.target [Service] Userdeploy WorkingDirectory/home/deploy/apps/myapp ExecStart/usr/bin/python3 /home/deploy/apps/myapp/main.py Restarton-failure RestartSec3 [Install] WantedBymulti-user.targetAfternetwork-online.target保证网络就绪后再启动避免启动瞬间抢不到数据库连接Restarton-failure让进程崩溃后 3 秒自动拉起WantedBy决定开机启动。写完执行systemctl daemon-reload和systemctl enable --now myapp生效。我的习惯是每个服务都预留 systemd 单元而不是用裸nohup跑进程这是确保机器重启后业务还活着的最可靠方案。希望这些从选型到排错的笔记能帮到你少走弯路——毕竟服务器的每一条坑都是前人用躺尸换来的。本文还有配套的精品资源点击获取