針對企業的需求而建置Build for the needs of the business

每個設計決策必須對應合理的商務需求Every design decision must be justified by a business requirement

此設計原則似乎是顯而易見的,但在設計解決方案時請謹記。This design principle may seem obvious, but it's crucial to keep in mind when designing a solution. 您預期會有數百萬名或幾千名使用者?Do you anticipate millions of users, or a few thousand? 是否可接受一小時的應用程式中斷?Is a one-hour application outage acceptable? 您是否預期流量有大量高載或可預測的工作負載?Do you expect large bursts in traffic or a predictable workload? 最後,每個設計決策必須對應合理的商務需求。Ultimately, every design decision must be justified by a business requirement.

建議Recommendations

定義商務目標,包括復原時間目標 (RTO)、復原點目標 (RPO),以及最大可容忍中斷 (MTO)。Define business objectives, including the recovery time objective (RTO), recovery point objective (RPO), and maximum tolerable outage (MTO). 決策人員應該了解架構相關的這些數字。These numbers should inform decisions about the architecture. 例如,為了達成低 RTO,您可能會將自動容錯移轉實作到次要區域。For example, to achieve a low RTO, you might implement automated failover to a secondary region. 但是,如果您的解決方案可以容忍較高的 RTO,可能就不需要該程度的備援。But if your solution can tolerate a higher RTO, that degree of redundancy might be unnecessary.

文件服務等級協定 (SLA) 和服務等級目標 (SLO),包括可用性和效能計量。Document service level agreements (SLA) and service level objectives (SLO), including availability and performance metrics. 您可能會建立可提供 99.95%可用性的解決方案。You might build a solution that delivers 99.95% availability. 這足夠嗎?Is that enough? 答案是業務決策。The answer is a business decision.

針對商務網域建立應用程式的模型Model the application around the business domain. 從分析商務需求開始。Start by analyzing the business requirements. 使用這些需求來建立應用程式的模型。Use these requirements to model the application. 考慮使用網域導向設計 (DDD) 方法來建立可反映商務程序和使用情節的網域模型Consider using a domain-driven design (DDD) approach to create domain models that reflect the business processes and use cases.

擷取功能及非功能性需求Capture both functional and nonfunctional requirements. 功能需求可讓您判斷應用程式的行為是否正確。Functional requirements let you judge whether the application does the right thing. 非功能性需求可讓您判斷應用程式的行為是否執行 良好Nonfunctional requirements let you judge whether the application does those things well. 特別是,請確定您了解您的擴充性、可用性和延遲需求。In particular, make sure that you understand your requirements for scalability, availability, and latency. 這些需求會影響設計決策和技術的選擇。These requirements will influence design decisions and choice of technology.

依工作負載分解Decompose by workload. 「工作負載」一詞在此內容中是指不連續的功能或計算工作,可利用邏輯方式與其他工作分隔。The term "workload" in this context means a discrete capability or computing task, which can be logically separated from other tasks. 不同工作負載在可用性、延展性、資料一致性和災害復原方面可能有不同的需求。Different workloads may have different requirements for availability, scalability, data consistency, and disaster recovery.

規劃成長Plan for growth. 解決方案可能符合您目前的需求,就使用者數目、交易數量、資料存放區等而言。A solution might meet your current needs, in terms of number of users, volume of transactions, data storage, and so forth. 但是,健全的應用程式在沒有重大架構變更下即可以處理成長。However, a robust application can handle growth without major architectural changes. 請參閱相應放大的設計分割處理限制See Design to scale out and Partition around limits. 也請考慮您的商務模型和商務需求將可能隨著時間變更。Also consider that your business model and business requirements will likely change over time. 如果應用程式的服務模型和資料模型太僵化,要針對新使用情節和情節演化應用程式會變得太困難。If an application's service model and data models are too rigid, it becomes hard to evolve the application for new use cases and scenarios. 請參閱進化的設計See Design for evolution.

管理成本Manage costs. 在傳統的內部部署應用程式中,您需支付預付硬體的費用。In a traditional on-premises application, you pay upfront for hardware as a capital expenditure. 在雲端應用程式中,您需支付所使用的資源。In a cloud application, you pay for the resources that you consume. 確定您了解所使用之服務的價格模型。Make sure that you understand the pricing model for the services that you consume. 總成本將包含網路頻寬使用量、儲存體、IP 位址、服務使用,以及其他因素。The total cost will include network bandwidth usage, storage, IP addresses, service consumption, and other factors. 如需詳細資訊,請參閱 Azure 價格For more information, see Azure pricing. 也請考慮您的作業成本。Also consider your operations costs. 在雲端中,您不必管理硬體或其他基礎結構,但仍然需要管理您的應用程式,包括 DevOps、事件回應、災害復原等。In the cloud, you don't have to manage the hardware or other infrastructure, but you still need to manage your applications, including DevOps, incident response, disaster recovery, and so forth.