“微服务”架构发展势头强劲，但它仍有一些缺点

微服务（Microservices）架构是一项在云中部署应用和服务的新技术，它是一种架构风格，将应用程序拆分为一系列小型的、可单独部署的服务，每个服务都运行在自己的应用程序中，并通过轻量级设备与HTTP型API进行沟通。

2014年，Martin Fowler与James Lewis共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。同时服务会使用最小规模的集成管理能力（例如Docker等容器），服务可以用不同的编程语言与数据库等组件实现。

由于云商考虑到微服务的广阔市场前景，这些年来，微服务在分布式计算领域炽手可热，几乎是云计算市场的标配商品。然而它也存在着一些显而易见的缺点：

复杂性是最大的问题。与更单一的架构相比，微服务引入了更高级别的复杂性。系统被分解为众多的服务；架构变得更加复杂，理解不同服务之间的交互可能具有挑战性。开发过程中没有免费的午餐，每种方法、工具、语言和架构都有有其必然的优缺点，而缺点往往会在炒作中被忽视。

分配是另一个造成缺陷的因素。对于微服务而言，服务之间的通信通常通过网络进行，从而导致延迟、网络故障和压力增加。出于这个原因，开发者必须在部署基于微服务的应用程序后升级网络。然而，它的成本可不便宜。

数据管理也比较复杂。微服务可能有自己的数据库或数据存储，这将使各种服务之间的数据一致性变得复杂。通常需要付出额外的精力和成本来维护数据完整性，而大多数开发者在遭遇数据损失之前并不了解这一点。的过程

服务依赖的过程可能会很痛苦。当微服务通过API进行交互时，一项服务的更改可能会对其他服务产生影响。这无疑增加了版本迭代的挑战和潜在的兼容性问题，尤其是在升级或更改应用期间。

最后是资源开销问题。对于大多数已部署微服务的应用程序来说，运行多个微服务实例将比单一结构的应用程序消耗更多的资源。这必然会增加基础设施资源投入，如果管理不当，很容易陷入云商的“广告陷阱”而付出更多金钱成本。

我们发现这些年开发人员和架构师对于微服务的使用充满了“过分”的热情。尽管在当代开发思想的主导下，微服务作为解耦、削峰的理念之一必不可少，但是我们都应该牢记架构的目的是什么，以及何时使用，何时不应该使用。

文/水哥