软件架构的本质是一种在特定资源背景下折中平衡后追求业务增长的一门艺术。决定开发技术架构选型的因素很多。这里，我们简单的对两种不同开发架构模式进行客观比较，希望对大家在技术架构选型时能有所参考意义。
提示
盘古开发框架 不会把用户绑定到一个固定的开发范式和架构上，而是支持随意组合、自动装配、灵活插拔。 既能构建大并发高可用的分布式微服务架构也能搭建小巧的垂直单体分层架构。
单体分层架构 VS 微服务分布式架构
- | 单体分层架构 | 微服务分布式架构 |
|---|---|---|
| 开发 | 开发测试流程简单 | 开发测试流程相对复杂 |
| 部署运维 | 单机部署或集群部署（简单）、运维成本低 | 分布式部署（略难）、运维成本高 |
| 团队人员 | 团队围绕一个中心应用开发，对开发人员能力要求低。开发、维护成本相对较低。 | 团队基于分布式多应用协作，对开发人员能力要求略高。开发、维护成本相对较高。 |
| 其它 | 扩展性弱、可靠性低、技术创新能力弱、企业对代码等数字资产管控能力弱。 | 扩展性强、可靠性高、技术创新能力强、企业对代码等数字资产管控能力高。 |
警报
上述指标对比均为相对结果，仅供参考。在特定项目资源、团队背景、业务场景等环境下，相关指标的相对高低强弱对比是会有偏差甚至反转的。
盘古开发架构选型建议
如下是从不同维度简单粗暴的以定量或定性的角度给出了一些选型建议，结论是孤立的脱离实际的，仅供参考。采用什么样的架构开发模式不能一概而论，需要大家综合当下实际情况 酌情选择 。 👻
| - | 单体分层架构 | 微服务分布式架构 |
|---|---|---|
| 开发人员 < 5 | ✔ | |
| 研发预算 < 100 w | ✔ | |
| 用户数较小的管理类系统 | ✔ | |
| 面向C端的（移动）互联网应用 | ✔ | |
| 多任务多小组协作 | ✔ | |
| 有专职运维人员 | ✔ | |
| 追求可维护性和扩展性 | ✔ | |
| 追求技术团队长期收益 & 增长 | ✔ | |
| 甲方企业自建的技术团队 | ✔ |