微服务架构有毒，何时不使用微服务？

【51CTO.com原创稿件】在过去的四年中，使用微服务来构建应用程序似乎成了一种标准。大多数我所合作过的团队也对此表现出了不同程度的兴趣。

微服务所承诺的弹性、高可用、低耦合、敏捷，以及能够解决单体架构带来的问题，这些都是它流行的主要原因。

但是近段时间来，对于微服务的一些保留意见和注意事项似乎引起了人们的注意。

在这篇文章中，我重点想讨论的是微服务的应用，它的缺点是什么，以及在什么情况下应该慎重考虑使用微服务架构。

什么是微服务

在工业级别，关于微服务基本特征的定义比较一致。

这些特征可以总结如下：

微服务是一种应用于组件设计(服务如何分组)和部署架构(服务如何部署和通信)的模式。

微服务适用于创建具有“一定功能复杂性”的分布式应用程序。

各个服务必须小。

各个服务按功能划分，实现关注点分离。

各个服务保持自治和相互解耦，可以独立进行部署、版本控制和伸缩。

各个服务之间通过轻量级 API 和异步通道相结合的方式进行通信。

各个服务拥有独立的状态，并且只能通过服务本身来对其进行访问。

一个典型的微服务实现模式如下图：

图 1：典型的微服务实现模式

从上图中我们可以看到：

微服务中的每组服务有自己的前端(由一个 API 和一个可选的 UI 组件组成)、一个实现自身服务领域逻辑的域层以及独立的数据存储。

前端复合。将所有前端组件(UI 组件或 API)组合成一致前端(复合 UI 或 API 网关)。

一条事件总线，作为异步通信的骨干。

主要问题是，对于那些适用采用微服务架构的用例，人们对微服务的看法趋于一致。

这就是为什么我想采取相反的方法，并试图说明在哪些情况下，微服务可能不是最佳选择。

微服务的种种挑战

实现微服务需要权衡利弊。由于本文的重点不是抨击微服务的缺陷，所以尽量简明扼要。

1. 微服务很难被正确设计

这里有专门的一本书《Microservices AntiPatterns and Pitfalls》来记录它的缺陷。它需要非常非常多的迭代来完成一个令人满意的领域设计。

同时几个基本的和结构化问题没有直接的答案，往往需要调整和迭代，例如：如何水平切分关注点，如何共享数据以及以什么方式进行数据复制，如何管理报告，是否应该在服务中包括 UI 组件等。

2. 微服务引入复杂性

微服务引入了一定程度上的复杂性，这些复杂性已经被详细地记录下来，其中最著名的是“微服务——不是免费午餐”。

图 2：成倍的增加了 API 的数量

微服务带来的挑战包括：

成倍的增加了 API 的数量。这使得变更代码变得困难，并引入了版本控制的复杂性，增加了服务功能性分解的难度。

引入了网络延迟。在组合服务时需要在可伸缩性和响应时间增加之间做出权衡。

鉴于 CAP 理论，处理横跨多个服务的事务非常复杂。和拥有单一数据库的单体架构不同，这些事务通常不是由基础设施处理。

调试分布式系统是复杂的(参见“微服务—不是免费的午餐”)。异步系统、服务间锁和竞态条件中产生的错误很难进行定位和排除。

尽管这些复杂性通过技术手段都可以克服，但是这需要技术人员付出额外的精力，不能让他们专注于实现那些更具价值的业务功能。

3. 微服务需要组织架构发生转变

微服务需要组织转向自治的、跨职能的团队。根据康威定律，这是至关重要的一步。

这意味着前端和后端开发人员、数据平台工程师、QA、产品经理和操作人员必须在一个团队中互相合作。

图 3：微服务需要组织架构发生转变

这样的组织运作起来非常平滑。这是因为大多数依赖关系都存在于团队内部，而且由于优先级是相同的，因此都能够快速解决。

4. 微服务需要过程和实践的改变

微服务需要过程和实践的改变。从偶尔发布几个大版本，到经常发布许多小版本。

从手动的资源供给，到基础设施即代码等自动化形式的资源供给。微服务架构的成功依赖于组织和流程改变的能力，而这往往是最难的。

图 4：微服务需要过程和实践的改变

5. 微服务需要深入的技术栈

上面讨论的这些技术挑战意味着团队的技术集需要更加全面的拓展。