企业数字化系统架构，从下到上通常分为五层：基础设施层提供服务器、网络和存储；数据层负责数据库和数据存储；服务层承载业务逻辑和接口；应用层面向用户提供操作界面；接入层统一做访问入口、鉴权和流量分发。理解这五层结构，企业就能判断自己的系统处于哪个成熟阶段，也能在选型时知道每一层该选什么技术、关注什么指标。

五层架构各自做什么

基础设施层

这是系统运行的底座，包括物理服务器或云主机、操作系统、网络带宽、存储设备。企业在这一层要决定是自建机房还是用云服务，核心考量是合规要求、数据量和预算。在上海，不少政企类业务因为数据合规要求，会选择私有化部署在本地服务器上，而普通中小企业直接用云服务器起步更轻。

数据层

数据层负责结构化数据的持久化，主流是关系型数据库，配套缓存、消息队列和文件存储。事务性业务数据放关系库，高频访问的热点数据放缓存，大文件放对象存储。数据层是系统性能的关键，表结构设计、索引、分库分表策略直接影响未来能撑多大业务量。

服务层

服务层把业务逻辑封装成可调用的服务。早期系统往往是单体应用，所有功能打包在一起；业务长大之后，会按领域拆成用户服务、订单服务、库存服务等独立部署的模块，也就是常说的微服务架构。服务层要解决的核心问题是：服务之间怎么调用、挂了怎么办、配置怎么统一管理。

应用层与接入层

应用层是用户直接接触的部分，包括电脑端网页、手机端、小程序和后台管理界面。接入层在所有应用前面，负责统一入口、负载均衡、身份认证和流量控制，让外部请求安全地进入内部服务。在上海，多端业务场景下一套后端服务同时给网页、小程序、APP提供数据，就是典型的接入层统一收敛模式。

从单体到微服务的演进

系统架构不是一开始就要上微服务。业务初期用户少、团队小，单体应用开发快、部署简单，是最划算的选择。随着用户量增长、团队扩大，单体应用会出现代码相互影响、发布互相牵制、局部故障拖垮全站的问题，这时才考虑拆分。拆分要按业务领域边界来拆，而不是按技术层硬拆，否则会拆成一堆频繁互相调用的细碎服务，维护更复杂。

演进中要补齐的能力

拆成多个服务后，必须同步补齐配套设施：服务注册发现让服务之间能互相找到；配置中心统一管理各服务参数；链路追踪帮你定位一次请求卡在哪一步；熔断限流防止一个服务雪崩拖垮全站。没有这些配套，微服务只会比单体更脆弱。

主流技术选型思路

选型的第一原则是成熟稳定、有人维护，而不是追新。关系型数据库主流是开源的关系库，缓存用内存缓存，消息队列处理异步解耦，Web服务框架选团队熟悉的技术栈。在上海做企业系统时，Java技术栈因为人才储备多、生态成熟，是多数项目的稳妥选择；但如果团队本身熟悉其他语言，沿用熟悉的技术栈往往比强行换栈更高效。

部署形态怎么选

架构设计还要决定系统部署在哪里。数据敏感、合规要求高的业务，部署在企业自己的服务器上；追求快速上线、不想管运维的，可以用云服务器。两者不是非此即彼，常见做法是核心数据放本地、边缘应用上云。无论哪种形态，都要在架构上把应用和数据分开考虑，方便未来在两者之间迁移。

可扩展性与高可用

好的架构要能跟着业务长大。访问量上来后，应用服务器可以横向加机器分担流量，数据库可以做主从读写分离。这些能力要在架构早期就留出扩展点，而不是等扛不住了再推倒重来。高可用方面，关键服务要避免单点：一台机器挂了，另一台能立刻顶上，数据库要做主备。在上海，企业业务量不大时不必一开始就上集群，但架构上要预留扩展余地，等业务真的涨起来时不至于无从下手。

选型看三个维度

一看业务规模：日活几千和日活几十万的系统，架构复杂度完全不同，小系统不要为想象中的未来过度设计。二看团队能力：技术再先进，团队没人会维护也是负担。三看长期成本：开源免费不等于零成本，后续的运维、升级、故障处理都要算进总拥有成本。把这三个维度想清楚，架构决策就不会走偏。