微服务还是单体，应用架构怎么选？

近几年，由于微服务生态建设的完善，微服务架构渐成趋势，逐渐流行。业内人士也都在争先恐后想一睹微服务芳容，甚至想王老虎抢亲。但同时存在没有认真考虑微服务架构是否适合自己的应用场景以及组织文化的问题。

本人在前几篇博文已经对微服务生态有了阐述。所谓生态，实际上讲的是天时地利人和，讲的是各方和谐。微服务生态的好坏，对微服务架构的实现有着直接的关联。所以，在实施微服务架构应用的同时，大家应该着力 
打造微服务生态。

以下是本人对于选择微服务架构还是单体架构提出的八个原则。本人才疏学浅，冒昧班门弄斧，让各位大咖见笑了。

1.对于业务需求而言，单体架构适合需求稳定可见，项目排期固定，变更在可控范围内，投资稳定的业务需求。而微服务架构适合于需求VUCA，用户量大，用户体验要求高（无时无刻，无论何处）、需要持续更新迭代的项目，当然需要持续投资。

2.对于系统运行而言，单体架构适合于访问量稳定可预期，系统性能需求可控，性能压力均衡，没有集中的突出的性能压力点的系统运行状态；而微服务架构通过对数据库分拆、业务功能分拆、和运行时资源动态伸缩的方法（参考《The
Art of
Scalability》），使得应用能面对访问量突变，性能突变、性能压力不均衡、压力点集中的系统运行状态。

3.对于开发过程而言，传统的瀑布式开发模式比较适合单体应用的开发，基于精益理念的敏捷开发模式适合于微服务架构，当然这不是绝对的，单体应用也可以采用敏捷开发模式。

4.对于项目开发模式而言，单体架构应用可以用外包模式，开发外包，运维外包，需求和实施两头在外，甲方项目经理主要负责在规定时间内需求落地，项目经理和运维经理可以分开；微服务架构适合于自开发自运维，或者与长期战略合作伙伴共同开发运维，适合于产品经理责任模式，“谁开发，谁运维”。

5.对于架构设计而言，单体应用无需考虑太多解耦问题，事务一致性很容易实现。而微服务为分布式架构，业务上需要领域专家和架构师一起进行合理的业务分拆和功能分拆，同时要保证运行时事务的最终一致性，还要考虑跨微服务session管理和统一认证鉴权问题，所以架构设计要求极高。

6.对于Infrastructure而言，单体应用结构简单，所以实体机技术和虚机技术就可以满足单体架构了，而支持微服务架构应用的开发需要基础架构快速ready
和自动伸缩的能力，所以更适合在云平台下进行。

7.对于团队运作而言，由于单体架构的建设(需求设计开发测试发布运维等过程)按部就班进行，各个团队联系无需很紧密，故对devops要求不高。而对于微服务建设，需要全栈团队自助服务，团队内部联系紧密，反馈及时，因此，特别依赖于持续集成持续部署和devops。（康威定律）

8.对于测试发布运维而言，由于单体应用架构简单，且技术单一成熟，故测试发布运维压力不大；而由于微服务架构的分布式架构，服务组件众多，服务调度复杂，资源分配会动态变化，发布过程要求无感知发布，且广泛使用开源技术，所以测试发布运维难度加大，需要投入大量自有人力和专业的第三方支持。