本地计算机上的mysql80服务启动后停止某些_面向服务的体系结构(SOA)失败的迹象...-CSDN博客

停止构建分布式整体

> Photo by Markus Spiske on Unsplash

我见过很多文章，开发人员谈论他们的组织如何转向面向服务的体系结构(SOA)，失败并迁移回整体开发。当然，这没有错。我们工作的一个主要方面是尝试某些东西，看看它是否有效，如果无效，则将其报废。 SOA并不适合所有人。如果不适合您的公司，则坚持使用整体设计。但是，如果是这样，那么您必须做对！

与大型和单一代码库一起工作多年形成了我们对应该如何做的看法和偏见。如果我们在使用服务时不自觉地遵循相同的习惯，那么我们可能不会意识到我们失败的领域。在本文中，我将讨论在SOA世界中应用整体实践的危险。

1.高度耦合的数据和架构

为了在SOA世界中取得成功，必须避免高度耦合的数据和架构。每个服务都应以深思熟虑的前瞻性抽象为基础。服务应在一定程度上是独立的-理想情况下，他们不知道任何服务的存在。在某些情况下，创建高度耦合的服务变得容易：

· 我们构建临时服务以支持临时用例。

· 创建良好的抽象可能会很昂贵。耦合服务是组织阻力最小的途径。

· 一些产品具有中央数据模型。如果我们让数据模型决定我们定义的抽象，我们的服务最终将在某种程度上被耦合。

如果我们不仔细检查我们创建的抽象，则可能会导致高度耦合的服务生态系统。这是一些耦合的依赖结构：

> Photo by the author.

· 左：服务A调用服务B，知道它将调用服务C。然后，它向服务C查询结果。

· 正确：服务A依赖于B，而服务B依赖于C，服务C依赖于A。我们的依赖图中有一个循环。

在这些结构中，您实际上是在开发分布式整体。在某个时候，您会遇到以下问题：

· 您需要同时更新两项服务，但是由于它们彼此依赖，因此您将不知道先更新哪一项。通过在一项服务中进行不间断的向后兼容更改，然后对其进行更新，然后再更新第二项服务，然后再从这两项服务中删除无效代码，即可解决此问题。是的…不漂亮。

· 一个简单的用户流可以跨越多个服务。如果存在问题，则只能由具有多种服务的上下文知识的人来诊断。

一个"坏的"依赖结构暗示了分布式的整体-使用整体的所有痛苦，却没有使用服务的好处。此外，高度耦合的服务通常会铺平道路，并欢迎更多的服务。换句话说，如果您不解决问题，那么随着服务生态系统的发展，情况会变得更糟。

数据耦合

当数据在各个服务之间高度耦合时，您将需要进行投资，以使用同步API调用和异步任务使数据保持同步。这些同步过程也可以采用SAGA的形式。无论如何，您都必须：

· 大量投资于基础架构和测试，以确保数据正确同步。

· 对开发人员进行流程培训，以免他们意外引入更改而导致数据同步问题。

· 随着足够多的数据点在多个服务之间同步，开发人员必定会犯一个错误-并可能造成灾难性的错误。

· 投资可视性和检测手段，以确保在同步过程中断时收到提醒。当确实发生故障时，您必须诊断问题并解决。两者都可能非常昂贵，具体取决于系统的刚性。

但是，如果您能够建立很少/没有数据耦合的服务生态系统，则可以避免不必要的麻烦。

2.整体开发习惯

在SOA世界中，通信结构，团队，运营，部署和流程看起来都不同。经过数年的整体开发，我们收集的工具不一定是与服务一起使用的工具。如果开发人员(和组织)要成功实现SOA，则需要用等效的SOA代替旧的工具/习惯。

本地开发

当使用整体时，我们在本地计算机上运行大多数(如果不是全部)基础架构。开发人员有时会遇到"在我的计算机上不起作用"的问题。组织在引导程序解决方案上进行投资以避免此问题并使开发人员尽快工作。大多数解决方案都围绕使基础结构更易于在本地计算机上运行而进行。

当您开始使用多种服务时，无法在本地计算机上运行所有内容。

· 在大多数情况下，开发机功能不足以在功能开发期间运行必要的服务。您可能无法运行一些大型服务，但是有时您的计算机将无法跟上。

· 在本地运行服务意味着开发人员必须知道如何运行(并可能部署)他们不拥有的服务。理想情况下，服务所有者无需担心所有权以外的任何服务。

投资易于在本地运行多个服务的解决方案是整体式的心态，并且以相同的方式暗示着分布式整体式的方式进行服务开发。我将在文章末尾留下一些资源，介绍其他公司如何进行本地服务开发，但是这些解决方案通常是这样的：

· 使用依赖项注入和客户端库模拟与其他服务的交互。

· 在云中运行您的一些基础架构，在本地运行其中的一些，并将本地基础架构插入到云基础架构中。

端到端测试

端到端测试有两种形式：

· 自动化测试，通常在CI / CD管道中运行。

· 手动测试，开发人员在签入代码之前和进行代码审查时进行的手动测试。

整体代码库中的端到端测试有些简单。设置适当的数据/状态后，您就可以在本地计算机上测试新的用户流。

即使我们编写了很好的单元/集成测试来验证代码的正确性，在质量检查过程中手动测试本地计算机上的所有内容也会增加我们的信心。随着您的服务生态系统的发展，功能和用例将得到多种服务的支持，并且无法在本地测试所有内容：

· 设置适当的状态可能需要很长时间。

· 可能很难模拟与非平凡系统(消息代理，异步作业队列等)的交互。

· 您的计算机无法运行所需的基础架构。

端到端测试在SOA中看起来非常不同。寻求一种易于在本地进行端到端测试的解决方案既昂贵又无法扩展。

SOA之所以受欢迎，是因为它有望加快迭代速度。如果您要花费大量时间在本地测试您的更改，那么您就无法利用SOA进行定位。在某个时候，您需要放弃在本地进行所有测试的心理安全性。

您的测试策略取决于您将采用的本地开发解决方案。以下是一些无需本地测试用户流即可释放代码的方法：

· 隐藏在功能鳍背后的新功能，使您可以在为所有人启用功能之前测试生产中的用户流程。

· 金丝雀部署，影子部署，红色/黑色部署等。

· 在开始生产之前，对阶段中的新更改进行压力测试。

当然，您可以通过其他方式获得通过放弃本地测试而放弃的心理安全性：

· 全面且经过深思熟虑的仪器/可观察性。

· 警报，工作簿和回滚过程可帮助您从故障中恢复。

我在文章末尾列出了测试/部署策略资源。

调试

另一方面，如果您的测试策略需要更改，那么调试策略也需要更改。

在整体中，堆栈跟踪足以使我们开始。堆栈跟踪将我们指向正确的方向，然后我们将跟踪饼干屑，直到解决问题为止。堆栈跟踪和传统的调试工具通常足以调试SOA中的问题，但是它们对于某些类型的问题没有用：

· 暂时性网络错误。

· 跨多个服务的数据同步问题。

· 错误的配置-连接超时，读/写超时，工作线程数，扩展配置等。

尽管您仍会梳理代码以查找问题，但调试工具箱还应包括：

· 用于下载和过滤生态系统中不同系统的访问日志的脚本。

· 分布式跟踪可帮助您了解单个用户请求的生命周期。

· 具有CPU，内存和P99指标的仪表板可捕获不会导致堆栈跟踪的问题。

· 复制生产环境的负载模拟策略。

下一步

如果发现自己处于这种情况下该怎么办？当然，没有一种万能的解决方案。这里有一些想法可以帮助您入门：

· 首先，如果服务稳定且未更改，请不要理会系统。它正在运行，并且您不想成为破坏它的人，因为您已经"开明"。

· 如果您当前的体系结构引起了问题，那么我要做的第一件事就是分析维护当前系统的金钱成本，与迁移到更好的系统相关的成本以及新系统可以节省的成本。这是一个艰苦的练习，但是您会惊讶地发现，使用提前期，错误/中断数量，受影响的用户数量等指标可以走多远。一旦进行了全面的分析，您可能会意识到迁移没必要但是，如果分析增强了您迁移系统的决心，请使用分析来获得管理层的支持。

· 在许多情况下，更改当前系统是不现实的。该组织不能承受缓慢的迁移速度，这可能太昂贵了，等等。没关系。您仍然可以确保系统的设计正确地向前发展。

结论

在SOA中开发分布式整体非常容易。我们需要避免将整体开发习惯应用于我们的服务。以下是一些要注意的症状：

· 高度耦合的数据和/或体系结构。

· 用于多个服务的本地开发策略不佳。

· 一个糟糕的测试策略，涉及在本地测试所有内容。

· 过时的调试工具无法诊断网络和跨服务问题。

整体开发还不错。只是不同而已。许多公司已经投资了向SOA的转移，却没有意识到他们要投资于整体开发要好得多。无论您坚持使用整体方案还是走服务路线，请务必避免构建分布式整体方案，这是两全其美的做法。

(本文翻译自Talha Malik的文章《Signs of Failing Service-Oriented Architecture》，参考：https://medium.com/better-programming/signs-of-failing-service-oriented-architecture-fd405c58f75b)