架构

# 前言

早期平台是一个单体应用，随着功能和需求的不断增多，维护一个单体巨石应用的成本和劣势逐渐凸显，并且到了无法忍受的地步。
每次小的功能更新都不得不重启整个后端服务，造成前端交互短暂失联。

单机数据库写请求量大量增加，导致数据库压力变大 数据库一旦挂了，那么整个业务都挂了 业务代码越来越多，都在一个 GIT 里，越来越难以维护 代码腐化严重、臭味越来越浓 上线越来越频繁，经常是一个小功能的修改，就要整个大项目要重新编译 协作成员增加，在同一项目中协作效率低(功能模块多，更新多，逐渐臃肿) 其他一些外围系统直接连接数据库，导致一旦数据库结构发生变化，所有的相关系统都要通知，甚至对修改不敏感的系统也要通知 每个应用服务器需要开通所有的权限、网络、FTP、各种各样的，因为每个服务器部署的应用都是一样的

# 架构设计原则

从架构了可维护性和标准化角度出发，每个后端应用，应该具备相对一致的代码目录结构、一致的配置加载规范、一致的消息总线配置。
所有微服务应用都应该是易部署，可重复的功能模块(可重复部署、简化部署步骤)
通用的 API 端点。

# 应用端口规划表

# 底层工具端口规划表

# 技术架构图

# 后端技术选型

# 前端技术选型