在绝大多数架构项目中，往往会出现一系列常见的失误，然而，透彻认识并理解这些失误，我们或许能够有效地降低它们再次发生的风险。

本文专注于探讨技术架构设计领域中常见的失误，而不深入考虑项目交付、人员因素和商业模式等方面。

一、连接！连接！连接！

几乎所有现代平台提供商的一个核心目标在于构建一个“包容性生态系统”，这一生态系统能够让用户在同一平台上执行各类活动。

然而，不容忽视的现实是，并没有一个完美的平台能够应付所有需求！一项成功的架构设计必须始终考虑入站和出站的连接，并且要允许用户利用其他工具来实现其需求。

数年前，我曾参与过一个卓越的大数据平台项目，该平台采用了一种尖端的仓库工具。然而，令人遗憾的是，该平台并未全面支持API调用（尤其是最新的RESTful和开放API），这意味着无法流畅地将数据引入平台。同时，用户必须安装ODBC驱动程序并通过管理员权限配置DSN才能提取数据，这一操作过程异常繁琐。

这就好比是一个思维敏捷的天才，却无法阅读或表达自己一样！

需要考虑的事项：

• 这个平台是否能够支持来自各种数据源的多种连接方式？
• 是否为最终用户提供了最新的解决方案，以便他们能够轻松地从生态系统之外进行数据查询？

二、关于“肤浅”或“有毒”的安全架构

虽然人们普遍声称“安全高于一切”，但很少有人从项目的一开始就充分考虑安全架构。安全框架的后期介入有时会导致两种截然不同的情况：

• 要么它几乎无法发挥作用，只是依赖“繁琐的流程”来欺骗内部或外部的审计机构。
• 要么它过度干预，采用复杂的流程来阻止用户执行任何操作。

我曾经见过一些处理生产数据的极端案例，其中的安全措施使得环境受到高度隔离，最终用户只能通过一种渠道来查询数据。

毫无疑问，安全确实至关重要，但如果结果是“在安全之下几乎没有（或没有）可用的资源” — 那我认为这已经违背了初衷。

需要考虑的事项：

• 一开始就应确保团队中有经验丰富的安全架构师，他是否具备实际交付项目的经验？
• 安全框架是否可能妨碍用户进行日常的业务操作？

三、与更广泛基础架构的低兼容性

几乎所有数据平台项目最初都怀揣着宏大的愿景，比如“改变世界”，但实际上，绝大多数项目都在实施过程中做出了一些妥协。

当我们无法淘汰旧系统、必须依赖现有解决方案时，兼容性问题会成为一道难以逾越的障碍！

多年前有一个项目，旨在引入最新的SSIS/SSAS报告和分析工具。最初的计划是将后端的Oracle数据库替换为MS SQL，但由于各种因素，这一计划在半途中被搁置。结果，解决方案最终变得“处于待定状态”，因为SSIS/SSAS并不原生支持Oracle数据库，必须安装Oracle“驱动程序”。前后端之间的兼容性问题带来了大量功能的缩减和性能问题。

需要考虑的事项：

• 我的主要解决方案是否能够自然支持上下游的组件（无需额外的驱动程序）？
• 假如解决方案最终被搁置并“处于待定状态”，我的解决方案中的每个组件是否足够兼容旧系统？

四、无处不在的数据复制

许多最终用户抱怨他们拥有多个数据源，却不知道哪一个是最佳选择。虽然很多架构提案最初的目标是实现“一个真实的版本”，但无可避免的是，数据复制问题仍然屡见不鲜。

典型的数据复制情况包括：

• 展示层复制基础数据层，以适应报告和可视化需求。
• 公有云复制本地数据，以利用计算能力和尖端工具。

也许你会反问：“那又有何不妥？”虽然多次数据复制存在着一长串潜在风险，包括数据溯源、变更管理、性能和存储成本效益等问题；我在这里举一个简单的例子：

想象一下，本可以通过维护一个单一的日记来管理日常活动；然而，你的妻子创建了一个“家庭”日历，你的秘书从你的单一日记中又创建了一个“工作”日历。或许在多花一些时间进行额外的管理后，这种方式仍然可以运行；但如果你的妻子决定在你的家庭日历中在上班时间购物，而这与你的工作日历发生了冲突呢？

需要考虑的事项：

• 是否需要在不同层面创建额外的数据副本？
• 我们是否可以利用API？是否可以使用实时连接？是否可以采用虚拟化数据仓库？甚至考虑采用微服务架构吗？

五、环境同步的挑战

现代架构通常采用严格的环境分段，典型地包括开发（DEV）、用户验收测试（UAT）和生产（PROD）环境。尽管很多公司正在积极采用最新的技术，如公有云（AWS、Azure、GCP）和基础架构即代码（IaC，例如Terraform），但它们仍然将生产环境托管在公司的防火墙之后，即本地环境。

我不会在这里详细讨论持续集成/持续交付（CI/CD）方面的挑战，因为已经有许多专家深入探讨了部署流程的问题。我要强调的是，确保在所有平台之间实现“工具、配置和库”的同步是至关重要的。

想象一下，你在Azure上开发了一款出色的模型，利用GPU进行计算，使用TensorFlow框架和Databricks；然而，当你尝试将相同的模型部署到生产环境时，你发现只有CPU虚拟机，没有TensorFlow，也没有Databricks... 这不是笑话，而是来自真实项目的经验。

需要考虑的事项：

• 我们是否拥有一个综合的架构，覆盖了公有云、本地和云内的环境？它们是否拥有同步的工具、库和配置？
• 如果上述情况是否是否定的，我们将如何管理跨不同平台的部署？

六、未受控的IaC环境

基础架构即代码（IaC）软件，如Terraform，为自动设置和配置虚拟化基础设施带来了极大的灵活性。然而，它也带来了一个未受控的虚拟化基础设施的风险，可能导致出现“隐藏”的或“空闲”的节点。

需要考虑的事项：

• 我们是否在IaC自动化代码中设置了适当的控制措施？例如，是否要求强制执行生态系统配置？是否在所有节点之间实施了严格的隔离？
• 我们是否定期扫描整个由IaC创建的基础设施，并清理掉空闲的节点？

七、弱或没有遥测功能

上述问题可能自然引发有关遥测的讨论。与安全框架中的问题一样，遥测方面通常在整个架构设计的较晚阶段才被引入。

一个强大/预配置的遥测组件可以支持架构师在设计过程中，并且最重要的是，它可以提高终端用户对平台的可见性，最终成为平台治理的重要组成部分。

需要考虑的事项：

• 我们的架构中是否包括独立的遥测组件？
• 如果没有，我们是否可以借助更广泛的基础架构中的遥测组件？例如，安全、审计或合规性方面的遥测组件。

八、混淆：只通向一方的单程票？

多年来，数据混淆一直是一个备受关注的话题，我确信几乎所有的数据平台都将面临这一挑战，尤其是在从公有云查询本地数据或实施用户权限隔离时。

虽然有许多聪明的机制可以用于数据混淆，但并非所有这些机制都能够实现双通道——也就是以安全的方式启用/逆转掩码算法。

一些解决方案甚至会对物理数据造成永久性的损害，但随后它们必须构建更复杂的机制来与受损数据匹配，这将引入不必要的流程和成本。

需要考虑的事项：

• 我们是否可以在虚拟环境中使用由安全密钥管理的可逆算法进行数据混淆？
• 如果不可避免地需要进行物理/永久性数据混淆，那么在罕见的情况下恢复它将产生什么成本？

我相信上述常见错误并不能构成一个排他性的列表，希望大家在未来的架构设计项目中避免重复掉入这些陷阱。