曾经参与的项目系统架构以及各中间件的使用

在上一篇简单说了下我主要参与了XX信息化平台和XX指挥平台，先对项目情况做个简单的介绍：XX信息化平台是一个项目，XX指挥平台也在这个项目里面，多了一个抽取数据的项目，如下图

2年来，为适应业务需要，平台也在不断的优化改造，比如把大屏抽取拆出来，业务改造，区分独立部署和非独立部署，统计分库，引入一些适合业务场景的中间件比如ClickHouse等，服务细分，印象中抽取服务一开始也是没有的。这里就说说XX后台的架构以及中间件的使用。

1.架构情况

微服务架构

spring boot+cloud框架搭建，系统根据基层XX指导文件分为4+6 10个大功能，实现了对党员、党组织、经费、学习等党建工作标准化，信息化部署。系统以党建后台做业务支撑

 运营后台(内部使用)做配置管理支撑，主要实现了用户与角色、组织和菜单、相关入口等一些核心配置

独立部署和非独立部署?

客户端：Web-多地部署、App-只有一个、小程序-只有一个、小马

服务端：一套

基本架构情况如下，从客户端到存储有4层

在此基础上分独立部署和非独立部署，独立部署在各地，一般是在内网，在一套标准的产品下，每个地方根据自己业务情况使用

非独立部署在公司联通云，负责对一些通用基础业务做管理，比如App上的一些通用业务

 另外App登录时也是到非独立部署这边校验，app登录时，查找用户配置表，检查此用户在哪个独立部署环境然后通过nginx转发到到对应独立部署环境的nginx，再通过独立部署的zuul往下走。独立部署和非独立部署nginx同步，用户数据也保持同步。

采用独立部署和非独立部署的方式是考虑到saas化+多租户存在不易管理，个性化不能很好地支持，为此采用这种方式。

如何支持个性化需求?

我们每次发版都是发布到所有环境，数据库结构和一些基础必要配置保证所有环境一致，通过各地运营后台配置+前端处理展示不同个性化需求

如何发布?

上一篇文章说到我们发布都是自动化流程，每次功能上线前，开发完毕由测试验证，都无误打包镜像，将镜像从测试环境推到生产环境(habor管理)，然后发布

2.中间件的使用

Redis 用于缓存和内存数据库
Mongo统计数据归档
es作搜索 主要是指挥平台上用到
XXL-Job定时调度 指挥平台上用到  
flyway数据库版本管理
Cassandra 数据变化和一些接口调用记录
debezium监控的数据变化

config做配置中心

服务中application-yml中的配置