转载

IBM架构师分享：极简主义软件架构 - Neal Hu

从构建大规模多区域分布式系统中汲取的经验教训！

在设计系统时，软件架构师通常需要选择各种依赖关系 - 基础架构，身份验证，存储，当我第一次开始在IBM担任软件架构职责时，我倾向于选择完成工作的依赖项，但很快我就学会了这一课：做一个极简主义者。只有在绝对需要时才引入新的依赖关系。

什么是依赖？

答案似乎很简单。如果你的系统依赖某些东西来运行，那就是一个依赖。然而，这只是冰山一角。依赖需要：

存在：无论你的系统走到哪里，它都会发生。
合规性：它符合您的系统要求的相同要求。
“UX”：它让您的用户满意。
维护：您需要花费额外的资源来维护它。

故事

在IBM Watson，与许多其他全球业务一样，我们的系统部署在世界各地。在设计内部SaaS时，我们的团队希望使用由另一个IBM团队托管的数据库即服务。我们在开发环境中使用它做了一个原型，甚至在我们的美国生产中进行了alpha扩展。一切看起来都很棒。

然而，当我们被要求在截止日期前将我们的系统部署到欧洲和澳大利亚等非美国地区时，我们意识到数据库团队有自己的全球推广计划。我们可以等待它们或在我们的代码中创建一个标志，以根据数据库的存在禁用某些功能。

我们最终选择了后者。但它为我们的部署引入了碎片，这导致我们的CI / CD管道出现更多问题。它还在我们的代码库中造成了不必要的复杂性。当我们添加新功能时，我们需要考虑两种情况（使用该数据库或不使用它）。如果您有N个依赖项，则可能最终得到2 ^ N个依赖项存在情况的组合。不用说，这将是一场噩梦。

合规性

今天，计算系统的规则和合规性比以往任何时候都多。如果您的公司为欧盟公民服务，您可以受GDPR的约束。如果您希望在美国为医疗保健业务提供服务，您必须与HIPAA会面。所有这些法规都对您的系统和依赖关系提出了要求。就像您需要确保存在一样，您需要保证您的依赖关系符合相同的要求。否则，在他们违反合规性的那一刻，你的系统也是如此。

“UX”：Kafka Streams vs Flink

当您设计框架并向其他人提供使用代码而不是托管SaaS时，用户体验更为重要。请记住，当用户邀请您的框架进入他们的房子时，他们也必须欢迎这些依赖项。

以Kafka Streams和Apache Flink为例。在构建基于Kafka的流处理管道时，我研究了它们。这里是一些快速上下文背景介绍：Kafka是一个开源的分布式队列系统，Kafka Streams是一个基于Kafka的框架，可以帮助处理Kafka中的数据。Flink可以完成类似的任务。

Kafka Streams和Flink有很多优点和缺点，但对我来说，中间代理是他们的依赖。Kafka Streams只需要依赖Kafka。另一方面，Flink需要依赖Zookeeper集群来实现HA（高可用性）。我们没有足够的资源来自己托管这样一个集群; 因此，我们选择了在Faf上Kafka Streams。

维护

添加新依赖项还会隐藏维护成本，例如其他度量标准，监视和警报，故障方案和自动化。依赖关系可能变慢或者只是失败，您的系统需要具有检测和处理它们的逻辑。部署系统时，持续交付系统应设置所有内容，包括依赖项，因此新的依赖关系通常意味着自动化中的新逻辑。为额外的工作做好准备！

原文 https://www.jdon.com/52386

正文到此结束