springboot多模块项目架构更新记录（单服务器部署-＞多服务器nginx分发，可扩容）

前情提要

**以下为简单图示（PS：轻喷，图随便画）**

接手时架构：

修改后架构：

修改原因：

1.随业务量增长，单服务器无法满足需求，且单服务器可用性不够高
2.业务进行拆分部署，独立通用模块，方便多人员同步开发（减少merge，我好不想merge），方便后续独立模块升级

为何使用这种架构

本来是准备直接升级成cloud完整微服务架构的
但是出于时间上的考虑（不太愿意让我花太久）
并且考虑业务量短时间的增长不会过于爆炸（短时间也没法给我搞个十万百万并发练手）
于是就有了图中的架构

架构解释

一个对外服务器（拥有公网ip）、3台内部服务器（无公网ip） 均部署在同一地域（理由后面有）
对外服务器负责对外通信并通过nginx分发达成分发+熔断的效果，提高系统高可用性
其中一台内部服务器部署后台管理已经统计等对用户无感知的服务器，即时宕机了，短时间对用户也没影响
其余两台则用于部署小程序部分的后台、消息通知rabbitmq通信（硬件上报、异步操作、以及部分需要重试的操作）
内部服务器访问外网则通过配置软路由的方式进行
服务器内部访问（rabbitmq，分发等）均通过内网进行，可以加快响应（嫌弃公网带宽贵。。。）

后续架构

如果业务持续增长，短时间只需额外增加服务器+提高带宽即可满足需求

后续架构（畅享）

1.rabbitmq 集群化
2.使用完整中间件监控状态而不是现在的简单nginx分发+熔断，无法做到监控服务宕机
3.考虑用户体验以及高可用，需要异地容灾+数据库同步
4.用户日志处理 ELK
5. 引入大数据框架对数据进行统计处理（mysql不精通果然不太行，join join 着cpu就拉满了o(╥﹏╥)o）
6. K3S/K8s管理（现在上线还是通过scp+脚本搞定的，虽然服务加起来也就十来个搞得定，但是还是想要个界面自动化啊，其实是想要个真正的运维大佬）

结尾

上面写的其实在架构师大佬看来估计全是漏洞，我也只是跟着几年的开发经验和经历自己弄了一个目前可用的架构
后续真要往架构师方向努力还是要多看书，多学习。
此文章仅用于记录个人的一些思路，方便后续回顾及反思，写这篇文章的时候这个架构已经上线运营了两年了。
目前来说是能满足业务需求的，也许后续真并发到了一定数量就要出问题了吧，那也是后面的事情了。

PS：建了一个qq群：324697857欢迎各位进群交流（吹牛打屁）