📚 课程目录第2章环境准备与基础组件

环境准备与基础组件：选型、搭建与配置

说实话，做物联网设备注册与身份管理，最怕什么？不是业务逻辑复杂，而是底层组件选错了，后面全得重来。我见过太多团队，项目做到一半发现数据库扛不住并发，或者消息队列丢消息，那叫一个痛苦。

这一章，咱们就把地基打牢。我会把 Python/Go 的选择、PostgreSQL/Redis 的搭配、RabbitMQ/Kafka 的取舍，掰开了讲清楚。每个组件我都会给出搭建命令和配置要点，都是我在生产环境里踩过坑之后沉淀下来的。

开发语言：Python 还是 Go？

这个问题，几乎每个项目启动时都会被问到。我的建议很简单：看团队，看场景。

核心判断标准：如果你的团队 Python 经验丰富，且对性能要求不是极致敏感，选 Python 快速出活。如果你要做高并发网关、边缘节点，或者对内存占用敏感，Go 是更稳妥的选择。

我个人习惯用 Python 做原型验证，用 Go 做核心服务。举个例子，设备注册的 REST API 我用 Go 写，因为要扛每秒几千个请求；而设备证书的签发脚本我用 Python，因为依赖库丰富，写起来快。

维度	Python	Go
开发效率	高，生态丰富	中等，但编译检查严格
并发模型	GIL 限制，需多进程/异步	原生 goroutine，轻量高效
部署复杂度	需解释器，依赖管理麻烦	单二进制，部署简单
适用场景	管理后台、脚本、原型	API 网关、核心服务、边缘计算

我的经验：在设备注册系统中，身份验证和 Token 签发这两个模块，我建议用 Go 写。原因很简单——这两个接口的延迟直接决定了用户体验，Go 的 goroutine 能让你轻松应对突发流量。

数据库选型：PostgreSQL + Redis 组合拳

设备注册系统，说白了就是管三样东西：设备信息、身份凭证、操作日志。这三样东西对数据库的要求完全不同。

PostgreSQL 用来存设备元数据、证书信息、用户账号。为什么选它？因为设备信息里经常有 JSON 字段（比如设备属性、扩展配置），PG 的 JSONB 类型用起来太顺手了。我在项目中遇到过，用 MySQL 存 JSON 字段，查询性能差得离谱，换了 PG 之后，同样的查询快了 10 倍。

Redis 用来缓存 Token、设备会话、限流计数器。说白了，身份验证的每一次请求都要查 Token，这个频率用 PG 扛不住，必须上缓存。

注意：不要把设备注册的持久化数据放在 Redis 里。Redis 是内存数据库，重启丢数据是常态。我见过有人把设备证书直接放 Redis，结果一次宕机，所有设备都得重新注册——那场面，简直灾难。

PostgreSQL 搭建与配置

搭建其实很简单，但配置有讲究。我直接给生产级别的配置要点：

# 安装（Ubuntu 22.04）
sudo apt update
sudo apt install postgresql-14

# 创建数据库和用户
sudo -u postgres psql
CREATE DATABASE device_registry;
CREATE USER iot_admin WITH PASSWORD 'your_strong_password';
GRANT ALL PRIVILEGES ON DATABASE device_registry TO iot_admin;

# 关键配置（/etc/postgresql/14/main/postgresql.conf）
listen_addresses = '*'          # 允许远程连接
max_connections = 500           # 根据设备量调整
shared_buffers = 1GB            # 物理内存的 25%
work_mem = 64MB                 # 排序和哈希操作内存
effective_cache_size = 3GB      # 操作系统缓存估算

避坑指南：我曾经把 max_connections 设成 2000，结果内存直接爆了。PostgreSQL 每个连接大约占用 10MB 内存，算清楚再设。一般设备注册系统，500 连接足够用，配合连接池（比如 PgBouncer）效果更好。

Redis 搭建与配置

Redis 的搭建更轻量，但配置里有个坑——持久化策略。我建议用 RDB + AOF 混合模式。

# 安装
sudo apt install redis-server

# 配置（/etc/redis/redis.conf）
bind 0.0.0.0                    # 监听所有接口
port 6379
requirepass your_redis_password  # 必须设置密码！
maxmemory 2gb                    # 限制最大内存
maxmemory-policy allkeys-lru     # 内存满时淘汰策略
appendonly yes                   # 开启 AOF 持久化
appendfsync everysec             # 每秒同步一次

安全提醒：Redis 默认没有密码，而且监听所有接口。我见过有人把 Redis 直接暴露在公网上，结果被挖矿程序扫到，数据全被删了。务必设置密码，并且用防火墙限制访问来源。

消息队列：RabbitMQ vs Kafka

设备注册系统里，消息队列用来做什么？设备上线通知、证书到期提醒、注册事件广播。说白了，就是解耦。

选 RabbitMQ 还是 Kafka？我直接给结论：

RabbitMQ：适合消息路由复杂、需要灵活确认机制的场景。比如设备注册成功后，需要同时通知多个服务（日志、监控、通知），用 RabbitMQ 的 Topic Exchange 非常方便。
Kafka：适合高吞吐、日志型数据、需要消息回溯的场景。比如设备注册事件的审计日志，用 Kafka 可以保留一段时间，方便事后排查。

对比维度	RabbitMQ	Kafka
吞吐量	万级/秒	百万级/秒
消息确认	支持，精确投递	At-least-once，需自行去重
路由灵活性	高（多种 Exchange）	低（仅 Topic）
消息保留	消费后删除	可配置保留时间
运维复杂度	低	高（需 Zookeeper）

我个人习惯：设备注册的核心流程用 RabbitMQ，因为需要精确的投递确认；审计日志和监控数据走 Kafka，因为量大且允许少量丢失。

RabbitMQ 搭建与配置

# 安装（Ubuntu 22.04）
sudo apt install rabbitmq-server

# 启用管理插件
sudo rabbitmq-plugins enable rabbitmq_management

# 创建用户和虚拟主机
sudo rabbitmqctl add_user iot_admin your_password
sudo rabbitmqctl set_user_tags iot_admin administrator
sudo rabbitmqctl add_vhost /device_registry
sudo rabbitmqctl set_permissions -p /device_registry iot_admin ".*" ".*" ".*"

# 关键配置（/etc/rabbitmq/rabbitmq.conf）
listeners.tcp.default = 5672
management.listener.port = 15672
vm_memory_high_watermark.relative = 0.6   # 内存使用超过 60% 时触发流控

我的经验：RabbitMQ 的内存阈值一定要设。我曾经没配这个参数，结果一次消息积压，RabbitMQ 直接 OOM 被系统杀掉，所有连接都断了。设了 0.6 之后，它会自动触发流控，虽然吞吐会下降，但至少不会挂。

Kafka 搭建与配置

# 下载解压（以 3.5.0 为例）
wget https://downloads.apache.org/kafka/3.5.0/kafka_2.13-3.5.0.tgz
tar -xzf kafka_2.13-3.5.0.tgz
cd kafka_2.13-3.5.0

# 启动 Zookeeper（Kafka 依赖）
bin/zookeeper-server-start.sh config/zookeeper.properties &

# 启动 Kafka
bin/kafka-server-start.sh config/server.properties &

# 创建主题
bin/kafka-topics.sh --create --topic device-register-events \
  --bootstrap-server localhost:9092 \
  --partitions 3 --replication-factor 1

# 关键配置（config/server.properties）
log.retention.hours=72          # 消息保留 3 天
num.partitions=3                # 默认分区数
default.replication.factor=2    # 生产环境建议 2 或 3

注意：Kafka 的分区数决定了并行消费能力。但分区太多会导致文件句柄暴增。我建议每个主题的分区数不超过 10，除非你有明确的性能测试数据支撑。

整体架构图

下面这张图，展示了我们这一章搭建的所有组件之间的关系。你看一眼，就能明白每个组件在系统里的位置。

组件版本与兼容性

最后，我整理了一份经过验证的组件版本组合。这些版本我都实际部署过，兼容性没问题。

组件	推荐版本	备注
Python	3.10+	3.8 以下已停止安全更新
Go	1.21+	新项目建议直接用 1.22
PostgreSQL	14 或 15	14 最稳定，15 有性能提升
Redis	7.0+	7.0 开始支持 ACL 和更好的内存管理
RabbitMQ	3.12+	3.12 移除了管理插件的依赖问题
Kafka	3.5+	3.5 开始不再强制依赖 Zookeeper（KRaft 模式）

我的建议：别追最新版本。选一个经过社区验证的稳定版，比如 PostgreSQL 14、Redis 7.0、RabbitMQ 3.12。这些版本我都在生产环境跑过一年以上，没出过兼容性问题。