单体架构还是微服务架构，这是个问题？
（此文章同时发表在本人微信公众号“dotNET每日精华文章”，欢迎右边二维码来关注。)
微服务架构现在越来越流行，那么是不是就意味着单体架构不再成为我们的选择了呢？个人认为这个要依情况而定。
现在谈及微服务架构的文章、演讲随处可见，似乎所有系统的架构都开始尽情拥抱微服务架构，包括笔者前久为一个异构电商平台系统设计的架构也选用了这种风格。然而，我们在选择微服务架构之前，一定要问一句“你现在面对的系统，微服务架构是一个好的选择吗？”。当然，这个问题也是我这几天在思考的。在我看来，任何互联网系统的架构发展到后期，随着复杂度越来越大，那么微服务架构是必然也是最好的选择。但是，正如《互联网系统架构的演进》提到的，系统的架构都是从小到大从简单到复杂演进的，“网站初期的架构一般采用“短平快”的架构思路，架构以简单清晰、容易开发为第一衡量指标。”
所以，微服务架构是否是一个好的选择，实际上要看系统的复杂度来决定的。对于这个问题，老马（Martin Fowler）最近发表的一篇文章《MicroservicePremium》深刻阐述了这一点。他给出了一个很关键的图：
上图直观的说明了单体架构和微服务架构在不同系统复杂度下不同的生产力，以及两者的对比关系。这篇文章谈到的很多具体内容，还需要读者自己去“阅读原文”。
综上，对于那种需要快速为商业模式提供验证的系统，其功能较少、用户很低的情况下，单体架构是更好的选择。不过，为了考虑未来的发展，一些基础性的功能（比如邮件发送之类）还是可以单独抽离封装为微服务的。且在单体架构内部，也需要更清晰的划分功能模块（尽量不让它们产生太强的耦合），数据库设计也可预先考虑未来微服务抽离的情况。
