问微服务和存储过程

EN

没有任何东西明确禁止或反对在微服务中使用存储过程。

免责声明:我不喜欢开发人员POV中的存储过程，但这与微服务没有任何关系。

存储过程通常在单核数据库上工作。

我觉得你是在屈服于逻辑谬误。

存储过程现在正在下降。大多数仍在使用中的存储过程来自一个较旧的代码库，该代码库一直保存在其中。那时，单块数据库也比微服务流行的时候普遍得多。

存储的procs和单块数据库都发生在旧的代码库中，这就是为什么您经常看到它们在一起的原因。但这不是因果关系。您不使用存储的进程，因为您有一个单一的石器时代数据库。您没有单块数据库，因为您使用的是存储过程。

大多数关于微服务的书推荐每个微服务一个数据库。

没有任何技术原因可以解释为什么这些较小的数据库不能有存储过程。

正如我所提到的，我不喜欢存储过程。我觉得它们很烦琐，对将来的维护也很难。我确实认为，在许多小型数据库上扩展sprocs进一步加剧了我已经不喜欢的问题。但这并不意味着这是不可能的。

同样，大多数微服务体系结构书籍都指出，它们应该是自主的和松散耦合的。使用专门用Oracle编写的存储过程，将微服务与该技术紧密结合在一起。

另一方面，无论您的微服务使用什么ORM，都可以使用相同的论点。也不是每个ORM都支持每个数据库。耦合(特别是它的紧密性)是一个相对的概念。这是一个尽可能宽松的问题。

无论微服务，Sprocs在一般情况下都会受到紧耦合的影响。我建议总体上不要使用sprocs，但不是特别因为您使用的是微服务。这和以前的观点是一样的:我不认为sprocs是可行的(一般情况下)，但这可能只是我的偏见，而且与微服务无关。

大多数msa书籍(我已经读过)都建议微服务应该面向业务(使用ddd设计)。通过将业务逻辑移动到数据库中的存储过程中，情况不再是这样了。

这一直是我对sprocs的主要抱怨:数据库中的业务逻辑。即使不是意图，它往往总是以这样的方式结束。

但是，不管你是否使用微服务，这种抱怨依然存在。它看起来是一个更大的问题的唯一原因是因为微服务推动了整个体系结构的现代化，而sprocs在现代体系结构中不再那么受欢迎。

要编写软件，需要将

与一项技术紧密结合在一起。

。

至少对于正在开发的编程语言所提供的运行时环境。

但更普遍的是，您会发现您的微服务与几种技术紧密耦合在一起：

• 提供高级HTTP/SSL/SOAP协议实现的网络服务框架
• 存储库/ORM/DAO框架，以提供持久性。
• 数据操作框架，以提供处理数据的工具。
• 进程/线程/ OS框架提供对操作系统资源的访问，如多任务、文件系统、内存、GPU计算、扩展卡等。

这是一种简单的微型服务。

存储过程

存储过程只是您可以选择使用或不使用的另一种技术。它不会神奇地使您的代码变得单一，或微。

然而，它的实质是：

• 另一种技术。应用程序中的每一种技术都减少了任何给定程序员对该技术组合的读取、理解和明智设计选择的可能性。
• 一种使用不同编程范式的语言。对于非专家来说，试图强迫他们自己的命令、功能、面向对象等等都太容易了.透视它，这往往导致少于恒星的结果。
• 一个API。它必须像代码库中的任何其他类一样维护。这也意味着数据库提供了一个非通用的接口。这使得替换数据库引擎本身和透明地应用通用行为(例如在内存缓存中)变得更加困难。
• 一件艺术品。必须对其进行版本化、测试和部署。这是可以做到的，但是数据库是需要一种不同方法的活构件。您通常不能只删除原始文件，然后替换它。为了将系统迁移到所需的状态，经常需要对更改进行过度的精心编排。

每一个都是真正的代价。在某些情况下，成本是合理的，而在另一些情况下则不然。

您将通过托管脚本引擎来支付几乎相同的成本。唯一的简化是您可以选择与宿主语言相同的编程范式。

业务逻辑

将业务规则迁移到数据库中是错误的做法。不是因为存储过程。

这是一个糟糕的实践，因为数据库和业务逻辑在不同的剪切级别上运行。

• 成熟应用程序中的数据库可以使用几十年。一般来说，这些系统会定期更新引擎，但是数据库本身已经被迁移了。它从一开始就没有被杀死和重建。没有理由让一个微型服务的寿命如此之长。
• 相比之下，几十年来，商业规则的变化是多么迅速。根据我的经验，一条古老的商业规则也许有几年的历史，但大多数规则变化很快，你永远也无法判断下一个规则会改变什么。一个新的要求，从一个调节器，旧的产品正在退役，更改的字母头，改变多少雇员向老板报告，等等，等等。

如果业务逻辑分布在剪切层上，特别是分布到一个较慢且寿命更长的层，它将产生对更改的抵抗。这不一定是坏事。毕竟，只有一个数据库中的业务逻辑为零，那就是一个三重存储。

仅仅指定表模式的行为就是将业务逻辑移动到数据库中。

Architecture

您正在努力使用适当的工具来解决适当的问题，而不需要太多的工具，也不会使它太难解决，以便制定和维护解决方案。

这可不容易。

但是，让我们想想不可思议的是，您将如何维护跨几种语言的业务逻辑？

• 目录..。以便能够跟踪和维护每个业务规则实现。
• 测试..。这可以针对每个业务规则使用，而不管它是在哪里实现的，也不管是如何实现的。
• 一个参考实现。因此，当发现不一致之处时，真相的来源就存在(或者至少是争论的源头)。

但这也是有代价的。

• 允许业务规则有许多实现更好吗？这样每个人都可以利用团队技能和框架规定，但需要严格的质量控制来避免有许多小的变幻莫测？
• 还是用一种语言写成一个单一的真理来源更好？可以说，实现成本更低，但也是一个单一的故障来源，它本身就是一个在不同平台、框架或尚未发明的工具面前抵抗变化的单一组件？

在开始我的回答时，我会说我实际上维护了几个使用存储过程的微服务。而且，在我的职业生涯中，我已经写了很多存储过程，我绝对同意，如果使用不当，事情会变得非常非常糟糕。

所以简单的回答是，不，存储过程在微服务体系结构中本质上并不坏。但你需要明白：

1. 你在给存储引擎的替代增加障碍。如果某些操作或性能特性或特性限制要求您切换存储引擎，则成本将更高，因为您将编写和测试大量新代码。运行多个存储引擎(在迁移阶段或根据性能需求隔离活动)可能会带来一致性问题，除非使用两阶段提交(2PC)，这本身就存在性能问题。
2. 您还需要维护另一个API，这意味着您的依赖关系可能中断。添加、删除或更改过程中的参数类型可能会破坏现有代码。在表和查询中也会发生同样的情况，但是您的工具在跟踪可能出错的地方方面可能没有多大帮助。存储过程的问题通常在运行时发现，在开发/部署过程中非常晚。
3. 你的数据库权限变得更复杂了。过程是以登录用户的身份运行，还是作为其他角色运行？您需要考虑这个问题，并对其进行管理(希望是以自动化的方式进行)。
4. 您需要能够安全地迁移到新版本。通常情况下，必须删除并重新创建一个过程。再一次，权限可能会给您带来一些问题。
5. 迁移失败的回滚可能意味着额外的努力。当产品环境与开发人员分离时，事情就变得更加具有挑战性。

这些是存储过程的一些用途，我认为它们通常是值得的：

1. 编辑历史记录(审计日志)的强制执行。触发器通常用于此目的，触发器是存储过程。在某些数据库中，也可能完全不允许应用程序角色的插入和更新:客户端执行过程，这些过程以不同的角色运行，具有适当的权限，并强制执行所有必要的行为。
2. 检查约束的扩展。这可能会让您进入业务逻辑领域，但在某些情况下，数据库的内置约束工具可能不足以满足您的需要。通常，表示检查的最佳方式是使用命令式代码，如果您依赖应用程序为您执行检查，则可能会出现错误的数据。
3. 当视图不适当或过于复杂时，对复杂查询的封装。我已经看到过一些情况，正确的视图需要一些非常复杂的SQL，这些SQL可以在存储过程中更容易理解。这可能很少见，但确实会发生。

一般来说，我建议你先尝试一下意见，必要时才诉诸程序。设计良好的视图实际上可以充当API，抽象出底层表如何被查询的细节。在某些情况下，使用存储过程增强API (视图)是有意义的。甚至可以直接从SQL查询发出JSON，从而绕过将数据从查询结果映射到应用程序的数据模型。这是否是一个好主意是由你根据自己的需要来决定的。

因为您应该已经在管理数据库资源(模式、权限等)通过一些自动化工具，不，存储过程本质上并不是对微服务不利的。