B/S 架构
浏览器即客户端,门店电脑打开网址就能用,不需要逐台安装客户端;版本升级在服务器端完成,几百家门店同步生效。
Technology / 技术架构
针对大型汽车经销商集团与汽车维修连锁服务企业的实际并发场景设计: 浏览器即客户端,门店免安装免升级;Java 语言研发,跨平台稳定运行; Redis 多级缓存扛住高频查询;集群化与分布式部署可随机构数量横向扩展。
Tech Stack / 技术栈
每一项都对应一类真实的部署与运维难题:门店数量增长、跨区访问、高峰期集中开单、集团与门店的数据边界。
浏览器即客户端,门店电脑打开网址就能用,不需要逐台安装客户端;版本升级在服务器端完成,几百家门店同步生效。
采用 Java 开发语言,跨平台部署,Windows 与 Linux 服务器均可承载;语言生态成熟,长期维护与二次开发成本低。
集合 Redis 高速缓存,把车型字典、库存快照、权限菜单等热点数据放在内存层,高峰期列表与查询不再直接压数据库。
应用节点以集群方式横向扩展,多节点共同承担请求;单节点维护或异常时业务不中断,适合集团级多机构同时在线。
应用、缓存与数据服务可分别部署在不同服务器,按压力逐层扩容;跨区域连锁可就近部署节点,降低访问延迟。
集团下各机构数据按权限边界隔离,门店只看本店,集团可跨店汇总;调拨、月结等跨机构业务在受控流程中流转。
Architecture / 三层架构
上层负责谁在用,中层负责做什么,底层负责数据怎么存与怎么出去;接口层把移动端浏览器、财务、生产、呼叫中心与厂家 DMS 接进同一套口径。
Deployment / 部署方式
同一套程序,三种落地方式。选择的关键不是价格,而是数据放在哪、谁来运维、以及未来扩店的速度。
| 对比项 | 私有化部署 | 云托管部署 | 混合部署 |
|---|---|---|---|
| 部署位置 | 服务器部署在集团自建机房或自有机柜 | 部署在云端主机,由我方托管运行环境 | 核心数据在本地,移动端与外网点在云上 |
| 适用对象 | 有自有机房与专职运维的大型经销商集团 | 中小型连锁与单店,希望开箱即用 | 既要数据本地留存,又要员工与车主随时访问 |
| 数据主权 | 数据完全留在企业内部网络 | 数据存放于云端环境,按账号权限访问 | 业务主数据在本地,移动端仅同步必要字段 |
| 扩容方式 | 自行增配服务器,扩展上限取决于自有硬件 | 按需调整云主机配置,扩店时快速加节点 | 本地与云端分别扩容,互不牵制 |
| 运维投入 | 企业侧负责硬件、网络与机房环境 | 我方负责运行环境与日常巡检 | 本地部分企业侧维护,云端部分由我方维护 |
| 典型场景 | 集团自建机房、对数据出网有明确要求 | 中小连锁上云、门店分散且无专职运维 | 数据本地 + 移动云,兼顾合规与移动办公 |
| 上线节奏 | 需先完成硬件与网络准备 | 环境就绪快,注重数据初始化与培训 | 需同时规划本地与云端两侧网络 |
具体部署方式可在需求沟通阶段根据门店数量、网络条件与数据管理要求共同确认。
Performance / 性能与可用性
以下为集群环境下的运行指标口径,反映系统的可用水平、缓存效率与承载能力。
Security / 安全与运维
安全不是一句口号,而是权限怎么分、日志怎么记、备份怎么跑、传输怎么加密这些具体动作。
Extension / 二次开发与接口
标准功能覆盖通用流程,个性化需求通过开放接口与二次开发承接,不破坏主干版本的可升级性。
提供对外接口,供企业内部其它系统读取车辆、工单、库存与收款数据,避免重复录入与口径不一致。
与主机厂 DMS 系统对接,同步车辆、索赔与备件业务数据,减少门店双系统重复操作。
与在用财务系统对接凭证与往来数据,业务单据与财务账务保持口径一致,减少人工对账。
面向车主手机浏览器(H5 页面)开放预约入口,车主端在线预约、查进度、查账单,消息提醒直达车主手机。
基于 Java 技术栈承接个性化报表、字段与流程定制,定制部分与主干版本分开管理,升级互不干扰。
旧系统的客户、车辆、库存与历史单据可导入并校验,切换前完成数据清洗与口径对齐。