提及软件系统架构时，通常会涉及高度可用的集群架构。然而，由于投入成本的限制，实施与规划常常存在较大差异。
今天，让我们探讨常见的高可用架构。
单机应用架构
单机架构很常见，因为简单，部署和管理都很清晰！特别在政务和传统企业领域，一个信息化项目就是系统软件加上一台物理服务器。在医院和一些具有IT运维能力的单位，会分配虚拟机来降低成本，架构本质上相同。
主要特点：
- 单台服务器部署一个或多个应用
- 应用端口直接暴露公网或通过防火墙映射
- 开启系统防火墙，可极大简化安全配置
- 禁止服务器外部访问数据库和Redis
- 服务器和应用接入星尘，方便监控和发布
最小高可用架构
双机最小高可用架构，在成本受限的情况下提供一定的高可用能力。两台服务器，应用和数据库互为主备，既分摊了压力也避免单点故障（需手工切换）。
主要特点：
- 两台服务器，典型分配是应用A加数据库B
- 数据库服务器部署备应用，避免A故障
- 应用服务器同时作为数据库从机，避免B损坏丢数据
- 前端nginx提供负载均衡，在A不可用时自动切换B
- 服务器和应用接入星尘，方便监控和发布
小型高可用架构
小型高可用架构把应用和数据库分开到不同服务器，进一步提升可用性。应用服务器集群（2台+）完全分摊用户请求，且随时可以扩容缩容，也方便维护重启。小型应用的数据库压力不大，一般把中间件跟数据库部署到一起，甚至只用一台服务器。
主要特点：
- 3到4台服务器，应用独占2台，数据库使用1到2台
- 应用与数据库分离，进一步提升性能
- Redis使用主从架构，从机打开持久化，主机不开
- MQ中间件出现，推荐使用RedisStream作为消息队列
- 服务器和应用接入星尘，方便监控和发布
标准高可用架构
标准高可用架构，要求能够关闭任意服务器，且不影响业务系统整体。
分为网关、应用、数据、监控四大部分，各自可简化或强化
主要特点：
- 引入硬件负载，结合虚IP，规避nginx单点故障
- 应用集群使用虚拟机/容器化，方便扩容缩容
- 数据库集群结合虚IP，实现故障自动切换
- Redis集群主从架构提升吞吐，且避免单点故障
- 服务器和应用接入星尘，方便监控和发布
大型高可用架构
大型高可用架构，在标准高可用架构基础上，增加异地多活。实时多活极难实现，一般某可用区故障时，由其它可用区提供降级服务
主要特点：
- 多地域建立机房，借助DNS和来访IP识别可用区
- CDN解决跨网络服务商访问不佳问题，要求多线机房
- 每个可用区数据向备份可用区单向同步，某可用区故障时，由备份可用区为其提供只读服务
- 写入数据不大的应用，在可用区之间双向同步，异地多活
- 服务器和应用接入星尘，方便监控和发布
常见的异地多活方案，大多数都是阉割版，并非实时异地双写。实时双活最大难题在于，每一次写入数据，都需要等待写入异地机房并收到确认后才算完成事务！且不说系统性能会答复下降，两地间网络的轻微波动，都能让整个系统停止服务，反而降低了可用性。
所以，大多数多活方案，都是以下两种：
- 主备机房之间单向同步核心数据，主机房故障时，备机房提供查询服务（降级）。
- 应用核心数据支持单向写入汇总，主机房故障时，请求流量指向备用机房，数据落盘后再等待网络恢复时写回主机房。
总结
每种应用架构方案都有其优缺点，在实际情况中需要根据具体情况进行选择，增减相应功能。
星尘适用于每一种架构，提供性能监控和健康监控服务，更进一步可提供发布功能以及应用配置管理功能。