在软件项目开发过程中，都有哪些常见的软件架构？

所有的架构都是基于业务演进而生的，这些年来软件架构的演变路径如下：

1. 单体应用：数据库、服务部署在同一台机器上

2. 单数据库多应用架构

3. 读写分离数据库架构 + 缓存(CDN、Redis)

4. 使用消息队列的架构

5. 面向服务的架构（SOA）

6. 微服务架构：API-Gateway、服务发现、熔断机制、服务部署

演进之路

1）单体应用 -> 单数据库多应用架构

原因：用户增加、业务变得复杂、系统响应速度变慢

方案：水平扩容

2）单数据库多应用架构 -> 读写分离数据库架构

原因：系统业务功能增加，数据库查询成为瓶颈，查询时间慢，整体响应变慢

方案：主从分离，CDN及业务缓存(Redis)

3）读写分离数据库架构 -> 消息队列架构

原因：存在耗费大量服务器资源及耗时较长的业务；流量瞬增场景

方案：消息队列

4）消息队列架构 -> 面向服务架构(SOA)

原因：系统复杂度增加、参与开发者变多

方案：单服务拆分为多个服务

典型案例：SSO单点登录

5）面向服务架构(SOA) -> 微服务架构

原因：系统复杂度增加，不同应用和数据之间互相依赖，逻辑纠缠不清，项目的部署进入了混沌状态

方案：微服务，解耦；将不同职责的服务独立部署，从而实现服务内部高内聚，服务之间低耦合的效果，让开发变得更为灵活!

结语

架构也很难一开始就设计的完美，架构不是设计出来的，甚至不能被设计，只能在需求的变化中不断演进。架构师的工作不太像建筑师那样构建大的蓝图，更像药剂师那样对症治病、照方抓药。就像《大教堂与集市》说的那样，“软件很大程度上是一个服务行业，虽然长期以来都毫无根据地被错认为是制造行业。”

就像生命在自然环境中不断适应，才得以演化；我们的架构需要根据需求中不断改进，才得以敏捷。

细细体会服务架构演进的步骤来看，无非是在不断的解决新的问题而产生新的架构，这就好似在这条路上不断循环

1. 确定新的问题域

2. 抽象新的问题域，产生新解决方案

3. 出现新的问题域

微服务架构不是这条路上的终点，这就好比现在又早就出现的云原生、Serverless、ServiceMesh、PAAS、SAAS等，当然这些出现的新的解决方案也都是终点；

在未知的道路上很崎岖，但是却永远都不会有终点的那一天，我们要不断的探索未知，解决未知。