azure 最佳实践 -- 随业务演化的架构

随业务演化的架构


每项设计决策必须考虑到业务
这项设计原则虽然看起来很明显，但在设计解决方案时要牢记这一点。你有数百万的用户，还是几千？一小时服务中断是否可以接受？系统会有大并发，还是流量始终比较小并且是可预测的？最终的每个设计决策都必须由业务需求进行说明。


建议做法
定义业务目标，包括恢复时间目标（RTO），恢复点目标（RPO）和容许中断的最大值（MTO）。这些数字应该关系到架构的确定。例如，要实现低RTO，可以实现自动故障功能将故障转移到辅助区域。但是，如果可以容忍更高的RTO，那么冗余度可能就是不必要的（复杂度）。


对服务级别协议（SLA）和服务级别目标（SLO）进行文档化，以及可用性和性能指标。例如构建一个提供99.95％可用性的解决方案。是否足够？答案是由业务来决定的。


围绕业务领域对应用程序进行建模。首先分析业务需求。使用这些需求来建模应用程序。考虑使用域驱动设计（DDD）方法来创建能够反映业务流程和用例的领域模型。


同时考虑到功能和非功能的需求。功能需求能够帮助你判断应用程序逻辑是否正确。非功能性需求可以帮助你判断应用程序是否做好这些事情。尤其是对可扩展性，可用性和延迟的需求。这些需求将影响设计决策和技术选择。


工作量拆分。在这种情况下，术语“工作负载”是指计算任务的计算或拆分能力，可以在逻辑上与其他任务进行分离。不同的工作负载可能对可用性，可扩展性，数据一致性和灾难恢复有不同的要求。


为（业务）增长而设计。从用户数量，交易量，数据存储等方面进行考量，当前解决方案可能满足需求。然而，健壮的应用程序可以处理递增的请求而无需对架构进行大的更改。参阅为扩展而设计以及分区原则，当然还要考虑到业务模式和业务需求会随时间而变化。如果应用程序的服务模型和数据模型过于僵化，那么架构很难随新的用例和场景进行演变。请参阅设计的演变。


管理你的成本。在传统的，部署在本地的应用程序中，需要为硬件（CAPEX）预付款。在云应用程序中，需要支付所消耗的资源。确保你了解所消费的服务定价模型。总成本将包括网络带宽使用，存储，IP地址，服务的使用等要素。有关更多信息，请参阅Azure定价模型。当然，还要考虑你的运营成本。使用云，你不必管理硬件或其他基础架构，但仍然需要管理应用程序，包括DevOps，事件响应，以及灾难恢复等。