方案 1 - 架构全局规模和安全访问
在以下两个单元中,你将查看两个业务方案。 公司说明、项目目标和约束已经为你列出。 你可自行对其进行处理,但如果可能的话,与他人进行头脑风暴可能会很有趣。
开发解决方案的流程
在这些情况下,并且很可能在现实世界中,你的目标是了解以下内容:
- 公司需要解决的问题。
- 与解决方案一起使用的任何要求和约束。
此目标通常采用“问题陈述”的形式。 它是一组正式段落,明确定义解决方案的情况、当前条件和预期结果。 在这一点上,你要避免探索如何解决问题,而要专注于你想解决的问题。
在你(很可能还有你的团队及利益干系人)对于问题陈述达成一致后,你应该为项目提出尽可能多的要求/目标(只要找得出)。 然后在解决方案中加入任何约束。
在这一点上,就算约束不切实际,也是可以接受的。 之后,你可以在显示每个要求和约束的成本/收益率后撤回这些约束。
在生产中,通常有六个阶段来创建解决方案。 形成问题陈述只是开始。
- 发现:客户对问题的原始陈述。
- 展望:对于项目成功的呈现形式的畅想性描述。 通常用“我可以…”这样的语句进行表述。
- 体系结构设计会话:初步解决方案技术选项和选择的初始布局。
- 概念证明 (POC):在选择了用于解决方案的最佳技术和流程之后,将使用小型且具有代表性的解决方案呈现形式示例来设置 POC。 如果并行示例中有当前正在运行的解决方案,则可以使用该解决方案。
- 实现:基于先前阶段的调查结果实现已完成解决方案的分阶段推出。
- 移交:对项目进行事后反思,并讨论未来可在哪些方面进行增强。
在本模块中,你可以利用项目模板和最新图标。 也可以在生产工作负载中使用这些资产。
对于本模块中的情况,你将花一些时间确定问题陈述(发现)。 但重点将放在“体系结构设计会话”上。 如果希望在模块之后进一步开发解决方案,可使用模块中的资产执行此操作。
方案详细信息
你的客户是全球范围内服务和内容分发的提供商。 它要求你帮助构建一个系统,该系统每秒可处理向一个(本质意义上的)操作数据市场的数千次写入。
客户还需要能够对数据执行实时分析,以确定趋势和识别异常。 目前正在使用公共语言运行时 (CLR) 应用程序执行该操作。 客户并不是要寻找数据仓库,也不是要利用大部分的 SQL 外围应用,但需要能够扩展其用户所在的位置。
客户还尝试确定在其混合环境中使用哪些身份验证方法。 尽管主要解决方案和应用程序都将在 Azure 中运行,但客户还需要适应以下各项:
- 加入域的非 Azure 计算机上的应用程序。
- 不允许在非 Azure 计算机上更改驱动程序或连接字符串的旧版应用程序。
- 从未加入域的非 Azure 计算机的 SQL 管理工具(SQL Server Management Studio、Azure Data Studio、PowerShell)运行报表的多个用户。
如果可能,客户希望消除连接字符串和应用配置文件中的硬编码密码或机密。 它希望在 SQL 工具中无需使用密码,或者找到一种增强身份验证的方式。
方案指南
- 从与用户当前解决方案最兼容且当前可用的 Azure SQL 部署选项开始。
- 客户如何在将读取工作负载与写入工作负载隔离的同时,在多个查询同时发生的情况下扩展到多个区域?
- 客户如何跨不同的部署访问数据?
- 对于方案中所述的交互路径,你会推荐哪些身份验证方法?
任务
在查看场景和所提供的指导后,请为项目提出尽可能多的要求(只要找得出)。
列出可能会在解决方案中使用的可能的技术和过程。 请随意在需要进行明确的地方对方案进行调整以获取更多信息。 在这种情况下,你可以进行假设。
提示
对于安全方面的挑战,你可以考虑使用 Azure SQL 安全性最佳做法 Playbook。
使用决策矩阵或其他决策过程,选择将构成初步解决方案的技术和过程。
做一些可说明你的项目目标、约束以及推荐的解决方案设计的笔记。
在脑海中有了初步的解决方案之后,下一步通常是将其呈现给更大的团队(或客户,或领导,视方案而定)。 你需要以一种共享项目目标和约束的方式来组装和呈现你的解决方案,并说明你的解决方案将如何解决这些事项。
准备就绪后,请回答以下问题,以评估你的解决方案与示例解决方案相比有何不同。 可能存在多个正确答案,因此,即使你的解决方案未列出,其也可能是可行的。