你真的需要微服务吗？

感兴趣的朋友可以关注"猿学堂社区"，系统化技术内容分享平台。或加入“猿学堂社区”微信交流群

1、前述

自互联网尤其是云平台爆发以来，软硬件基础设施的服务模式不断更新，从早期的IaaS、PaaS、SaaS三大件，到后来的FaaS、BaaS、DaaS，一切以aaS格式表述的新词从各个服务公司的口中提出来，成为技术服务模式的前沿和潮流。所有平台式技术服务的输出，都会以不同形式降低原有的软件开发及运维成本。

开发及运维成本的降低，促使企业可以以同样的人力去维护更加庞大复杂的基础设施平台。在这个基础上，企业可以应对越来越复杂化的应用架构改造升级。而这种改造升级在云平台及成熟的大规模运维工具出现之前，是几乎不可能的。

微服务便是在这种大背景下应运而生的一种架构形式。离开了云基础设施、容器以及大规模的资源编排工具，基于微服务架构的软件系统运维成本大大高于传统架构模式，这足以让绝大多数公司望而却步。

当下的应用架构，微服务和ServiceMesh、云原生俨然已经成为一种事实标准，而传统的Web应用架构、模块化架构已经被弃之如敝履，鲜有人提及。许多人拿着微服务去应用于一切软件架构场景。从未考虑，由微服务架构导致的应用层面的复杂度上升是否真的划算，传统的架构形式是否是一种更合适的选择。

此时，我们应问一句：你真的需要微服务吗？你的架构是不是过度设计了？

我们有必要从传统应用架构模式出发，结合近十年来现代应用场景的不断变化，了解其所面临的挑战以及可能存在的解决方案。通过这个过程中去分析微服务产生的背后原因。只有纵向的去分析应用架构的发展历程，才会知其然更知其所以然，从而更理性的评估和设计软件架构，不会盲从而动。

2、传统应用架构的局限及应对之道

笔者注：软件应用架构类型繁多，要一一列举已超出本文范围。此处所谓的传统应用架构，主要是针对B/S、SOA等互联网应用架构，不考虑诸如C/S等架构形态。

传统应用架构的上一次颠覆式突破应该是“动态脚本”到MVC。彼时，互联网应用无论从并发访问量还是数据量上，都未形成明显的瓶颈，反而业务复杂度以及由此导致的可维护性、业务组件的复用性是主要的问题。显而易见，基于“动态脚本”是无法实现良好的可维护性和可复用性的（这么说也有点绝对，只能说实现成本比较高，门槛也比较高，不适合推广到普通的研发团队）。

MVC的出现完美的解决了这一问题。基于Java的Struts以及后起之秀Spring MVC，基于PHP的Zend Framwork、ThinkPHP都是MVC架构的杰出代表。MVC本质上解决了应用层的问题，但是对于视图层、存储层并未有好的解决方案。以基于Java的各MVC框架为例，视图层通过集成各种模板引擎解决，而存储层则完全交给了开发者，采用各种ORM框架来完成。Spring Framework这类“中间层”（如果可以这么叫）框架，像胶水一样，把各层的框架整合到一起，形成软件的主体技术