设计原则 — 现代应用开发

应用架构的优秀实践。

 

全部展开 全部收起

    • 尽可能使用低代码平台;如不可行,则使用成熟的编程语言和轻量级框架

      概述
      您用于构建应用的编程语言和框架决定着您能否成功交付和长期维护应用。选择何等语言和框架,对扩展业务、运行应用以及为客户交付高质量功能有着长远的影响。通常而言,更换语言或框架会消耗巨额成本。但是,盲目追求多种并行的生态系统(即多种语言和框架)也会导致复杂性升高,敏捷性下降。

      语言和框架的选择会影响诸多因素,包括交付速度、现有生态系统的稳定性和优势、运营准备情况和生产绩效。尽可能使用低代码平台,这样您就可以专注于解决业务问题,无需分心应对传统开发过程中的复杂性。如果您的应用需求复杂程度较高,可选择成熟的语言和轻量级框架。

      原则详细信息
      相比传统的手动编码方式,低代码平台可帮助您更快地构建、测试和部署企业应用。它们不仅非常适合您与企业利益相关者合作构建临时应用,适合构建报告和分析应用,低代码平台还可帮助您扩展 SaaS 应用以及对原有应用进行现代化改造。使用低代码方法,您可以消除复杂性,轻松添加添加新功能,例如数据可视化、数据收集、数据分析、安全性、可访问性、性能和全球化。得益于大大降低复杂性,低代码平台可以大幅减少代码维护工作。

      但是,如果您的应用需求复杂程度较高,请选择使用成熟的编程语言和轻量级框架。在选择编程语言时,尽量选择具备以下关键优势的语言:

      • 安全
      • 高性能和高效率
      • 工具支持
      • 丰富、最新的文档
      • 库生态系统
      • 符合测试套件或参考实施规范
      • 强大社区

      较新的语言的语言设计以及相应的生态系统和库往往具有更高的变动率。这意味着更加难以评估风险,后续更改的成本也更高。

      在选择框架时,尽量选择开源框架。开源框架经历了同行的持续检验,吸取众多开发人员的创建和维护经验构建而成,其功能符合大多数开发人员的需求和预期。您可快速发现并修复漏洞。此外,您还需要选择占用资源(如 CPU、内存、网络带宽或文件句柄)较少的轻量级框架。

      您所采用的应用框架应当能够在优化任务重点(业务逻辑优于样板和基架)和保持灵活性(支持您满足当前和未来的功能需求)之间取得平衡,并针对日志记录、遥测、安全、配置和通用模式(如构建 REST API)等常见功能提供易于使用、合理且无争议的默认值。

      Oracle 建议
      Oracle APEX 是一个低代码平台,它不仅提供丰富的高级组件,例如表单、图表和 UI 小部件,还提供通用设计模式和直观的图形开发环境。使用 APEX 开发的应用可以通过 SQL 访问本地数据,并使用 REST API 与外部服务集成。此外,您还可以将您在 APEX 中开发的功能发布为 REST API 以供外部使用。

      如果低代码平台不适合您的应用,您可以选择 Java 编程语言。Java 为常见的应用程序用例提供了一组稳定而广泛的功能,并拥有用于开发现代应用程序的受信任和稳定的库和框架的健康生态系统。Java 专注于简单性和可读性,并且精心支持开发人员工具(包括静态分析工具和测试框架),降低了软件维护成本以及生产应用中的错误风险。

      使用 GraalVM 开发和运行应用。GraalVM 是一个 JDK 发行版,它能够通过动态运行时优化、主动且高频率的安全漏洞修补以及 Java Flight Recorder 等低成本的性能分析和诊断工具,同时提供 Java 的稳定性与强大性能。

      请使用 Graal Development Kit for MicronautHelidon 框架,采用 API 优先方法来构建应用。这两种方法的基架可以极大地缩短应用交付时间,并针对常见使用场景(例如 REST API)提供简单易用的模式,为日志记录、遥测和存储等常见活动提供简单、无争议的框架选项。此外,它们还通过惯用响应式 API 支持非阻塞 I/O,可确保实现高性能服务;还支持高性能网络库,可实现低延迟。

      • 对于与企业 Java 生态系统密切相关的应用(如 CDI、JAX-RS 或 JPA),请选择 Helidon MicroProfile。Helidon 通过 MicroProfile 标准优先支持现代 Java 企业模式,可简化将现有 Java EE 应用移植到微服务。
      • 对于不依赖现有企业 Java 生态系统的应用,请选择 Graal Development Kit for Micronaut (GDK)Helidon SE。GDK 的编译时应用基架不仅提高了应用运行时性能,还支持框架级检查,可消除许多与反射和运行时配置相关的安全和质量问题。

      Helidon 和 GDK 均内置支持 GraalVM 原生映像,可帮助您构建内存高效的应用和紧凑型应用。

    • 构建通过 REST API 进行通信的应用即服务套件

      概述
      将应用功能或任务拆分成多个相互协作的独立松耦合服务。每项服务承担单一职责,专注于提供一项特性或功能。相比传统的一体化架构,此方法可改善应用维护、功能开发、测试、部署和可伸缩性。

      采用合同优先的 REST API 设计方法提供清晰易懂的接口,用于支持各服务之间的通信。API 合同可为团队提供必要的协作和功能使用机制,无需依赖于服务实施的内部细节。例如,开发团队可以完全拥有一项服务,并自由改进实施,而无需与其他开发团队协调代码依赖关系。

      原则详细信息
      合同优先方法的第一步是指定服务的 REST API,然后对 API 实施进行原型设计,让利益相关方(如使用该服务的团队)进行试用。所有相关方都同意 API 的详细信息后,各团队就可以并行实施该服务以及其它使用该 API 的服务。

      在产品生命周期早期定义安全和服务水平协议的政策执行,以确保所有利益相关方清楚了解服务合同的所有方面。

      将 API 规范与代码一视同仁,使用版本控制系统管理 API 规范、源代码和策略配置。

      Oracle 建议
      使用与实施无关的 OpenAPI 格式指定 API,并将其存储在 Oracle Cloud Infrastructure (OCI) DevOps 提供的存储库中。

      使用 Graal Development Kit for Micronaut 或 Helidon 等轻量级开源方法实施服务。

      OCI Kubernetes EngineOracle Functions 等无服务器平台上部署服务,以简化部署、增强可扩展性和提高成本效益。

      使用 Oracle Cloud Infrastructure API Gateway,基于 API 规范创建受保护和监管的私有或公有端点。

      使用 Oracle Cloud Infrastructure Service Mesh 简化 OCI Kubernetes Engine 集群托管的服务之间的通信,确保通信安全。OCI Service Mesh 还支持您通过其(作为 sidecar 在应用云池中运行的)代理组件所发出的指标和日志来观测服务之间的所有网络流量。

    • 打包应用并部署为容器

      概述
      通过容器将代码及其依赖关系打包成一个单元,让应用可以在多个计算环境中快速、可靠地运行。您可通过执行容器镜像文件在计算环境中创建和启动容器。

      与传统的虚拟机相比,容器更小,需要的资源更少,而且启动时间更快。它们独立于平台,可以在任何地方运行应用。为了利用这些优势,您需要将应用分解成多项服务(每项服务执行一个业务功能),并将每项服务打包成一个容器。对于传统应用,您可以将其中的现有功能逐步替换为容器化服务,直至整个应用被重构。

      原则详细信息
      将应用代码和依赖关系打包成一个可执行单元(容器镜像),赋予容器高度可移植性。通过将这种可移植性与基础设施的抽象性相结合,容器可为应用提供操作一致性。无论应用是在企业内部的物理服务器上运行,还是在云端的虚拟机上运行,它每次都会产生相同的结果。

      通过这种一致的可重复性和可预测性,容器简化了 DevOps 流程,让您的开发团队能够更快地部署应用。此外,由于提供流程级的隔离且经常被替换,容器还简化并加快了与修复软件漏洞相关的流程。应用程序分解成模块化的容器化服务后会变得非常强大。单个服务中的错误或故障不会导致整个应用瘫痪,而且您可以单独更新或修补每项服务。

      与虚拟机不同,容器内部并未随带操作系统,而是共享主机的操作系统。因此,容器的体积更小,启动速度比虚拟机快。大多数容器镜像的大小为几十兆字节,而虚拟机的大小为几千兆字节,其启动时间为几秒钟,而不是启动虚拟机所需的几分钟。

      在容器中使用模块化服务运行和扩展应用的理想方式是在每个容器中只部署一个服务。这种方法将服务相互隔离,从而消除了停机时间,并使每个服务能够独立扩展。

      尽管您可以手动部署容器,但最好使用与连续集成工具和连续部署工具相集成的容器管理软件。

      Oracle 建议
      使用 Oracle Cloud Infrastructure Registry(即 Container Registry)来存储您的容器镜像,使用 Oracle Cloud Infrastructure Kubernetes Engine 来运行和管理容器。这些全托管式服务与 OCI 平台功能紧密集成,在所有 Oracle Cloud 区域可用,满足 PCI、ISO、SOC、HIPAA 和 FedRAMP 等监管要求。

      除了在 Container Registry 存储容器映像之外,您还可以存储清单列表(有时称为多架构映像)以支持多种架构,例如 ARM 和 AMD64。为了识别和减少潜在的安全漏洞,可以对上传到 Container Registry 的所有镜像启用镜像扫描。您还应该对容器镜像进行签名,以确保只有经过授权和信任的镜像被部署到 OKE。

    • 自动构建、测试和部署

      概述
      持续集成 (CI) 和持续部署 (CD) 是一套工具和程序,可供开发团队频繁、可靠地交付代码变更。CI/CD 优秀实践包括代码审查,以及对单元测试、集成测试、代码签到、提交票据和将应用部署到开发和测试环境的指导。

      持续集成是一种软件开发实践,指开发人员频繁将代码变更集成到共享信息库主干。每次集成都通过创建构建,然后对构建运行自动测试来验证开发人员变更,从而确保您的应用不会在新变更集成到主干时发生中断。

      持续集成的优势包括:

      • 自动测试可尽早识别回归故障,减少引入到生产环境中的漏洞
      • 尽早解决集成问题,简化构建流程
      • 更加快速、轻松地检测和定位错误(每项变更通常都很细微)

      持续交付是在持续集成的基础上,将通过相应测试的构建自动交付至测试和/或生产环境,目的是让代码库随时准备好部署至客户生产环境。

      持续交付的其它优势包括:

      • 自动执行复杂部署,帮助您的团队减少发布准备时间
      • 更频繁的发布有助于加速客户反馈循环
      • 细微变更的决策压力更小,从而加快迭代速度

      持续部署比持续交付更进一步,它可将每一项通过所有测试的变更自动部署到客户生产环境,而无需人工干预。未通过测试的新变更将无法部署到生产环境。由于无需人工干预,因此持续部署高度依赖于设计良好的测试自动化。

      持续部署的其它优势包括:

      • 无需暂停发布,可加快开发速度
      • 通过改善质量和持续改进流程来提高客户满意度

      CI/CD 提供了存储、集成、部署和维护代码的优秀实践,可自动化构建应用。这些优秀实践包括:

      • 运用“左移”范式,注重在软件开发生命周期 (SDLC) 中尽早检测和预防问题。例如,在持续集成期间监视应用的第三方依赖项,以了解漏洞。
      • 使用基于 Git 的代码库来存储所有代码资产,并使用不可变的工件服务来存储任何派生的资产。
      • 为了实现持续集成,每天至少一次将所有代码合并到“候选发布”分支。将代码合并到该分支时,确保自动触发构建。作为构建管道的一部分,请先运行所有单元测试并立即修复任何管道故障,然后再在候选发布分支中进行进一步开发。进行代码安全扫描以检测漏洞。不要存储任何存在漏洞问题的构件。在进一步开发之前,先修复候选发布分支中的所有漏洞。
      • 为了实现持续部署,自动将候选发布版本交付到测试环境中,或者使用金丝雀部署。当测试部署通过后,自动将其推广到正式生产。如果测试部署失败,请立即解决问题,然后再在候选发布分支中进行进一步开发。使用安全功能作为部署的一部分,以防止未经授权和脆弱的工件被部署在基础设施上。
      • 在生产环境中,使用监控工具来评估已部署应用程序的健康状况,并检测任何部署后的漏洞。如果发现任何问题,实施自动回滚到以前的版本。在部署后环境中执行安全检查,并立即解决检测到的任何问题。

      Oracle 建议
      使用 DevOps 服务自动部署您的云原生应用。首先,将代码存储在 DevOps 代码库中并创建一个发布分支。以小批量的方式对发布分支进行修改,并每天协调分支中的问题以保持其稳定性。然后,使用代码库中的触发器功能来自动启动 DevOps 构建管道。

      使用一个 DevOps 构建管道来构建与代码库相关的所有构件。如果构建失败,配置构建管道,使其在完成之前等待批准。批准请求应该交给触发构建的提交者,他们应该提交新的代码来解决这个问题,然后批准构建完成。对于成功的构建,配置构建管道以自动交付构件到 Oracle Cloud Infrastructure Artifacts Registry 服务,并自动触发 DevOps 部署管道。

      在 OCI DevOps 构建管道的构建阶段,添加应用依赖项管理来检测应用依赖项中的安全漏洞 (CVE)。通过这种方法,您将能够在发现潜在 CVE 后立即进行检测和补救。

      使用 Resource Manager 在一个最大安全区域内创建您的所有基础设施环境,自动获得部署安全性优势。通过使用 Resource Manager,您可以使用基础设施作为代码,以一致的方式在所有区域内自动创建基础设施。然后,您可以配置 DevOps 部署管道,使其始终部署到您在安全区创建的资源。

      创建一个单一的 DevOps 部署管道,部署从单一构建管道创建的所有构建。组织部署环境,例如 OCI 区域、可用性域和故障域。使用金丝雀、滚动或蓝绿部署策略来配置管道。您也可以将管道配置为自动触发测试。启用 OCI MonitoringApplication Performance Monitoring 来检测应用和基础设施问题。

      如果没有检测到问题并且测试成功完成,配置部署管道以自动将工件部署到部署策略中的下一个环境,直到构件完全部署到所有生产环境。当部署到生产环境时,配置该管道以一次部署到可用性域中的所有故障域。一次部署到一个区域中的所有可用性域中,然后再一次部署到所有区域。继续在应用和基础设施上使用 OCI Monitoring 和 Application Performance Monitoring,以快速检测问题。设置预警,如果任何关键指标在部署过程中突然下降,自动认定部署失败并触发回滚到前一个版本。

    • 使用托管服务消除应用开发和运行中的复杂性

      概述
      托管服务可提供特定功能,且无需您执行优化性能、可用性、扩展、安全性或升级等维护任务。借助托管服务,您可以集中精力为客户提供出色功能,而不必担心运营复杂性。

      托管 OCI 服务可为云原生开发提供可扩展、安全的组件。您可以使用托管服务来开发和运行应用并存储数据;即便不具备专业知识,您也可以使用同类优秀的解决方案来构建和运行应用。

      原则详细信息
      借助托管服务,您可以创建高度可用、可扩展、敏捷且高性能的应用,同时实现安全性、合规性和弹性。

      托管服务降低了应用底层组件的复杂性,可助您轻松存储和检索数据以及创建和运行应用。这些服务还集成了支持自动构建、测试和部署应用的工具集,可助您提高工作效率并加快产品上市速度。

      托管服务可集中并自动化执行各种基础设施管理任务,从而消除人为错误和专业技能需求。底层基础设施将及时更新,安全性高,您可以监视和跟踪修改或访问,以保障应用和数据的机密性和完整性。

      托管服务提供高可用性和可扩展性,可以轻松满足您的应用需求,并且您只需按使用付费。您可以先从小规模开始部署,然后按需扩展,且性能或可靠性不会出现任何下降。

      Oracle 建议
      我们建议采用以下云技术服务:

      • Oracle Autonomous Database,用于管理数据仓库或事务处理的数据。Oracle Autonomous Database 提供具有自治优势的内存、NoSQL 和 SQL 数据库,可降低管理开销。
      • Oracle Cloud Infrastructure Kubernetes Engine 适用于创建、运行和管理容器。
      • Oracle Functions,以安全、隔离的方式创建、运行和扩展短期运行的应用,无需管理任何基础设施。
      • Oracle API Gateway,用于基于 API 规范创建受保护和治理的私有或公有端点。
      • Oracle Cloud Infrastructure Object Storage,用于安全、可靠地存储或检索任意内容类型的非结构化数据。它支持无缝扩展,且性能或可靠性不会出现任何下降。
      • Oracle Cloud Observability and Management Platform 服务与上述所有服务相集成,可深入洞悉日志、指标和事件。
      • Oracle Application Express (APEX),用于快速构建低代码、数据驱动的现代应用。APEX 可以大幅提高可用性和可扩展性,满足不断变化的低代码应用需求。它支持简单的自动化管理、稳定的高性能和自动扩展。

      这些服务均具备高水平的可用性、性能和弹性。其底层基础设施由 Oracle 进行管理和修补,可确保您的应用始终处于安全状态。

    • 使应用层保持无状态

      概述
      应用状态包含许多元素,包括数据缓存、用户偏好、个性化、服务之间交换的信息、多步骤工作流程中的位置、应用部署、运行时配置以及用户会话(例如,用户上次访问的页面或者用户购物车规模和其中的商品)。如果应用状态丢失,则可能会导致数据丢失、应用故障、用户体验欠佳,有时还会造成应用完全停机。

      如果将应用状态存储在本地文件系统或单个主机的内存中,一旦应用发生故障(例如重启或本地化磁盘故障),应用状态就可能丢失。解决方法就是将状态保存在外部持久性存储中。但为了确保数据一致性,您需要使用尽可能少的持久性存储,最好是仅使用一个持久性存储。

      原则详细信息
      应用状态的元素通常存储为各种格式的多个构件,例如序列化对象、JSON 或 XML 文档或文本文件。如果这些元素存储在多个持久性存储(例如外部文件系统、消息存储、对象存储、多个数据库或弹性块存储)中,则不同数据存储可能会不同步,从而导致状态不一致。应用还必须实施事务、联接和幂等性策略,从而确保在需要以单元形式更新状态时提供数据一致性。

      将应用状态元素分散到多个存储中会导致安全漏洞几率增加。生命周期操作,例如添加和删除节点、打补丁、备份和恢复以及灾难恢复复制非常复杂,并且需要特别注意,以确保不同门店的状态保持一致。

      因此,最好能够将所有应用状态和数据存储在一个数据库中。数据能够在单个存储中保持一致,并更容易管理。使用此方法可以替换应用实例。这尤其有利于弹性微服务或临时实例等现代应用架构,其中一个实例仅为单个或几个请求提供服务。添加节点是简化操作,因为新节点可以获取状态的最新副本并删除节点不会完全丢失状态。只需替换可执行文件,就可以以滚动方式应用补丁程序。节点可以从备份中恢复,并从数据库中获取状态。状态可以作为一个单元持续地复制到不同的区域,以便用于灾难恢复。不同区域保持一致状态可以确保故障转移或切换后应用不会出现任何功能问题。

      Oracle 建议
      如果您的应用使用数据库,那么请使用一个数据库来存储应用状态。相比其它选项(如文件或内存中表示),数据库可提供更高的可用性、完整性和安全性。理想方式是使用可以存储不同格式的多模型数据库来存储应用状态的所有元素。相比使用多个专用数据存储,多模型数据库可以轻松实现和维护所有应用状态元素的一致性。(注意:尽管在应用程序中存储缓存状态是允许的,但应用程序必须被设计成使用数据库作为真理的来源,并能够从数据库中重新创建其状态。)Oracle Database 是实现这一目的的理想选择。它可以存储不同的格式,并提供可预测的性能,因此将应用状态存储在其中并不会降低应用性能。

      对于未使用数据库的应用,请考虑使用 Oracle Cloud Infrastructure Object Storage 等其它持久性存储来存储状态。如果应用状态不能保存在单个数据存储中,请将应用状态存储在可以在发生故障后保持同步并恢复为一致单元的多个数据存储中。

      下面是有关在 Oracle Database 中存储状态的一些建议。

      • 用户会话对象状态:使用 JSON 对象/关系映射,如 JPA 或关系表。
      • 本地数据高速缓存:对于在应用层中高速缓存的数据,信息源应来自于数据库。高速缓存应在应用启动时或根据需要重建。缓存更新应使用 write-behind 方法来更新后端数据库。应将更改通知应用实例中的其它高速缓存实例,以便刷新高速缓存。
      • 应用配置数据:这些是构件,例如连接端点、限制、日志级别、日志目的地和端口号,通常存储为 JSON 文档、XML 文件或属性文件。使用适当的数据类型可将此数据存储在数据库中。
      • 进程间通信或远程进程调用:应用微服务和组件之间通常使用消息进行通信。使用 Oracle Database 事务队列使此类消息具有持久性,并确保在发生故障时仍然能够保留并处理消息。
      • 文本(例如审计日志记录):应用会生成日志文件,如审计日志和诊断日志。使用 Oracle Text 功能集中存储此类日志。
      • 性能监视: 应用会生成用于性能监视的指标或时间序列数据。使用 Oracle Database 时间序列数据或 JSON 数据功能存储此类数据。
      • 工作流状态:某些工作流引擎将应用状态存储在本地,此类工作流进行故障转移后可能会导致状态丢失。使用数据库中的工作流引擎可避免此类问题。至少,将工作流引擎配置为将数据库用作其状态的持久性存储。
    • 使用功能全面的融合数据库处理所有数据

      概述
      您的应用可能会使用多种格式的数据,例如表格(关系)、非结构化、XML、JSON、空间或图形数据。通常每种数据格式都需要不同类型的数据库。例如:关系数据库用于存储关系数据,文档存储用于存储非结构化数据,图形数据库用于存储分层链接数据。但是,使用多个数据库通常会导致操作复杂度增加和数据不一致。因此,理想方式是使用一个多模型数据库来存储、索引和搜索多种类型和格式的数据。

      利用数据库功能简化应用逻辑。例如,将 SQL 用于查询、联接和分析;使用事务处理来确保一致性和隔离;使用内置的机器学习算法和分析功能来避免不必要的数据传输。要保护敏感数据,请使用数据库的安全功能和访问控制,并使用复制来提高应用的可用性、可扩展性和弹性。

      原则详细信息
      使用多模型数据库存储不同类型的数据,例如 JSON 文档、属性图形和关系数据。高级多模型数据库可全面支持数据库中存储的任何类型的数据。您可以存储新的 JSON 文档、插入关系行并更新同一 ACID 事务处理内的所有属性图。可以使用 SQL 语句来联接、筛选和聚合这些不同类型的数据,这可以保证您习惯于关系数据库的一致性和并发性。除了提供这些丰富的功能之外,多模型数据库还可以用作单用途数据存储,您可以使用 SQL 之外的 API(例如 REST API、文档存储 API 和图形 API)访问这些数据库。

      使用多模型数据库的一个关键优点是可重用性。尽管数据可能具有不同的类型和配置,但管理这些数据的底层技术是一样的。这意味着,您不必学习多种数据库技术,也不必了解如何针对每种数据使用和优化数据库技术。由于技术是不变的,您也不必重写应用代码。此外,多模型数据库还可以减少数据碎片,提高应用弹性,更轻松地进行备份和恢复。

      Oracle 建议
      使用多模型融合数据库 — Oracle Autonomous Database 存储、管理和分析所有数据。使用视图在表中显示数据,轻松维护应用,在不影响现有应用的情况下更改基础 schema。使用基于版本的重新定义,让您无需停机即可升级应用。使用 Oracle Data Safe 实施和评估安全控制、屏蔽敏感数据和审计数据访问。使用 Oracle Data Guard 作为高度可扩展的数据读取高速缓存,确保灾难恢复备份一致。

      Oracle Autonomous Database 执行运营任务时不会影响或中断工作负载。这意味着您不需要在应用中添加复杂的补偿逻辑来处理扩展或故障转移场景。数据库独立管理 CPU 和存储等资源,并提供弹性和双向可扩展性。

    • 仪器端到端监控和追踪

      概述
      单一用户请求可以追踪构成现代应用的多个服务或微服务的复杂路径。端到端跟踪是指追踪每个请求从来源传输至基础设施内部的路径,并帮助您从根本上解决问题。Monitoring 通常用作诊断工具,以便在应用无法正常运行时提醒开发人员。

      开发人员、管理员和安全官必须保持权威并及时了解应用的运行状况、性能、运行状态和可能发生的安全事件,以确保应用的功能和性能在其生命周期中满足预期要求,并简化事件诊断和应用恢复。全面的端到端监视和跟踪应当能够直接实施和管理,而不会增加应用复杂性。

      原则详细信息
      应用可能无法按预期方式运行。例如,可能性能不佳或者彻底无法运行。不同于传统单体应用,基于微服务构建的应用会因组件之间的多种交互而带来更多的诊断挑战。

      跟踪可以帮助您快速了解用户请求在通过微服务和基础设施等其它应用组件时的动态,也是查明问题最为行之有效的方式。使用端到端跟踪收集每个用户请求的数据,然后检查数据以确定您的应用可能遇到哪些瓶颈和延迟。例如,在履行之前,请求可能会通过多个微服务来回传递。如果无法跟踪请求的整个路径,则无法确定故障的根本原因。

      Monitoring 通常更具针对性,可检测应用行为,然后收集、聚合和分析指标,从而帮助您增强对应用行为的了解。端到端监视还支持智能、自动化地与工具集成,以动态调整资源容量并协调应对意外事件。

      清晰、准确、及时地了解应用运行状态和历史记录并不仅仅是为了衡量最终用户体验。您可能还需要遵守地区或国家的司法管辖权,能够生成关于处理特定敏感数据元素的详细活动报告或证明。

      一般来说,监视解决方案应当能够兼容第三方工具,尤其是与您的环境管理工具保持一致。保持设计灵活性并避免供应商锁定十分重要。

      Oracle 建议
      从一开始就在应用中构建全面的监视和跟踪功能,并在整个生命周期中保持稳定一致。这些功能不应增加开发、测试和部署的复杂性,并且应易于部署和管理。尽可能采用可扩展的解决方案,以适应您当前使用和将来可能部署的多种平台。

      OCI 服务(如 Monitoring)旨在提供开箱即用的监视支持。您还可以通过 API 和 SDK,利用一致的部署和管理经验将许多 OCI 服务扩展到您的应用组件。例如,您可以使用所有虚拟机和应用的集中存储来添加自动监视指标收集或日志捕获。

      在开发和测试期间,您可以将服务配置为仅收集基本调试或性能测试信息。在进行生产部署时,再对现有配置参数进行简单更新以扩大信息收集范围,增强频率和可跟踪性。

      Oracle Cloud Infrastructure Service Mesh 可自动捕获在 OCI Kubernetes Engine 中运行的服务的各种通信指标和日志。您可以使用这些数据来跟踪服务的运行状况并提高应用性能。

      在整个云租户环境中使用强大的集中式数据收集,为分析、协调调查和警报生成提供单一信息源。Service Connector Hub 可以对事件提供灵活、一致和可定制的响应。OCI Logging Analytics 支持高效分析和调查您的所有云端(以及外部)事件日志系统。您还可以使用 OCI Service Connector Hub、Functions 和 Notifications,将摄取的指标和日志转换为切实可行的警报。您可以利用我们与第三方产品和服务(如 Splunk 和 Grafana)的集成。

      以下 OCI 服务可帮助您整合应用托管环境中的日志、监视和跟踪:Logging、Monitoring、Logging Analytics、Application Performance Monitoring、OS Management、Database Management 和 Java Management Service。这些全托管服务与常见 OCI 基础设施资源实现了集成,并且提供支持机制来集成您的定制应用资源。

    • 通过自动数据复制和故障恢复消除单点故障

      概述
      单点故障是指应用中的某个组件发生故障,导致您的整个应用无法使用或出现性能波动。在开发具备高可用性和高可靠性的应用时,您可以使用自动数据复制来确保单一组件发生故障不会导致数据丢失。

      通过跨计算机的数据复制以及冗余网络,您可以预防日常计算机和网络故障。在多个地理区域的数据中心(或“可用性域”)中复制数据可以有效防范局部灾难,例如火灾、地震、洪水或飓风。

      原则详细信息
      为了让应用实现高可用性,您需要确保在发生故障时,应用所依赖的数据仍然可用。实现数据高可用性的关键是通过自动数据复制实现冗余。

      复制是指在分布式数据库系统的多个数据库中复制和维护数据库对象(如表)的过程。系统会先捕获一个站点的更改并存储在本地,然后转发并应用于其它远程位置的各个副本。

      复制数据库可在两种不同的模式下运行:主动 - 被动和主动 - 主动。在主动 - 被动模式下,有一个主副本和一个或多个辅助副本,只有主副本参与应用数据处理。在主动 - 主动模式下,所有副本都参与数据处理。主动 - 主动模式不需要主辅助故障转移,因此可实现更高的资源利用率和可用性。

      冗余可确保数据副本故障不会影响整体运行。计算机或磁盘故障通常是独立的,但网络或电源故障可能会导致一组计算机同时发生故障。为了防止发生此类事件,网络和电源基础设施应具有冗余性,并且数据副本必须小心放置在几个不会同时发生故障的位置。

      Oracle 建议
      OCI 数据中心经过精心设计,能够有效消除单点灾难性故障。典型的数据中心或可用性域包含多个称为容错域的独立故障单元。两个独立的容错域不能一起出故障。同样的,单个区域可能具有多个可用性域,这些可用性域在地理位置上是分开的,以确保其中两个可用性域不会同时发生故障。

      使用 OCI 存储服务(如 Block Volumes、Object Storage 和 File Storage)在容错域和可用性域中复制数据,避免出现单点故障影响应用数据的可用性。利用 OCI Kubernetes Engine 充分发挥 OCI 中内置的弹性故障隔离优势,将应用部署在多个容错域和可用性域中。Oracle Autonomous Database、Data Guard 和 GoldenGate 提供双活软硬件复制,支持高可用性以及零停机打补丁和升级。您可以使用这些托管服务确保数据的高可用性,且无需构建和维护存储基础设施。

    • 实施自动化纵深防御,保护您的应用及数据安全

      概述
      纵深防御方法指实施多层独立、冗余的安全控制策略作为应用防御层。即使其中的某一个层发生故障,其它层仍然能够提供安全保障,例如,结合使用防火墙与入侵检测技术。

      然而,无论是从局部还是整体来看,手动管理和配置安全控制策略都极为复杂、不透明且容易出错。所以最好能够使用自动化安全控制策略来保护您的应用和数据安全。

      原则详细信息
      使用涵盖物理、技术、管理、运营、人员和程序安全元素的各种控制措施实现纵深防御,有效管理风险。这些相互独立的控制措施组成了纵深防御,可有效应对故障、漏洞或其它安全风险。这些控制措施通过不同方式管理风险,并提供日志记录、审计和其它功能,能够检测到安全违规并将其报告给适当的利益相关者。

      相比手动配置一组复杂的安全控制,我们建议您使用简单、规范的自动化控制来保护应用安全。自动化安全控制可消除导致许多安全事件的人为错误,您无需成为安全专家,也能够保护您的应用和数据安全。

      Oracle 建议
      在应用生命周期的所有阶段(包括开发、构建、测试、部署和运行时)实施简单易用的自动化安全控制。验证生命周期中每个步骤的用户、权限和访问策略,并确保仅在适当的时候授予访问权限。检测软件开发生命周期早期引入的安全问题。早期检测可确保应用在生产环境中使用安全架构优秀实践进行部署,并检测和缓解因配置错误或公开漏洞而导致的运营安全问题。

      OCI 提供多重自动化安全服务来可靠保护您的应用和应用数据。下面是关于使用 OCI 服务的一些建议:

      • 使用 Web 应用防火墙 (WAF) 限制来自未知位置的流量。对于传输层安全 (TLS),对负载均衡器和自动注释使用证书。在每个提供 HTTPS 内容的负载均衡器上启用 WAF。启用 Oracle 管理的规则并支持误报。使用地理 IP 访问规则限制没有业务往来的国家 / 地区的流量。在 WAF 中使用威胁情报来阻止 Tor 节点。
      • 使用 Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) 实现身份优先的安全方法,轻松引导和管理用户。在应用前端使用 OCI IAM 通过强身份验证方法对用户进行身份验证,同时通过情境感知自适应安全、可选社交或联合登录或无密码身份验证(取决于要求)提供出色的用户体验。使用户能够管理他们对使用条款的同意并支持数据驻留要求,从而支持监管要求。在后端使用 OCI IAM 根据需要限制对应用组件的访问。通过强大的多重验证 (MFA) 选项为管理员强制验证。强制实施严格的安全策略,仅允许通过显式授予的权限进行访问。通过职责分离,只有需要的人员才能获得访问仅限。
      • 使用具有硬件安全模块加持的 OCI Vault 中存储的密钥对数据执行静态加密。建议为每个服务使用单独的加密密钥,但 (OCI) Vault 实体与隔间保持一致。至少每三个月轮换一次主加密密钥和数据密钥。在生产环境中使用专用 Vault,并在辅助区域中复制密钥。创建备份并将其存储在独立区域中的 Oracle Cloud Infrastructure Object Storage 中。保护加密密钥的安全,并仅允许应用程序所有者授权访问密钥。
      • 使用内置的安全主体授权计算实例对其它 OCI 服务执行操作。
      • 使用 OCI 虚拟云网络 (VCN) 中的网络安全组功能,强制实施与端点隔离的最小可访问性原则。在每个 VCN 上启用 Netflow 日志记录。监控加密挖掘活动或命令和控制服务器活动的 DNS 日志记录。
      • 使用 Oracle Security Zones 在默认安全配置中启动应用。对使用专用子网的隔间提供最大安全区域。确保操作员能够通过 Oracle Cloud Infrastructure Bastion 访问专用子网中的任何计算实例。
      • 启用 Oracle Cloud Guard,解决或接受/禁用所有问题。数据安全功能还可以扫描数据库,获取安全优秀实践,并发出有关数据差异的警报。
      • 启用 Oracle Data Safe,通过监视用户和访问来保护 Oracle Database。Data Safe 还可以扫描数据库,获取安全优秀实践,并发出有关数据差异的警报。
      • 使用 Oracle Cloud Infrastructure Vulnerability Scanning Service 定期扫描实例和容器,找出已知的安全问题。
      • 使用 OCI Service MeshOCI Kubernetes Engine 集群中服务之间的通信执行身份验证和加密。OCI Service Mesh 还支持您配置访问策略,以控制服务间通信并验证外部请求。

注:为免疑义,本网页所用以下术语专指以下含义:

  1. 除Oracle隐私政策外,本网站中提及的“Oracle”专指Oracle境外公司而非甲骨文中国 。
  2. 相关Cloud或云术语均指代Oracle境外公司提供的云技术或其解决方案。