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