说到微服务OR单体架构，其实这两个场景并不存在很明确的争议界限的，而是可以理解为一个项目或者说一个系统的不同阶段。比如说系统初始阶段采用单体架构，待用户量、数据量上来之后采用微服务架构，这都是很正常的架构现象。那么为什么会出现争议呢？
对于这个问题，个人理解应是项目之初对于架构的选择问题上触发的争议。因为项目之初往往为了快速上线，抢占市场，对于项目上可支配的时间往往不是很充裕，甚至说是很紧张。这个时候就会有两种声音：一种是采用单体架构，项目开发周期短，功能够用，上线速度快，无需考虑由于微服务架构带来的各种数据一致性问题以及子项目的交互问题；另外一种就是说采用微服务架构，虽然开发周期会延长，但是功能更强大，系统整体容灾性更好，系统更稳定，单一子项目代码体量小，上线更快更无感，后期拓展能力更强。
所以说这个时候，往往就会在选择微服务架构还是单体架构上产生争议，不过这个争议其实也是容易评估解决的。如果待开发项目本身初版功能比较简单，且用户量不大，单体架构足以支撑的话，那么考虑到快速上线的情况，当然是选择单体架构周期更短；后期随着功能的不断增多，用户量的不断增长，再逐渐向微服务结构转化或者说整体进行向微服务结构的迁移，都是可以的。而如果待开发项目本身初版功能就比较全，时间上也不是很紧张，那么当然选择微服务架构对于项目的拓展性以及单一子项目代码更新的便捷性上都是很不错的，只是需要考虑数据一致性以及子项目之间通信的问题。
在实际业务中，我们的项目发展过程基本就是沿着单体架构到微服务架构的路线进行的。项目初始往往比较急，需要尽快上线体验功能，因此采用单体架构附以nginx负载均衡转发提供服务，保证项目稳定运行；待后期项目功能不断拓展，单一项目承载太多，体量太大的时候，会拓展出小的子项目，搭建微服务架构来保证系统稳定，同时保证单一子项目迭代上线不影响整体业务运行。
在云上，当然还是微服务脚骨更符合未来云的发展趋势。对于云来说，系统上云往往也就是由于系统本身的数据量太大，本地服务器已经无法承载才会提前上云保证服务运行。而大批量的访问和数据量处理，单体架构自然是无法承载的，这个时候微服务架构就能很好的发挥优势。对于不同的业务开辟出独立的应用进行开发、运行、部署、维护，整体上不影响整个系统本身的运行，这样其实也更符合云的开放的思想。
综合来说，微服务架构更符合未来云的发展趋势。