保持简单
 避免过度设计体系结构设计、应用程序代码和操作。 |
|---|
它通常是你要移除的内容，而不是要添加的会生成最可靠解决方案的内容。 简单性减少了要控制的表面，最大程度地减少了效率低下现象和潜在的配置错误或意外交互。 另一方面，过度简化可能会引入单一故障点。 保持平衡的方法。
示例方案
Contoso Travel 将要收购并整合一家拥有基于 Web 的热门旅游应用的小型初创公司。 该应用受欢迎的原因是由于其与连锁酒店和航空公司协商大幅折扣的商业模式，以及利用社交媒体开展的密集而极具针对性的营销活动。
初创公司产品的现有版本是使用 nodejs 开发的，运行在托管在本地数据中心和 AWS 之间的 VM 上。
最大程度地减少工作负载组件
仅当组件有助于实现目标业务价值时，才会将组件添加到体系结构。 精简关键路径。
针对业务需求进行设计可能会生成易于实现和管理的简单解决方案。 避免使用太多关键组件，因为每个组件都是一个重要的故障点。
Contoso 的挑战
- 新收购应用程序的一个组件有助于在用户预订后直接在网站上收集其反馈。 此功能很少使用，因为大多数用户只是跳过它。 用户拥有一种强大的反馈循环机制，它通过公司社交媒体帐户运行，主要用于营销用户交互。 此机制的使用频率明显高于网站的反馈功能。
应用方法和结果
- 作为应用添加 Contoso Travel 品牌后的初始版本的一部分，团队决定移除工作负载的网站反馈组件。
- 较小的代码库降低了维护和操作的成本。 并且在此案例中并未影响业务需求。
标准化软件开发生命周期
在代码实现、部署和流程中建立标准，并记录这些标准。 使用自动化验证确定强制实施这些标准的机会。
标准可提供一致性并最大程度地减少人为错误。 标准命名约定和代码样式指南等方法可以帮助你保持质量，并在故障排除过程中可轻松识别资产。
Contoso 的挑战
- 来自初创公司的开发团队没有定义许多开发和过程标准。 正在使用的许多库功能重叠，未强制执行编码样式，发布管道缺少使用自动测试的正式发布入口。
- Contoso 工作负载团队意识到由于样式缺乏一致性以及对库和设计模式的不一致使用，新代码库的维护成本过高，。
- 生产中进行重大更新后经常发生事件，有时需要回滚更新或在部署中途进行热修复。 此类部署问题的频率迫使团队在发布生产更新时使用全员参与的支持模型。 更糟糕的是，常见问题通过糟糕的用户体验对 Contoso 的声誉产生负面影响。
应用方法和结果
- 该团队接管了对新应用的支持工作，并通过强制执行编码样式、标准化一组通用库和设计模式，以及基于自动测试正式使用发布入口，努力实现更高的一致性。
- 在实施这些更改时，工作负载团队坚持遵循其标准文档要求。 对于所有正在采用的新工具、设计模式和样式进行全面记录，从而支持团队更有效地了解和维护工作负载。 现在，团队可以在执行代码评审时更轻松地识别标准中的偏差。
最大程度地减少运营和开发负担
利用平台提供的功能和预生成资产，这些资产可帮助你有效实现业务目标。
此方法可最大程度地减少开发时间。 它还支持你采用已用于类似工作负载的已经过试用和测试的做法。
Contoso 的挑战
- 对于 Contoso Travel 品牌下的初始版本，nodejs 解决方案将从 VM 迁移到应用服务，以利用该服务提供的许多本机可靠性功能。
- 在 VM 上部署的版本包含大量检测所需的自定义代码。
应用方法和结果
- 在向应用服务进行初始迁移期间，团队能够通过在应用服务中实现 App Insights 自动检测来移除所有自定义检测代码。
- 团队还能够利用多项其他本机应用服务功能，例如自动缩放、密钥保管库集成和区域冗余。