微服务架构的十个劣势

微服务架构在业界有许多定义，但最常被接受的定义是，微服务架构是一种将大型复杂软件系统，通过提供API的办法，分解为更小的模块化部分的方式。

建立一个具有微服务体系结构的解耦系统有很多好处，从一开始就开始使用这种分布式和分离式体系结构来构建整个系统，已经成为一种行业规范。基于云的应用程序的架构类型非常适用，已是非常确定的事实。

尽管它带来了实实在在的好处，但同样重要的是要注意，这种类型的体系结构还有一些缺点，需要在系统架构和设计的初始阶段多搞一些才靠谱。因此，需要更细致的方法来了解您是否真的需要从一开始就构建一个分离的系统。

有时候最好从单体应用程序开始，然后花时间将不同的功能在服务变化过程中分解为服务。因此，我们来看看微服务体系结构的一些常见缺点，它将帮助您获得更均衡的观点：

1. 难以维护 - 基于微服务的系统很难维护和重构。在单体系统中，只需要一个代码库进行更改，而在基于微服务的系统中，则会有许多不同的代码库需要开发和维护。

2. 写代码复杂 - 必须承认，建立一个分离的分布式系统并不是小菜一碟。它需要细致的系统规划和设计，您必须将许多接口代码层组合在一起。然后还可能会出现服务没有响应的情况，因此你需要编写代码和检查来处理各种情况。

3. 部署和系统管理员可能会很痛苦 - 即使只部署一个应用程序，有时也会变得非常痛苦，并且经常会需要由运维团队来救火。现在微服务会将这个问题按服务数量来扩展。没有合适的运维团队，建立和管理基于微服务的系统几乎是不可能的。

4. 数据库管理 - 虽然有可能你有一个单一的数据库与所有的服务对话，但即便是这样，也需要明显复杂的逻辑和非常严密的代码来维护事务。也有些情况下，单个服务可能需要拥有自己的数据库，并且管理如此多的小型数据库可能非常麻烦。

5. 需要更多的人力 - 微型服务架构会导致太多与系统一起增长的移动部件，并且管理所有这些接口移动部件，与维护单体系统所需的团队相比，您需要拥有更大的团队。

6. 不同的技术堆栈 - 尽管最初可能不需要长期只能使用特定的技术栈，但随着技术栈数量的增加，管理它们的努力和工程专业知识也会增加。

7. 跟踪错误很难 - 跟踪应用程序性能和管理日志或发现错误非常困难。在单体系统中，跟踪、识别和修复错误非常简单。

8. 性能取决于网络影响 - 由于大多数服务通过网络相互通信，所以系统的性能取决于底层网络的强度。

9. 改变接口会使事情变得复杂 - 为了使松散耦合的服务系统运行良好，每个API的一开始的设计都需要很到位。虽然这样子的系统，故障是孤立的，但仍然在api变化时，可能会对其他功能产生灾难性的级联影响。

10. 测试成为一项挑战 - 测试单体系统要容易得多，但要测试基于解耦服务的系统，意味着要为每个单独的API执全局的性能、探索性、功能性和回归测试。对于手动QA工程师来说同样困难，而且为这样的系统构建和维护自动化测试套件本质上也是相当具有挑战性的。

所以更有效来讲，您需要一个战略和一个专家团队来执行该策略，以解决构建微服务系统带来的这些问题。有适当的地方有了正确的自动化、正确的工具和团队，许多这些缺点可以相当轻松地解决。 我们Enpointer在所有我们所从事的产品中都是微服务架构的支持者。 因此基于微服务架构的专业人员绝对可以搞定我们刚才所描述的缺点，但对事物有一个平衡的看法是有帮助的，这样下一次您设计新产品的架构时，您就可以获得更全面和更具质感的理解。

translated from https://enpointer.com/blog/10-disadvantages-of-micro-services-architecture/

54chen注：微服务有许多难点，其中的关键，是模块间关系表达、模块间负载均衡、模块问题快速发现和定位。