开发人员在任何软件项目过程中都会做出数百个微观和宏观决策。有些似乎相对无害,但对下游会有一个很大的影响。几位Cantina工程师聚在一起,回顾了我们在学习了一些艰苦的课程后需要特别考虑的关键点。
利益相关者要求
您作为架构师或系统设计师的首要任务几乎总是让 所有必要的利益相关者 尽快发现需求。
这些需求在项目的初始阶段可能是最难获得的。虽然这种担忧通常与看似最后一刻的审计和安全要求有关,但请记住上下文规则。
数据读/写平衡
在决定如何构建可伸缩Web应用程序时,关键的首要决策是了解数据存储可能需要的读写平衡:
数据一致性
我们中没有一个人可以逃脱 CAP定理 !
但只有在出现系统故障,网络故障或其他无法满足三元组的分区(P)元素时才会发挥作用。在这种情况下,应用程序设计人员和架构师必须提出一个棘手而棘手的问题:这个产品可以更好地容忍哪些,一致性失败或可用性失败?
领域/数据模型
在考虑指定系统应该是什么业务领域时(参见 域驱动设计 ),应该考虑系统的上下文 - 允许通过系统传递的非 上下文 固有的信息作为文档而不是作为领域模型的一部分。
例如,采用一个系统将天气数据返回给用户,但该系统也从另一个第三方服务获取该数据。
解决方案可能会寻求保持从第三方返回的数据,并将其领域复制为自己的领域。这将迫使架构管理一个更复杂的领域,该领域具有许多可能永远不会使用的关系,但必须随着时间的推移而维护。
通过将较小的关系数据库与文档存储相结合,它还将模糊改善数据访问性能和简单性的潜力。
像这样的问题可以通过 端口和适配器 等范例来解决。通过完全理解系统的领域而不包括领域环境不固有的信息,架构师能够做出能够极大地提高设计性能和可维护性的存储技术决策。
负载的可变性
在灾难或公共事件期间接收大量负载峰值的API(例如Facebook)将具有与从空气质量传感器接收预期的每小时度量标准的要求截然不同的要求。
利用可以有效计量请求的体系结构(队列,热表等)可以缓解这些问题中的一些问题。
如果数据一致性不是系统中最重要的问题(如前所述),那么复制数据系统可以帮助在请求进行负载平衡或智能路由时保持单一入口点的压力。
虽然 无服务器计算 提供了诸如内置扩展等显着优势,但它需要更多纯函数的无状态代码结构。对于新系统的绿地greenfield实施,这可能没问题,但迁移遗留系统可能是一个挑战。