設計原則 - 現代化應用程式開發

簡介
此程式設計語言與架構可協助您建置 App，讓您在 App 的成功交付和維護中扮演重要角色。您選擇的語言和架構，將會長期影響您的業務擴展能力、應用程式運作成效，以及為客戶提供高品質功能的能力。語言或架構的變更通常非常耗時。支援多種語言和架構的平行生態系統，將會增加複雜性，並降低靈活性。

語言與架構的選擇會影響一系列因素，包括交付速度、現有生態系統的穩定性及強度、營運整備程度，以及生產效能。盡可能使用低程式碼平台，讓您專注於解決業務問題，而不需解決傳統開發所帶來的複雜問題。如果您的應用程式需求較為複雜，請選擇成熟的語言與輕量級架構。

原則詳細資訊
低程式碼平台可讓您比傳統手動編碼更快速地建置、測試及部署企業應用程式。這些平台很適合用來與業務利害關係人協作建置商機應用程式，以及資料報告與分析應用程式。低程式碼平台也可用來擴充 SaaS 應用程式，並將舊版應用程式現代化。當您想要新增功能時，這個方法可以協助您避免複雜的作業，例如資料視覺化、資料收集、資料分析、安全、輔助功能、效能及全球化。低程式碼平台大幅降低了這些複雜性，並大幅減少了您需要維護的程式碼數量。

但是，如果您的應用程式有更複雜的需求，請選擇與輕量型架構結合的成熟程式設計語言。選擇程式設計語言時，請挑選可為您提供關鍵優勢的語言，例如：

• 安全性
• 高效能與效率
• 工具支援
• 廣泛且最新的說明文件
• 程式庫生態系統
• 測試套件或參照實作的規範
• 強大的社群

程式語言越新，其設計方式以及對應生態系統與程式庫方面的變化速度就越快。變化速度越快，風險評估將會更加困難，後續變更成本也會越高。

選擇架構時，請選擇開源架構。開源架構會持續接受同行審查，其功能因此更貼近大多數開發者的需求，因為他們參與了架構的建立和維護過程。每當出現錯誤時，都能迅速發現並修復。此外，您還應該選擇消耗較少資源 (例如 CPU、記憶體、網路頻寬或檔案控制碼) 的輕量級架構。

選擇能夠兼顧提高任務專注度 (優先處理業務邏輯，而非規劃與編程) 和靈活性 (可同時支援目前和未來的功能需求) 的應用程式架構。採用一個架構，為一般功能 (例如記錄日誌、遙測、安全、組態) 及一般模式 (例如建置 REST API) 提供容易使用、合理及沒有爭議的預設值。

Oracle 建議
Oracle APEX 是低程式碼平台，提供表單、圖表和 UI 小工具等高階元件。APEX 還透過直觀式圖形開發環境，提供常見的設計模式。使用 APEX 開發的應用程式，可以透過 SQL 存取本機資料，並使用 REST API 與外部服務整合。此外，您也可以將您在 APEX 中開發的功能發布為 REST API，以供外部使用。

如果低程式碼平台不適用於您的應用程式，請採用 Java 做為您的程式設計語言。Java 為大多數常見的應用程式使用案例提供穩定且廣泛的功能，並擁有健全穩定、值得信賴的程式庫與架構生態系統，可用於開發現代化應用程式。Java 注重簡潔特質和可讀性，再加上對開發人員工具 (包括靜態分析工具和測試架構) 提供強大支援，降低了軟體維護成本和生產應用程式中出現錯誤的風險。

使用 GraalVM 開發和執行您的應用程式。GraalVM 是一個 JDK 發行版本，透過動態執行時期最佳化、頻繁主動修正安全弱點，以及低成本的效能分析與診斷工具 (例如 Java Flight Recorder)，讓您同時享有 Java 的穩定性與一流的效能。

選擇 Graal Development Kit for Micronaut 或 Helidon 架構，使用 API 優先的方式建置應用程式。這兩種方式都提供框架生成 (scaffolding) 功能，大幅減少為常見使用案例交付應用程式和容易使用模式 (例如 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 設計方式，為服務之間提供清晰且容易理解的介面。API 合約可為團隊提供協同合作與使用功能的必要機制，而不需視服務的導入內部明細而定。例如，服務可以由開發團隊全資擁有，因此可以自由改善實作，而無須與其他開發團隊協調程式碼相依性。

原則詳細資訊
指定服務的 REST API，從合約優先方法開始。然後製作 API 的原型實作，以讓利益關係人 (例如將使用 API 的團隊) 試用。當每個人都同意 API 的詳細資訊時，獨立團隊可以並行工作來實行服務和其他將使用之服務。

在產品生命週期的初期就定義安全和服務層次協議的政策強制實行項目，以確保每個人都清楚服務合約的所有方面。

將您的 API 規格視為程式碼，並透過版本控制系統以及原始程式碼和原則組態進行管理。

Oracle 建議
使用不限實施格式的 OpenAPI 指定您的 API，並將其儲存在「Oracle Cloud Infrastructure (OCI) DevOps」提供的儲存區域中。

使用輕量的開源方式 (例如 Graal Development Kit for Micronaut 或 Helidon) 實作您的服務。

在無伺服器平台 (例如「Oracle Container Engine for Kubernetes」或「Oracle Functions」) 上部署您的服務，以簡化部署、取得可擴展性及符合成本效益。

您可以使用 Oracle Cloud Infrastructure API Gateway，從 API 規格建立受保護且受管理的專用或公用端點。

使用 Oracle Cloud Infrastructure Service Mesh 簡化和保護 Oracle Container Engine for Kubernetes 叢集中代管服務之間的通訊。OCI Service Mesh 也可讓您透過代理主機元件 (在應用程式 Pod 上以 Sidecar 形式執行) 所發出的指標和日誌，觀察服務之間的所有網路流量。

簡介
容器封裝程式程式碼及其依存關係，讓應用程式在多個運算環境間快速可靠地執行。容器映像檔是一個檔案，執行後會在運算環境中建立並啟動容器。

相較於傳統虛擬機器，容器較小、需要較少的資源，以及啟動時間較快。他們也是獨立的平台，可以在任何地方執行應用程式。若要善用這些優點，請將您的應用程式分解為各項服務，以容器身分執行個別的業務功能並封裝每項服務。對於傳統應用程式，請逐步以容器化服務取代您應用程式中的每個現有功能，直到整個應用程式重新建構為止。

原則詳細資訊
將應用程式程式碼與相依性封裝成單一可執行單元 (容器映像檔) 代表容器極度可攜。藉由將此可攜性與基礎架構抽象化結合，容器就能為您的應用程式帶來操作一致性。不論您的應用程式是在實體伺服器上執行，還是虛擬機器上的雲端執行，每次都會產生相同的結果。

透過這個一致的可重製性和可預測性，容器可簡化 DevOps 流程，讓您的開發團隊能夠更快速地部署應用程式。提供程序層次的隔離，以及因為經常被取代的容器，能夠簡化並加速與修復軟體弱點相關的程序。將應用程式細分為模組化容器化服務時，也會使它們非常健全。個別服務發生錯誤或故障並不會影響整個應用程式，而您可在應用程式的其餘部分獨立更新或修正每項服務。

與虛擬機器不同，容器不是它自己的作業系統；而是共用其主機的作業系統。因此，容器比虛擬機更小，啟動速度更快。相較於可達到數 GB 的虛擬機器，大部分容器映像檔的大小為數十個 MB，且其啟動時間是以秒為單位，而非啟動虛擬機器所需的分鐘數。

使用容器中的模組化服務執行並調整應用程式的最佳方式，就是在每個容器上部署一個服務。此方法會將服務彼此隔離，從而消除了停機時間，並為每個服務啟用獨立擴展。

雖然您可以手動部署容器，但是最好使用與持續整合及持續部署工具整合的容器管理軟體。

Oracle 建議
使用 Oracle Cloud Infrastructure Registry (Container Registry) 來儲存容器映像檔，以及使用 Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) 來執行及管理容器。這些完全受管理的服務與 OCI 平台功能緊密整合，在所有 Oracle Cloud 區域均提供，並符合 PCI、ISO、SOC、HIPAA 及 FedRAMP 等法規標準。

除了將容器影像儲存在容器登錄中之外，您還可以儲存清單清單清單清單 (有時稱為多架構影像) 以支援多個架構，例如 ARM 和 AMD64。若要識別並降低潛在的安全性弱點，請在上傳至容器登錄的所有影像上啟用影像掃描。您也應該簽署容器映像檔，以確保只將授權和信任的映像檔部署到 OKE。

總覽
開發團隊使用持續整合 (CI) 與持續部署 (CD) 這組工具和程序，以頻繁、可靠地交付程式碼變更。CI/CD 最佳實務作業包括程式碼複查、單元測試的準則、整合測試、程式碼存入、存檔回報項目，以及將應用程式建置到開發和測試環境。

持續整合會說明一個實務作業，其中開發人員會頻繁將其程式碼變更整合到共用儲存區域的主要分支。開發者變更會先建立組建，然後針對組建執行自動測試，以驗證這些變更。測試可確保每當有新的變更整合至主要分支時，您的應用程式就不會中斷。

持續整合的優點包括：

• 自動測試會偵測迴歸失敗，較少的錯誤在生產中運送到生產環境
• 整合問題會提前解決，讓組建流程更容易
• 錯誤的偵測速度較快且更容易 (因為每個變更通常很小)

持續交付是超出持續整合的重要一步；透過適當的測試後，組建會自動傳遞至測試和 (或) 生產環境。持續交付的目標是隨時準備好可部署至客戶生產環境的程式碼庫。

持續交付的其他優點包括：

• 複雜部署的自動化，代表您的團隊花費較少的時間來準備核發
• 更頻繁的版本，加速客戶意見回饋迴圈
• 快速重複，因為對小改變的決策施加壓力較少

持續部署會比持續交付方式進一步；所有透過測試的變更都會自動部署到客戶生產環境。沒有人為介入 - 只有失敗的測試可以阻止新變更部署到生產環境。沒有人為介入，持續的部署依賴良好的測試自動化。

持續部署的其他優點包括：

• 由於無須暫停發行版本，因此提高開發速度
• 提升客戶滿意度是因為品質和持續提升效率

CI/CD 提供儲存、整合、部署及維護程式碼的最佳實務作業，以自動化您建置應用程式的方式。這些最佳實務作業包括下列各項：

• 應用「左移」典範，並專注於在軟體開發生命週期 (SDLC) 中儘早偵測及防止發生問題。例如，監控應用程式的第三方相依性，以取得持續整合期間的漏洞。
• 使用以 Git 為基礎的程式碼儲存區域來儲存所有程式碼資產。使用不可變的使用者自建物件服務來儲存衍生的的資產。
• 若要實行連續整合，請每天至少將所有程式碼合併至「釋出候選版本」分支一次。當您將程式碼合併至該分支時，請確定組建已自動觸發。在組建管線的過程中，執行所有單位測試並立即修正任何管線失敗，再於版本候選分支中進一步開發。在程式碼中使用安全掃描以偵測漏洞。不要儲存任何有漏洞問題的使用者自建物件。在進一步的開發前，先修正版本適用分支中的所有漏洞。
• 若要實作持續部署，請自動將版本適用者傳遞給測試環境或使用便利部署。測試部署通過時，會自動將它們提升為完整生產。如果測試部署失敗，請先立即解決問題，再於版本適用者分支中進一步開發。使用安全功能作為部署的一部分，以避免在基礎架構上部署未授權和漏洞的使用者自建物件。
• 在實際執行環境中，使用監督工具評估已建置應用程式的狀況，並偵測任何後續建置漏洞。如果偵測到任何問題，請實行自動倒回至先前的版本。在部署後環境中執行安全檢查，並立即解決任何偵測到的問題。

Oracle 建議
使用「DevOps 服務」自動部署雲端原生應用程式。首先，將程式碼儲存在 DevOps 程式碼儲存區域中，然後建立版本分支。進行小型增量以變更核發分支，並每天調節分支中的問題以確保其穩定性。然後使用程式碼儲存區域中的觸發程式功能，自動啟動 DevOps 組建管線。

使用單一 DevOps 組建管線來建立與程式碼儲存區域關聯的所有使用者自建物件。如果組建失敗，請設定組建管線在完成前等待核准。核准要求應移至觸發建置的確認者，且應使用新程式碼確認來解決問題，然後核准建置完成。若是成功的組建，請設定組建管線，以自動將使用者自建物件傳遞至 Oracle Cloud Infrastructure Artifacts Registry 服務，並自動觸發 DevOps 部署管線。

新增「應用程式相依性管理」，以在 OCI DevOps 建置管線的建置階段偵測應用程式相依性中的安全漏洞 (CVE)。如此一來，您就能夠偵測潛在 CVE，並在其變成已知時立即修正。

使用資源管理程式，在最高安全性區域中建立所有基礎架構環境，以自動受益於部署安全性。透過使用資源管理程式，您可以使用基礎架構作為程式碼，以一致的方式自動建立您所有區域的基礎架構。接著，您可以將 DevOps 部署管線設定為您已在安全區域中建立的資源。

建立單一 DevOps 部署管線，以部署從單一組建管道建立的所有使用者自建物件。組織部署環境，例如 OCI 區域、可用性網域以及容錯網域。使用固定、滾動或藍綠色的建置策略設定管線。同時設定成自動觸發測試。在您的應用程式和基礎架構上啟用 OCI 監控和 Application Performance Monitoring 以偵測問題。

如果未偵測到任何問題並順利完成測試，請將部署管線設定為自動將使用者自建物件部署到部署策略中的下一個環境，直到所有實際執行環境中完全部署使用者自建物件為止。部署到生產環境時，請將管線設定為一次部署至可用性網域中的所有容錯域。一次部署到區域中的每個可用性網域，然後一次部署到每個區域。繼續在應用程式和基礎架構上使用 OCI 監督和 Application Performance Monitoring，以快速偵測問題。設定警示，如果建置期間有任何主要測量結果突然刪除，建置就會自動失敗並觸發倒回上一個版本。

簡介
受管理的服務提供特定功能，不需執行與最佳化效能、可用性、擴展、安全性或升級相關的維護工作。藉助管理式服務，您可以專注於為客戶提供功能，無需擔心複雜的營運。

受管理 OCI 服務提供可擴充的安全元件，以進行雲端原生開發。使用管理式服務開發及執行您的應用程式並儲存其資料；您無須具備每個網域的專業知識，即可取得業界最佳的解決方案，以建置及操作您的 應用程式。

原則詳細資訊
受管理的服務可讓您建立具有安全性、規範及抗逆力的高可用性、可擴展性、靈活性和高效能應用程式。

管理服務會抽象化您應用程式的基礎元件，讓您輕鬆儲存及擷取資料，或建立並執行應用程式。此服務與提供應用程式自動建置、測試及部署的工具集整合。管理式服務可提高生產力並縮短產品上市時間。

託管服務可集中和自動化各種基礎架構管理作業，排除人為錯誤以及對專業技能的需求。基礎基礎架構會保持在最新和安全的狀態，而服務可讓您監控和追蹤修改或存取，確保應用程式和資料的機密性與完整性。

管理式服務具有高可用性且可擴展性，可符合應用程式的需求，而且只需依據使用量付費。您可以從小規模開始著手，無須體驗任何效能或可靠性的降低。

Oracle 建議
建議您使用下列雲端服務：

• Oracle Autonomous Database 可管理資料倉儲或交易處理資料。Autonomous Database 提供記憶體內、NoSQL 和 SQL 資料庫，讓您充分利用自治式的優勢降低管理負荷。
• Oracle Cloud Infrastructure Container Engine for Kubernetes，以建立、執行及管理您的容器。
• Oracle Functions 可建立、執行及調整為短期持續時間執行的應用程式，完全不需要管理任何基礎架構。
• Oracle API Gateway 可從您的 API 規格建立受保護及治理的專用或公用端點。
• Oracle Cloud Infrastructure Object Storage 可安全且安全地儲存或擷取任何內容類型的非結構化資料。此服務可順暢調整，不會發生任何效能或服務可靠性的降低情況。
• Oracle Cloud Observability and Management Platform 服務會與上述所有服務整合，以便能夠檢視日誌、測量結果和事件的可見性。
• Oracle Application Express (APEX) 可快速建立低程式碼現代化的資料導向應用程式。這些服務具有高可用性、高效能和靈活度。它除了提供自動化管理功能之外，還提供一致的高效能、自動調整規模及易於管理的管理功能。

這些服務具有高可用性、高效能和靈活度。他們的基礎基礎架構受到管理和修補，以確保您的應用程式安全無虞。

總覽
應用程式的狀態可包含許多元素，包括資料快取、使用者的偏好設定、個人化、服務之間交換的訊息、多重步驟工作流程中的位置、應用程式部署、程式實際執行組態以及使用者的階段作業 (例如，使用者上次瀏覽的頁面或使用者購物車中的大小和項目)。如果您的應用程式狀態遺失，可能會導致資料遺失、應用程式發生故障、使用者體驗不佳，有時甚至造成應用程式完全故障。

如果您將應用程式的狀態儲存在本機檔案系統或單一主機的記憶體中，如果應用程式發生中斷 (例如重新啟動或本地化磁碟故障)，則可能會遺失該應用程式。請改為將狀態儲存在外部持續性存放區。盡可能使用較少的持續性商店；最好只一個，以提供資料一致性。

原則詳細資訊
應用程式狀態的元素傳統上會以各種格式 (例如序列化物件、JSON 或 XML 文件或文字檔) 儲存成多個使用者自建物件。如果這些元素儲存在多個永久存放區 (例如外部檔案系統、訊息存放區、物件存放區、多個資料庫或彈性區塊儲存)，則不同的資料存放區可能會不同步，並造成狀態不一致。必須將狀態更新為單元時，應用程式也必須實行交易、結合以及等冪，以確保資料一致性。

藉由在多個商店散發應用程式狀態的元素，增加安全漏洞的機會。生命週期作業，例如新增和移除節點、修正、備份與復原，以及複製災害與復原會變得極為複雜，需要特別考量以維持不同存放區的狀態一致性。

如此一來，更好的方法是將所有應用程式的狀態及其資料儲存在單一資料庫中。資料在單一存放區中能夠保持一致，而且更容易管理。使用此方法，可以取代應用程式執行處理。這特別有助於現代化的應用程式架構，例如彈性微服務或臨時執行處理，這些執行處理只能提供服務來提供單一或幾個要求。新增節點已簡化，因為新節點可以取得狀態的最新複本並移除節點不會導致整個狀態遺失。您可以藉由取代執行檔，以機動方式套用修正程式。您可以從備份回復節點並從資料庫取得狀態。狀態可以一致地以單位複製到不同的區域以進行災害復原。在不同區域呈現一致的狀態，可確保應用程式容錯移轉或切換之後不會有任何功能問題。

Oracle 建議
如果您的應用程式使用資料庫，請使用相同的資料庫來儲存狀態。與檔案或記憶體內表示法相較，資料庫提供了較佳的可用性、完整性和安全性。理想的方式是使用多重模型資料庫 (可儲存不同格式) 來儲存應用程式狀態的所有元素。使用多重模型資料庫，而非多個單一用途資料存放區，可讓您輕鬆達成和維護所有應用程式狀態元素的一致性。(注意：雖然允許在應用程式中儲存快取狀態，但應用程式必須設計為使用資料庫作為事實來源，且能夠從資料庫重新建立其狀態。)Oracle Database 非常適用於此用途。它會儲存不同格式，並且提供可預測的效能，因此將應用程式的狀態儲存起來不會降低應用程式效能。

如果您的應用程式未使用資料庫，請使用其他持久性保存存放區 (例如 Oracle Cloud Infrastructure Object Storage) 來儲存狀態。如果應用程式狀態無法保留在單一資料儲存中，請設計您的應用程式，將狀態儲存在多個資料儲存區中，這些資料儲存區可在故障後保持同步，並復原為一致的單位。

以下是一些儲存 Oracle Database 狀態的建議。

• 使用者階段作業物件狀態：使用 JSON 物件 / 關聯式對應，例如 JPA 或關聯式表格。
• 本機資料快取：對於應用程式層中快取的資料，真值來源應為資料庫。應於應用程式啟動時或視需要重新建立快取。對快取的更新應該使用更新後端資料庫的寫入方法。應用程式執行處理中的其他快取執行處理應該會收到變更通知，以便重新整理快取。
• 應用程式組態資料：這些通常儲存為 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」來儲存、管理及分析所有資料。使用檢視來顯示表格中的資料，以簡化應用程式的維護，以便變更結構描述而不影響您現有的應用程式。使用以版本為基礎的重新定義功能，讓您不必停機就能升級 應用程式。您可以使用 Oracle Data Safe 來實行和評估安全控制項、遮罩機密資料以及稽核資料存取。使用 Oracle Data Guard 作為資料的高擴展性讀取快取，並維持一致的備份以進行災害復原。

Oracle Autonomous Database 可執行作業工作，不會影響或中斷其工作負載。這表示您不需要將複雜的補償邏輯新增至應用程式，即可處理調整或容錯移轉案例。資料庫可獨立管理資源 (例如 CPU 和儲存體)，並提供彈性的雙向擴展性。

簡介
單一使用者要求即可追蹤構成現代應用程式之多個服務或微服務的複雜路徑。端對端追蹤會依照要求來源的過程，深入了解您的基礎架構，並協助您除錯問題的根本原因。「監控」通常用來作為診斷工具，當您的應用程式未如預期般運作時，警示開發人員。

開發者、管理員及安全人員必須維持對您應用程式健康狀況、效能、操作狀態及可能發生安全事件的授權和及時地了解您的應用程式。這種理解可確保您應用程式的功能與效能在生命週期中達到預期；它也能簡化事件診斷與應用程式復原。全方位的端對端監控與追蹤應可直接導入及管理，無須讓您的應用程式變得複雜。

原則詳細資訊
您的應用程式可能因多種原因而無法如預期般運作。例如，它可能效能不佳或根本只是故障。不同於傳統的單體式應用程式，從微服務建置的應用程式會因元件之間的互動而帶來額外的診斷挑戰。

追蹤是透過微服務和其他組成應用程式的元件 (例如基礎架構)，快速瞭解使用者要求發生情況的最佳方法。使用端對端追蹤功能收集每個使用者要求的資料，然後檢視這些資料，以了解您的應用程式可能發生瓶頸和延遲的情況。例如，要求可能在完成前透過多個微服務來回傳。若沒有追蹤要求整個歷程的方式，便無法判斷其故障的根本原因。

「監控」功能通常較為直接，透過帶領您的應用程式儀表及收集、聚總及分析度量，讓您更了解應用程式的行為情況。端對端監控功能也允許與工具的智慧和自動化整合，以動態調整資源容量，並協調對未預期事件的回應。

清楚、準確且及時的了解應用程式的作業狀態與歷史記錄，不只是評估一般使用者體驗。您也可能需要遵循區域或國家司法管轄區，而這些管轄區可能需要能夠產生隨選、詳細的活動報告或有關處理特定機密資料元素之證明。

一般而言，監控解決方案應與第三方工具相容，並特別符合您環境的管理工具。維護設計彈性並避免供應商鎖定是很重要的。

Oracle 建議
在您的應用程式中建置全方位的監控與追蹤功能，並讓它們在整個生命週期中保持一致。這些功能不應該讓開發、測試和部署變得更加複雜，而應該容易實施和管理。在可能的情況下，採用可擴展的解決方案以適應您當前使用和將來可能部署的平台的多樣性。

OCI 服務 (例如 Monitoring) 旨在提供立即可用的監控支援。此外，您還可以使用透過支援的 API 和 SDK 的一致部署和管理體驗，將許多 OCI 服務擴展到您的應用程式元件。例如，您可以為所有虛擬機器和應用程式新增集中儲存的自動化監督測量結果收集或日誌擷取。

在開發與測試期間，您可以設定服務只收集基本除錯或效能測試資訊。當您的應用程式方法是實際執行部署時，請對現有的組態參數進行簡單的更新，以提高收集資訊的範圍、頻率和可追蹤性。

「Oracle Cloud Infrastructure Service Mesh」會為在 Oracle Container Engine for Kubernetes 中執行的服務，自動擷取各種通訊指標和日誌。您可以使用這些資料來追蹤網格中的服務狀況，並改善應用程式效能。

針對整個雲端租用戶環境使用強大的集中式資料收集，提供單一位置進行分析、協調調查和產生警示。Service Connector Hub 可讓事件有彈性、一致和可自訂的回應。您可以利用 OCI Logging Analytics 對所有雲端 (和外部) 事件記錄系統進行有效率的分析與調查。您也可以使用 OCI Service Connector Hub、Functions 及 Notifications，將擷取的指標和日誌轉換成切實可行的警示。您可以利用我們與第三方產品和服務 (例如 Splunk 和 Grafana) 的整合方案。

下列 OCI 服務可協助您合併代管應用程式之環境的記錄日誌、監控及追蹤：記錄日誌、監控、記錄日誌分析、應用程式效能監控、OS 管理、資料庫管理及 Java 管理服務。這些完全管理的服務已與一般 OCI 基礎架構資源整合，並提供支援的機制以整合您的自訂應用程式資源。

簡介
單點故障是應用程式的一個元件，故障時，會將整個應用程式變成無法使用或不可靠。當您開發具有高可用性且可靠性的應用程式時，請使用自動化資料複寫來確保單一元件的失敗不會導致資料遺失。

跨機器進行資料複製和使用備援網路，可以保護您免受常規機器和網路故障的影響。在多個地理區域的資料中心 (或可用性網域) 中複製資料，可保護您避免受到局部性的災害，例如火災、地震、洪水或颶風。

原則詳細資訊
為了讓您的應用程式達到高可用性，您必須確保應用程式在發生失敗時保存可用的資料。資料高可用性金鑰透過自動化資料複寫提供備援。

複製和維護資料庫物件 (例如表格) 的程序，是在構成分散式資料庫系統的多個資料庫中。在一個站台套用的變更會在轉送並套用到位於遠端位置的每個複本之前，先擷取並儲存在本機上。

複製的資料庫可以在兩種不同的模式下運作：主動 - 被動和作用中 - 作用中。在主動 - 被動模式下，單一主要複本與一或多個次要複本；只有主要複本參與應用程式資料處理。在主動 - 主動模式下，所有複本都參與資料處理。作用中 - 作用中模式提供較佳的資源使用和更高的可用性，因為不需要主要秒容錯移轉。

安全備援可確保資料複本獨立失敗。機器或磁碟故障通常是獨立的，但網路或電源故障可能會導致機器群組同時故障。若要保護這類事件，網路和電源基礎架構也應備援，且資料複本必須正確地放置在無法同時故障的不同機器和位置。

Oracle 建議
OCI 資料中心經過精心設計，以避免單一重大故障點。典型的資料中心或可用性網域包含多個獨立的故障單位，稱為容錯域。兩個獨立的容錯域不能同時出現故障。同樣地，單一區域可能會有多個可用性網域 (地理上分隔)，以確保兩個可用性網域不會同時出現故障。

使用 OCI 儲存體服務 (例如區塊磁碟區、物件儲存體以及檔案儲存體)，在容錯域和可用性網域之間複製資料，讓單一故障點不會影響應用程式資料的可用性。透過使用 Container Engine for Kubernetes 將您的應用程式部署至多個容錯和可用性網域，以充分利用 OCI 中的彈性錯誤隔離。Oracle Autonomous Database、Data Guard 以及 GoldenGate 提供主動 - 主動硬體和軟體複製，以提供高可用性，以及零停機時間修正與升級。使用這些管理式服務提供高可用性資料，無須建置和維護自己的儲存基礎架構。

簡介
深度防禦是一種方法，當多個獨立、備援的安全控管措施都可作為應用程式的防禦層級。此多層式設計是為了確保即使其中一層失敗，也能安全無虞；例如防火牆結合了入侵偵測。

不過，安全控制的手動管理與組態可能會非常複雜、不透明，而且容易個別和一致地發生錯誤。使用自動化安全控制，取代保護您的應用程式及其資料。

原則詳細資訊
深度防禦使用涵蓋安全實體、技術、管理、作業、人員及程序元素的各種控制來管理風險。他們的獨立性代表他們提供深入的防禦，處理故障、漏洞或其他安全漏洞。這些控制項的設計目的是為了以不同的方式來處理風險，並提供記錄、稽核和其他功能，以確保偵測到並向適當的利益關係人報告已嘗試的安全違規。

使用簡單但規定的自動化控制來保護應用程式，無須手動設定一組複雜的安全控制。自動化安全控制可消除人為錯誤 (許多安全事故的根本原因)，並協助您保護應用程式及其資料，而不會要求您成為安全性專家。

Oracle 建議
在應用程式生命週期的所有階段 (包括開發、建置、測試、部署和執行階段)，實施容易使用的自動化安全控制。確認生命週期中每個步驟的使用者、權限和存取原則，並確保只有在適當時授予存取權。偵測軟體開發週期早期導入的安全問題。早期偵測可確保以安全架構最佳做法將您的應用程式部署在實際執行中，並偵測到錯誤組態或揭露的漏洞所造成的作業安全問題。

OCI 提供多種自動化安全服務，協助保護您的應用程式及其資料。以下是一些使用 OCI 服務的建議：

• 使用「Web 應用程式防火牆 (WAF)」限制來自不明位置的流量。針對傳輸層安全 (TLS)，使用「適用於負載平衡器的憑證」和自動輪替。在提供 HTTPS 內容的每個負載平衡器上啟用 WAF。啟用 Oracle 管理的規則並調整誤報。使用 geo-IP 存取規則來限制來自與您沒有業務夥伴之國家的流量。使用 WAF 中的威脅情報來封鎖 Tor 節點。
• 使用「Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)」作為身分識別優先的安全方法，讓使用者能夠輕鬆上線與管理。在您的應用程式前端使用 OCI IAM 以強式驗證方法驗證使用者，同時透過內容感知調適型安全、選擇性社交或同盟登入或是無密碼驗證 (視需求而定) 維持最佳使用者體驗。讓使用者能夠管理對使用條款的同意，並支援資料駐留要求，以支援法規要求。在後端使用 IAM，即可視需要限制對應用程式元件的存取。強制管理員透過強大的多重因素認證 (MFA) 選項進行認證。強制實行高度安全原則，僅允許透過明確授予權限存取。分開職責，以便將存取權限限定於需要存取的職責。
• 在硬體安全模組的支援下，以儲存在 OCI Vault 中的金鑰加密靜態資料。您可能偏好為每個服務使用個別的加密金鑰，但請將 OCI 保存庫實體與區間保持一致。至少每年輪換主要加密金鑰，每三個月輪換一次資料金鑰。在生產環境中使用專用保存庫，並在次要區域中複製金鑰。建立備份並將它們儲存在個別區域的 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 資料庫。「資料安全」也會掃描資料庫，以獲取安全最佳實務和分歧警示。
• 使用「Oracle Cloud Infrastructure Vulnerability Scanning Service」，定期掃描執行個體和容器，找出已知的安全問題。
• 使用 OCI Service Mesh 驗證及加密 Oracle Container Engine for Kubernetes (OKE) 叢集中服務之間的通訊。OCI Service Mesh 也可讓您設定存取原則，以控制服務間通訊並驗證外部要求。