按標籤瀏覽 我們已經將詞彙分類。使用篩選器按標籤瀏覽詞彙。
基本原理
基礎設施
安全
屬性
應用程式
方法論
架構
網路
全選 全不選
是什麼 API 閘道器是一個工具， 它聚集了多應用程式的 API，使它們可以透過單一的入口存取。 這使得組織能夠集中處理特定的功能（如身分驗證、授權或限制應用程式之間的請求數量）。 API 閘道器作為的公共介面，來為 API 使用者（通常是外部的）提供服務。
解決的問題 如果您希望為外部使用者提供 API，您通常會希望有一個單一的入口點來管理所有的存取。 此外，API 閘道器可以讓您統一套用功能到所有的流量上，而不需要修改任何應用程式的程式碼。
如何幫助我們 API 閘道器為應用程式中的各種 API 提供了一個單一存取點， 這使得組織能夠在集中處理跨域商業邏輯或安全邏輯，也讓應用程式使用者能夠透過訪問單一地址滿足所有需求。 API 閘道器可以透過為系統中所有Web服務的請求提供單一的存取點來簡化像安全性和可觀測性這樣的運營問題。 由於所有請求都流經 API 閘道器，它可以集中添加功能，如指標收集、速率限制和授權。..
是什麼 DevOps 代表著由團隊擁有應用程式開發（Dev）到正式維運（Ops）完整過程的一種方法論，所以它才被稱作 DevOps。 DevOps 不只是一套技術的運用，更是文化與流程的全面轉變。 DevOps 要求工程團隊專注在更小的元件，而非一次處理整個功能，並且減少交接的次數，因為頻繁的交接正是導致錯誤的常見原因。
解決的問題 傳統上，在具有緊耦合單體式應用程式的複雜組織裡，工作通常分散在不同的團隊之間。 這導致工作需要多次的交接與漫長的前置時間（lead time）。 每當一個元件或更新準備就緒時，它就會被放到下一個團隊的工作佇列中。 由於每個人都只處理專案的一小部分，而這種方法導致缺乏所有權（ownership）。 他們的目標將會是把工作交給下一個團隊，而不是向客戶提供正確的功能，這顯然是本末倒置。
當程式碼終於部署到正式環境，早已經歷了許多的開發人員、在眾多佇列中等待。 假設此時程式碼無法運行，追查問題根因就會是一件非常困難的事情。 而 DevOps 顛覆了上述這種開發方式。
如何幫助我們 讓一個團隊可以擁有應用程式完整的生命週期，可帶來交接次數最小化、降低部署到正式環境的風險、擁有更好的程式碼品質（如果團隊也負起程式碼在正式環境運行的責任）， 並且因為團隊擁有更多的自主權與所有權而提高了員工滿意度。..
是什麼 DevSecOps 一詞指的是開發、維運與安全責任的文化融合。 它擴展了 DevOps 方法，將安全優先事項納入其中，並且對開發人員和維運人員的工作流程帶來最少的干擾，甚至不造成擾亂。 如同 DevOps，DevSecOps 是一種文化的轉變，由採用的技術推動，並有著獨特的採用方法。
解決的問題 DevOps 的實踐包含持續整合、持續交付和持續部署，並加速應用程式的開發和發佈週期。 可惜的是，無法充分體現所有組織利害關係人的自動化發佈流程可能會惡化現存的問題。 一個快速發佈卻沒有考量安全需求的流程可能會降低組織的安全態勢。
如何幫助我們 DevSecOps 關注於破除團隊間的隔閡，以及促進安全與自動化工作流程的建立。 在選擇安全應用程式（工具、解決方案）時，組織必須善用自動化 CI/CD 工作流程和政策的落實，並且為開發者提供支持。 該目標並非成為阻礙者，而是安全政策的落實，同時給予使用者如何使他們的專案向前推展的正確資訊。 當 DevSecOps 被適當地實施，組織將會獲得更好的團隊溝通，並且減少安全事故和附帶成本。..
是什麼 eBPF（延伸柏克萊封包篩選器）是一種允許小型沙盒程式或腳本在 Linux 系統核心空間執行的技術，不需要修改核心原始碼載入 Linux 核心模組。
Linux 系統有兩個空間：核心空間和使用者空間。 核心空間是作業系統的核心，也是唯一可以無限制存取硬體的部分。
應用程式會停留在使用者空間，當它們需要更高權限時，就會向核心發送要求。 對於需要更彈性的應用程式，像是直接存取硬體，核心可以透過所謂的「Linux 核心模組」進行擴充。 這種方式擴充了核心的預設功能，允許應用程式更深度地存取底層元件。 不過，這種方法也會帶來安全風險，因此 eBPF 成為更有吸引力的替代方案。
解決的問題 通常狀況下，應用程式在使用者空間執行，如果應用程式需要核心的某些權限（E.g. 存取某些硬體）， 會透過「系統呼叫」向核心提出請求。 在大多數情況下，這種方法都能正常執行。不過，在某些情況下，開發人員需要更靈活的低階系統存取方式。 可觀察性、安全性和網路功能就是很好的範例。 為此，我們可以使用 Linux 核心模組，在不修改核心原始碼的情況下延伸核心基礎。 雖然使用 Linux 核心模組有很多好處，但也會帶來安全風險。 由於 Linux 核心模組在核心空間內執行，它們可能會導致核心崩潰，而核心一旦崩潰，整個機器也會當機。 此外，核心模組擁有更高的權限，可以直接存取系統資源。如果沒有適當的安全保護，攻擊者就會利用這些漏洞。
如何幫助我們 eBPF 提供比 Linux 核心模組更可控的環境，以執行使用者自訂的程式。 它在核心的沙盒環境中執行，提供隔離並降低風險。 如果漏洞或缺失在 eBPF 程式中被利用，其影響通常僅限於沙盒環境。 此外，在 eBPF 程式開始在核心中執行之前，它必須通過一些驗證。 驗證器元件會檢查 eBPF 程式是否存在潛藏的安全違規行為， 像是違規存取記憶體、無窮迴圈和未經授權的核心函式。 這樣它就能確保程式不會進入無窮迴圈並導致核心崩潰。 與 Linux 核心模組相比，這些安全控制措施使 eBPF 成為在 Linux 核心中執行應用程式更安全的選擇。..
是什麼 Kubernetes （通常縮寫為 K8s）是一個開源的容器協調工具。 它可以在現代基礎設施上自動管理容器化應用程式的生命週期， 就像一個能夠在分散式系統中管理應用程式的「資料中心作業系統」。
Kubernetes 會在叢集的節點間對容器們進行排程， 並結合多個基礎設施上的資源， 例如負載平衡器、持久性儲存空間等等， 來執行容器化的應用程式。
Kubernetes 具有自動化和可擴展的特性， 讓使用者能夠以可重現的宣告式設定來部署應用程式（請見下文）。 經驗豐富的 Kubernetes 從業人員可以根據其需求， 透過它的 API 來利用其自動化功能進行擴展。
解決的問題 長期以來，基礎設施自動化和宣告式設定管理一直是重要的概念， 但隨著雲端運算的普及，這些概念變得更加地迫切。 隨著對運算資源的需求增加， 組織需要更多的維運能力，同時又要更少的工程師數量， 因此新的技術和工作方式便變得不可或缺。
如何幫助我們 Kubernetes 與傳統基礎設施即程式碼的工具類似，都有助於自動化， 但 Kubernetes 具有使用容器的優勢。 因此比虛擬機器或實體機器更不容易出現組態漂移。
此外，Kubernetes 是透過宣告式設定來運作的， 這意味著操作者並非告訴機器應該要執行什麼指令， 而是描述基礎設施應該要長什麼樣子； 通常是透過清單檔案（例如 YAML）的形式來進行描述。 然後，Kubernetes 便會自行完成「如何達成這個樣子」的部分。 這使得 Kubernetes 能很好地相容於「基礎設施即程式碼」。
Kubernetes 還具有自我修復的功能。 叢集的實際狀態將始終與維運者所期望的狀態相符。 當 Kubernetes 偵測到與清單檔案描述不符的情況時， Kubernetes 控制器便會修復這個問題。 雖然 Kubernetes 使用的基礎設施可能會不斷地變化， 但 Kubernetes 會自動不斷地隨之改變， 以確保與期望的狀態保持一致。..
是什麼 Pod 是 Kubernetes 環境中最基本的可部署單位。 它代表部署和管理容器化應用程式的必要組件。 每個 Pod 包含一個應用程式實例，並且可以由一個或是多個容器 所組成。 Kubernetes 將 Pod 視為大規模部署的一部分進行管理，並且可根據需求垂直或是水平地擴展 Pod 的規模。
解決的問題 雖然容器通常作為獨立的單位運行以及控制特定的工作負載， 但是某些情況下，容器間需要以緊密耦合的方式進行互動與被控制。
如果將這些密切相關的容器單獨管理，則會導致冗余的管理任務出現。 舉例來說，操作者必須反覆地確保這些容器彼此的部署狀態以確保他們保持在一起。 此外這些密切相關的容器其生命週期必須一致同步的被處理，但是卻只能各別單獨管理。
如何幫助我們 Pod 將緊密關係的容器們打包成一個單一的單位，此舉大幅度的簡化了容器操作。 譬如，輔助用容器通常都會伴隨主要容器一起使用已加入額外功能或是設定全域設定。 範例包含將基本設定給注入或是套用到主要容器的容器， 以 sidecar 來處理網路流量與路由相關的模式(參見 服務網格)， 或是幫忙收集其他容器日誌的容器。
記憶體和 CPU 配置可以在 Pod 層級去定義，使得容器們可以彈性的方式去共享資源或是針對每個容器去設定。..
是什麼 分散式系統是透過網路連接的自主運算單元的集合，從使用者角度來看是一個單一的一致性系統。 這些一般被稱為節點的元件可以是硬體設備（例如計算機、行動電話）或是軟體行程。 節點經由程式設計以達到一個共同目標，為了協作，它們透過網路交換訊息。
解決的問題 現今大多數的現代化應用程式都非常龐大，需要以超級計算機去運行。像是 Gmail 或是 Netflix。 沒有一台計算機足夠強大到可以承載整個應用程式。 藉由連接多台計算機，運算能力可以變得接近無限大。 如果沒有分散式運算，許多我們目前依賴的應用程式將無法運作。
傳統上，系統可以垂直擴展。也就是在單一機器上增加更多 CPU 或記憶體。 垂直擴展相當耗時、需要停機，而且很快就會達到極限。
如何幫助我們 分散式系統允許水平擴展（例如在需要時對系統增加更多節點）。 這樣可以自動化並允許系統處理突然增加的工作負載或資源消耗。
非分散式系統將自身曝露在故障的風險中，因為如果一台機器故障，整個系統就會故障。 分散式系統可以被設計成，即使一些機器發生故障，整個系統仍然可以保持運作並產生相同結果。..
是什麼 分散式應用程式是一種功能被拆分為多個較小獨立部分的應用程式。 分散式應用程式通常由獨立的微服務組成，以處理更廣泛的應用程式中的不同問題。 在雲端原生的環境中，這些獨立元件通常在叢集中以容器執行。
解決的問題 在單一計算機上執行的應用程式代表單點故障–如果該台計算機故障，應用程式將變得不可用。 分散式應用程式通常作為單體式應用程式的對比。 單體式應用程式可能難以擴展，因為各個元件無法獨立擴展。 隨著單體式應用程式的增長，它們也會拖累開發者的速度，因為更多的開發者需要在未必有明確定義邊界的共享程式碼庫中工作。
如何幫助我們 當將一個應用程式拆分為不同的部分並在許多地方執行，整個系統能夠承受更多的故障。 它也允許應用程式利用單個應用程式實例所不具備的可擴展性，也就是水平擴展。 然而，這也需要付出代價：增加複雜度與營運開銷–你現在正在執行多個應用程式元件，而非單一應用程式。..
是什麼 水平擴展是一種透過加入更多節點而非對單一節點加入更多計算資源來提升系統容量的技術（後者稱為垂直擴展）。 假設我們有一個 4GB RAM 的系統，並且想要提升其容量到 16GB RAM，水平擴展代表的是加入 4 X 4GB RAM 的系統而非切換到一台 16GB RAM 的系統。
這種方式透過添加更多實例或節點來提升應用程式的效能，以達到更好的工作負載。 簡單來說，其目的是減少伺服器的負載而非擴充單一伺服器上的容量。
解決的問題 隨者對應用程式成長的需求超越該應用程式的當前容量， 我們需要找到一種方式來擴展（增加容量）系統。 我們可以加入更多節點到系統中（水平擴展）或是加入更多計算資源到現有節點上（垂直擴展）。
如何幫助我們 水平擴展允許應用程式在底層叢集的限制範圍中去擴展。 透過加入更多的實例到系統中，應用程式能夠處理更多請求。 如果單一節點每秒可以處理 1000 個請求，則每一個額外的節點都能夠讓每秒多處理大約 1000 個請求。 這使得應用程式可在不加入更多容量到任何節點的情況下去同時執行更多工作。
相關詞彙 垂直擴展 自動擴展..
從雲端原生的角度來看，可靠性是指系統對故障的反應能力。 如果我們有一個具備在基礎設施發生變化且單一元件發生故障時仍可繼續運作的分散式系統，那麼它就是可靠的。 另一方面，如果它很容易出現故障，並且需要操作人員手動干涉才能使其繼續運行，那它是不可靠的。 雲端原生應用程式的目標即是建立本質上可靠的系統。..
可擴展性指的是一個系統能夠擴大成長的能力， 也就是增加系統執行其預定功能的能力。 舉例來說， Kubernetes 叢集透過增減容器化應用程式的數量來擴展， 但這種可擴展性取決於幾項因素。 它擁有多少個節點？ 每個節點可以處理多少個容器？ 以及控制平面能夠支援多少記錄和操作？
可擴展性的系統使增加容量變得容易。 主要區分為兩種擴展方法。 其中之一， 水平擴展添加更多節點以處理增加的負載。 相比之下， 在垂直擴展中， 單個節點有更強大的功能以執行更多的事務（例如，透過為單個機器添加更多記憶體或 CPU）。 具備可擴展性的系統能夠輕鬆地進行變更，以滿足使用者的需求。..
可觀察性是一個系統屬性，其定義了系統能夠產生可執行見解的程度。 它允許使用者從這些外部輸出去理解系統狀態並採取行動來修正。
計算機系統通過觀察低階信號（例如 CPU 時間、記憶體、磁碟空間）以及更高階和業務信號（包括 API 回應時間、錯誤、每秒交易次數等）進行衡量。 這些可觀察的系統通過專業工具，即所謂的可觀察性工具，進行觀察（或監控）。 這些工具的列表可以在 Cloud Native Landscape 的可觀察性部分 中查看。
可觀察的系統向操作人員提供有意義且可執行的資料，使他們能夠達到更有利的結果 (更快的意外應變，開發者生產力提升)並減少繁瑣作業與停機時間。
因此，系統的可觀察性程度將顯著影響其維運和開發成本。..
是什麼 在用戶端-伺服器架構（又可被稱爲主從式架構）中，構成應用程式的邏輯（或者說程式碼）會被拆解至兩組或是多組元件： 一組用戶端負責發起工作請求（例如在你的瀏覽器裡執行的 Gmail 網頁應用程式）， 以及一組或多組伺服器負責滿足這個請求（例如執行在 Google 雲端的「發送郵件」服務）。 舉例來說，你撰寫的外寄電子郵件是由用戶端（在你的瀏覽器裡執行的網頁應用程式） 傳送到伺服器（Gmail 的伺服器，這些伺服器會將你的外寄電子郵件轉寄給收件人）。
這與獨立式應用程式（例如桌面應用程式）形成對比，後者將所有的工作集中於一處完成。 舉例來說，像是 Microsoft Word 這樣的文字處理程式，可以完全安裝並在你的電腦上執行。
解決的問題 用戶端-伺服器架構解決了獨立式應用程式面臨的一大挑戰：定期更新。 對於獨立式應用程式，每一次的更新，都需要使用者自行下載並安裝最新版本。 試想如果你在瀏覽 Amazon 的產品目錄前，需要先將其完整下載到你的電腦上才能開始瀏覽！
如何幫助我們 透過在遠端伺服器或是服務中實現應用程式的邏輯，維運人員可以在不改動用戶端邏輯的情況下進行更新。 這意味著可以更頻繁地進行更新。 將資料存儲在伺服器上，允許多組使用者查看和共享相同的資料。 試想看看線上文字處理器與傳統的離線文字處理器之間的使用差異。 在前者中，你的檔案是儲存於伺服器上並可以與其他使用者共享，他們只需從伺服器下載即可。 在傳統世界中，檔案需要先複製到可移除式媒體（像是磁碟片！）中並與個別用戶分享。..
是什麼 如果我們將將軟體開發週期想像成一條從左到右依序執行的線， 「向左移」中的「左」指的便是週期中較早的階段。 向左移是在軟體開發生命週期中的早期階段就進行測試、安全性或開發實踐等， 而避免等到週期的末期才進行的一種實踐。
儘管最初是用來指稱早期測試的過程， 但現在向左移也可以應用於軟體開發和 DevOps 的其他方面，如安全性和部署。
解決的問題 如果在開發週期後期或部署後才發現安全問題、錯誤和軟體缺陷， 修復它們可能會變得更加困難且昂貴， 尤其是如果該軟體已經部署到正式環境中。
如何幫助我們 透過在軟體開發中採用向左移的思維， 團隊可以在整個開發生命週期中進行測試和加強安全性。 由於測試和安全性的責任由開發團隊共同承擔， 從軟體工程師到品質保證再到維運， 每個人都在確保應用程式的穩定性和安全性。
此外，向左移開啟了持續改進的可能性，並且採用了敏捷式而不是瀑布式的開發方法。 團隊可以進行小規模的迭代改進，並儘早識別問題。 這種方法讓工程師可以提早在設計和架構階段， 就採用安全可靠的開發實踐。 在整個開發週期中進行測試可以減少軟體發布前所需的測試時間。
許多軟體工具和 SaaS 解決方案都有助於團隊朝著向左移前進。 但向左移也可以透過改進團隊內部的流程和文化變革來實施。..
什麼是多租戶 多租戶是指為多個租戶提供服務的單一軟體設施。 一個租戶是一個使用者、應用程式或多個在自己資料集上使用軟體運作的使用者/應用程式。 這些租戶並不共享資料（除非擁有者有明確指示），甚至可能不知道彼此。
租戶可以小至一個具有單一登入 ID 的獨立用戶（例如個人生產力軟體），或像整個公司一樣大，擁有數千個登入 ID，每個登入 ID 都有自己的權限，但以多種方式相互關聯。 多租戶軟體的範例包括 Google Mail、Google Docs、Microsoft Office 365、Salesforce CRM 和 Dropbox，以及許多被歸類為完整多租戶或部分多租戶的其他軟體。
解決的問題 如果沒有多租戶，就需要每個租戶都去安裝專用的軟體設施，這會增加需要運用的資源和維護負擔，進而提升了軟體成本。
如何幫助我們 多租戶軟體為每個租戶提供一個隔離的環境（工作資料、設定、憑證清單等），同時為多個租戶提供服務。 從租戶的角度來看，每個租戶都有其專用的軟體設施，儘管實際上它們都共享同一個。 這是透過在伺服器上運行軟體並允許租戶以介面和/或 API 透過網路連接到該軟體來實作的（另請參閱主從式架構）。 使用多租戶軟體，租戶能夠共享一個設施的資源，而不會相互影響或僅以預先定義和受控的方式有所交互作用。 軟體供應商所節省的資源可以轉移給租戶，進而顯著地降低用戶的軟體成本（像是基於網頁的電子郵件或文件編輯器）。
相關術語 多租戶和 SaaS 並非同義詞，即便 SaaS 多租戶很常見，甚至將多租戶視為其核心優勢之一。..
歡迎 歡迎使用雲端原生 Glossary 的貢獻指南，感謝您的關注。 您可以透過以下方式參與貢獻，我們將在此進行詳細說明：
在現有議題上進行工作 提出新術語 更新現有術語 幫助本地化 Glossary CNCF Glossary 概述 該 Glossary 的目標是簡化複雜的雲端原生領域，使其更容易被人們理解和使用。
雲端原生 Glossary 的內容存儲在此 GitHub 存儲庫中， 您可以在那裡找到有關 Glossary 的議題、拉取請求(PRs)和 討論。
誰可以貢獻？ 您如何參與此專案取決於您的雲端原生專業知識水準。 簡化複雜的概念需要對該主題有深入的了解。 因此，要貢獻新術語，您必須精通該主題。 貢獻者通常是在這些技術上工作了一段時間的工程師或專注於雲端原生的學者。
專業知識是必需的，因為用簡單的話語解釋複雜的概念 真的 很難。而且，儘管易於理解的結果可能看起來很簡單，但達到所需的簡單性需要雲端原生專家之間的努力和協作。
如果您尚未成為雲端原生專家但仍想貢獻，我們建議與專家合作。 一旦專家確信術語準確描述概念，您就可以做出第一個 Glossary 貢獻。
本地化工作是精通另一種語言的初學者可以為 Glossary 做出寶貴貢獻的地方。 借助現有的可靠英語定義，經驗不足的貢獻者可以將術語本地化為目標語言。您可以加入現有的本地化團隊或創建新的本地化團隊。 請閱讀本指南中幫助本地化 Glossary 章節，了解如何開始。
開始之前 在開始您的 Glossary 貢獻之前，請確認完成以下步驟：
建立 GitHub 帳號，如果您還沒有的話。 簽署貢獻者授權協議(Contributor License Agreement) (CLA)。 驗證您的提交簽名。 啟用 vigilant mode 在您的 GitHub 帳戶上，以顯示 “Verified” 狀態在您的提交上。 最佳實踐 為了方便審核過程，請使用 semantic line breaks（例如，每句話一行）。 我們建議查看這份 markdown cheat sheet 以正確地在 GitHub 中格式化 Markdown 文本（例如，超連結、粗體、斜體）。 並且在命名 ...
是什麼 函式即服務 (FaaS) 是一種無伺服器的雲端運算服務， 它可以在特定事件觸發時執行程式碼， 而無需去維護常見於建置與發佈微服務應用程式所需的複雜基礎設施。 在 FaaS 的運作模式下，使用者只需專注於管理自己的功能和資料，應用程式的其他管理工作則交由雲端服務提供商來處理。 這種服務不僅讓開發者可以取得他們所需的功能以外，而且在程式碼不執行時，也無需支付額外的服務費用。
解決的問題 在傳統的地端環境中，企業需要自行管理和維護其資料中心。 企業必須投資於伺服器、儲存空間、軟體和其他技術外， 可能需要聘請 IT 人員或是外包商來購買、管理並升級所有的設備和使用授權。 在這種情況下，資料中心必須配置足夠的資源以應對高峰需求，即使在工作量減少、資源閒置時也難以避免。 反觀，若企業業務快速擴展，IT 部門可能又面臨資源無法即時提供的困境。 在標準的基礎設施即服務 (IaaS) 雲端運算模型下， 用戶會預先購買特定容量，即表示你需要為保持應用程式運行所需的伺服器元件支付給公共雲端服務提供商。 在需求增大時，用戶必須擴充伺服器容量；需求降低時，則需降低容量。 即使應用程式並未在被使用，但運行該應用程式所需的雲端基礎設施仍要持續運作。
如何幫助我們 FaaS 為開發者提供了一種抽象，使他們能夠在無需管理伺服器的情況下，可以根據事件來運行網路應用程式。 以檔案上傳為例，這個動作可能會觸發一段自定義的程式碼，該程式碼將原始檔案轉換成多種格式。 對於大量使用的程式碼，FaaS 的基礎設施能自動擴展， 無需開發者花費時間和資源去設計程式碼的可擴展性。 計費模式則是根據運算時間來計算，這表示企業在功能未使用時，就不必支付任何費用。..
是什麼 垂直擴展也被稱為「向上和向下擴展」，是一項當系統負載提高時透過對單一節點增加 CPU 或 RAM 來提升系統容量的技術。 假設您的系統中有一台 4GB RAM 的計算機，並且想要提升系統的容量至 16GB RAM，那麼對這個系統作垂直擴就展意味著切換為另一台 16GB RAM 的計算機。 (請參考另一種擴展方法：水平擴展)
解決的問題 當應用程式的需求成長超出該應用程式實例的當前容量時， 我們需要找出一種方式來擴展系統(增加容量)。 我們可以加入更多計算資源到目前的節點(垂直擴展)， 或是加入更多節點至此系統(水平擴展)。 可擴展性有助於提升系統的競爭力、效率、評價以及品質。
如何幫助我們 垂直擴展讓您不用修改應用程式中的程式碼就能調整伺服器的大小。 相對地，水平擴展則要求應用程式必須是可被複製的，而且很有可能需要修改程式碼。 垂直擴展藉由增加計算資源來提升現有應用程式的容量， 使得應用程式能夠處理更多請求並同時執行更多工作量。
相關詞彙 水平擴展 自動擴展..
在計算機的背景中，抽象是一種表示方式，它將細節隱藏起來， 讓服務的使用者（包括電腦程式和人類）能夠更容易理解系統並使其更通用。 一個很好的例子是您的筆記型電腦的作業系統（OS）。 它抽象化您的計算機運作的所有細節。 您不需要了解 CPU、記憶體以及程式如何運作， 您只需操作作業系統，作業系統會處理這些細節。 所有細節都被隱藏在作業系統的「幕後」或抽象之後。
系統通常具有多個抽象層。 這顯著簡化了開發過程。 在程式設計時，開發人員建立與特定抽象層兼容的元件， 而不需要擔心底層的具體細節及差異。 不論底層是什麼，只要與抽象層兼容，元件就能在系統中運作。..
是什麼 在微服務的世界裡，應用程式被拆分成多個較小的服務，而這些服務會透過網路進行通訊。 就像您的 Wi-Fi 網路一樣，計算機的網路本質上是不可靠的、易被攻擊的，且經常速度較慢。 服務網格透過管理服務間的流量（即通訊），並在所有服務中統一加入可靠性、可觀察性和安全性功能，來解決這一系列新的挑戰。
解決的問題 當轉移到微服務的架構後，工程師現在都必須處理數百個，甚至數千個需要通訊的服務。 這意味著將有大量的流量會在網路上來回傳輸。 除此之外，單一的應用程式會需要對通訊進行加密以支援監管要求、為營運團隊提供通用指標、或對於流量提出詳細的見解以協助診斷問題。 如果這些功能被建立在單一的應用程式中，那麼每一個功能都會產生團隊間的摩擦，減緩新功能開發的速度。
如何幫助我們 服務網格在不需要改變程式碼的情況下，為所有服務統一地增加了可靠性、可觀察性和安全性功能。 在服務網格出現之前，這些功能必須被嵌入到每一個服務中，成為錯誤和技術債的潛在來源。..
是什麼 金絲雀部署是一種部署策略，一開始有兩個環境：一個目前有即時流量的環境和一個目前無即時流量且已更新程式碼的環境。 流量會逐漸從應用程式的原始版本轉移到更新後的版本。 它可以從 1% 的流量開始，然後是 10%、25% 等等，以此類推，直到所有流量都轉移到已更新的版本。 企業可以在正式環境中測試新版本的軟體，獲得回饋、錯誤診斷，並在必要的時候可以快速退回到穩定版本。
「金絲雀」這詞是指「礦坑中的金絲雀」的做法，把金絲雀帶入礦坑中確保礦工們的安全。 如果出現無味的有害氣體，這隻鳥就會死亡，礦工們知道他們必須儘速離開。 同樣地，如果更新後的程式碼出現問題，即時流量就會被"撤離"回原始版本中。
解決的問題 無論測試策略有多嚴謹，總是會在正式環境中會發現一些錯誤。 將 100% 流量從應用程式的一個版本完全切換到另一個版本，可能會導致更嚴重的失敗。
如何幫助我們 金絲雀部署讓企業在大量流量轉移到新版本以前，可以查看新版本軟體在實際場景中使用的情形。 這種策略讓企業能夠最大限度地減少停機時間，並在新部署出現問題時快速退回上個版本。 它允許更深度的正式應用程式測試，而不會對整體使用者體驗產生重大影響。..
是什麼 持續交付，通常縮寫為 CD，是一套將原始碼變更自動部署到驗收環境中的實踐， （或者，在持續部署的情況下，部署到正式環境中）。 CD 關鍵是包括確定軟體在部署前 得到充分測試的程式，並提供一種在必要時退回修改的方法。 持續整合（CI）是實現持續交付的第一步 （也就是說，在測試和部署之前，變更必須乾淨地合併）。
解決的問題 大規模部署具有 可靠性 的更新會成為一個問題。 理想情況下，我們會更頻繁地部署，為終端使用者提供更好的價值。 然而，手動操作會使每一個變化都轉變為高額的交易成本。 過去，為了避免上述成本，企業發布的頻率較低， 在一次的部署中包含更多的變更，同時也會增加出錯的風險。
如何幫助我們 CD 策略建立了一個完全自動化的生產路徑， 使用各種部署策略測試和部署軟體， 如 金絲雀部署 或 藍綠部署 來進行發布。 這使得開發人員可以頻繁地部署程式碼，讓他們放心地確保新的修訂版已經過測試。 通常情況下，CD 策略中使用基於主幹的開發方式，而不是功能分支或拉取要求。
相關術語 持續整合 持續部署..
是什麼 持續部署，通常縮寫為 CD，它直接將完成的軟體部署到正式環境，比持續交付更進一步。 持續部署（CD）與持續整合（CI）緊密相關，通常被稱為 CI/CD。 CI 流程用於測試對特定應用程式的變更是否正確，而 CD 流程則自動部署組織測試環境的程式碼變更到正式環境。
解決的問題 發布新軟體版本是一個勞動密集且容易出錯的過程。 通常這也使組織希望盡量減少發布新版本的頻率，以避免正式環境發生事故並減少工程師需要在正常工作時間之外提供支援的次數。 傳統的軟體部署模型讓組織陷入一個惡性循環，其中軟體發布的過程無法滿足組織在穩定性和功能迭代速度方面的需求。
如何幫助我們 透過自動化發布週期並強制組織更頻繁地將產品部署到正式環境中，CD 之於維運團隊就像 CI 之於開發團隊一樣。 具體來說，它強制維運團隊自動化正式部署中痛苦且容易出錯的部分，從而降低整體風險。 它還使組織更善於接受和適應正式環境的變化，進而提高穩定性。
相關術語 持續整合 持續交付..
是什麼 持續整合，通常縮寫為 CI，是盡可能定期整合程式碼更改的實踐方法。 CI 是 持續交付（CD）的前置工作。 傳統上，CI 的流程從程式碼更動提交到版本控管（Git、Mercurial 或 Subversion）時開始， 以準備被 CD 系統使用的測試產出物（tested artifact）直到結束。
解決的問題 軟體系統通常是龐大且複雜的，有許多開發人員在維護和更新它們。 在系統的不同部分同時工作， 這些開發人員可能會做出互相衝突的修改，並在無意間破壞對方的工作。 此外，由於多位開發人員在同一個專案上工作， 任何日常任務，如測試和計算程式碼品質，都需要每位開發人員重複執行，浪費了時間。
如何幫助我們 每當開發人員提交修改時，CI 軟體會自動檢查程式碼更動是否合併得很乾淨。 使用 CI 伺服器來執行程式碼品質檢查、測試甚至部署，這幾乎是一種普遍存在的做法。 因此，它成為團隊內部品質控管的具體實現方式。 CI 讓軟體團隊能將每次的程式碼提交轉變為具體的失敗或可用的發布候選版本。
相關術語 持續交付 持續部署..
以下的風格指南旨在幫助你了解雲端原生 Glossary 的定義結構，並在整個過程中保持一致的風格。
雲端原生詞彙遵循位於 CNCF 資源庫中的預設風格指南。 此外，它還遵循以下規則：
使用簡單、易懂的語言，避免技術術語和流行語 避免使用俚語 使用字面和具體的語言 省略縮略語 少用被動語態 力求以積極的形式表述 引號外不加感歎號 不要誇大其詞 避免重複 要簡明扼要 受眾 本 Glossary 是針對技術和非技術人員編寫的。 請使用簡單的術語來解釋定義並不要假定技術知識。有關定義的更多細節請參閱下面的定義部分。
最小可行定義 我們的目標是讓任何人都能夠輕鬆理解雲端原生術語。 因此，我們專注於簡潔明瞭。 請使用清晰簡單的語言，並提供任何使用技術的人都可以理解的示例，同時提供一個最小可行定義，至少從技術角度上來說。 我們不希望省略上下文和示例 — 畢竟，這些東西可以幫助讀者理解概念 — 但如果技術細節不需要理解它，我們就會跳過它。 目標不是讓事情變得過於複雜。一旦讀者了解了基本概念，其他資源將有助於他們進一步深入挖掘。 這部分超出了本 Glossary 的範圍。
定義樣板 每個 Glossary 術語都存儲在一個 markdown 文件中，並遵循這個樣板：
— title: status: category: — ## 是什麼 對該技術或概念的快速總結。 ## 解決的問題 關於它所解決的問題的幾句話。 ## 如何幫助我們 用幾句話說明這個東西是如何解決問題的。 標題 title label 將始終位於定義布局的頂部，其值應使用標題大小寫。
— title: 定義樣板 狀態 status label 將出現在 title label 之後。這個 label 代表著這個定義距離完成還有多遠。..
是什麼 容器是由計算機中的作業系統所管理，且具有資源與功能限制的執行中行程。 容器行程內可用的檔案可被打包成一個容器映像檔。 容器在同一台機器上相鄰執行， 但通常作業系統會阻止讓不同容器行程間互相溝通。
解決的問題 在容器技術出現之前，需要單獨的機器來執行不同應用程式。 每台機器都需具備自己的作業系統，因而需要 CPU、記憶體和磁碟空間， 而這些資源都是為了執行一個單獨應用程式。 另外，無論是作業系統的維護、升級或啟動都是額外工作負擔的來源。
如何幫助我們 容器可共享相同的作業系統和機器資源， 分散作業系統的資源消耗，並有效率的使用實體機器的資源。 這樣的能力具備可行性的原因，是因為容器之間的溝通通常都受到限制才能達成。 這樣的方式也允許更多的應用程式在同台實體機器上執行。
然而容器也伴隨著一定的限制。 由於容器共享相同的作業系統，因此行程的安全性可能會較其他替代方案差。 容器還需要限制共享資源的使用。 為了保證資源利用，管理員必須約束和限制記憶體與 CPU 使用率，避免讓其他的應用程式執行效率低落。..
是什麼 容器協調指的是在動態的環境中自動管理容器化應用程式的生命週期。 這通過一個容器協調器 (大多是 Kubernetes) 來執行如部署、(自動)擴展、自我修復和監控。 協調是一個隱喻用詞: 協調工具就如同樂隊指揮一樣指揮管理眾多容器，確保每個容器(或樂手)各執其職。
解決的問題 手動管理大規模的微服務、安全性和網路通訊以及常見的分散式系統 雖然困難但並非不可能。 而容器協調能讓用戶自動化所有這些管理任務。
如何幫助我們 容器協調工作允許使用決定系統的狀態。 首先，這些工具會宣告系統應具備的狀態 (例如 x 個容器、 y 個 Pod 等等)。 接著容器協調工具將會自動監控基礎建設並且在其狀態與宣告狀態不一致時自動修正 (例如當一個容器壞掉不能運行時，則啟動一個全新的容器)。 這種自動化的操作簡化了許多工程團隊手動與複雜的維運工作，例如 服務開通、部署、自動擴展、網路、負載平衡和其他活動。..
<p>嗨！👋 感謝您對貢獻 CNCF 雲端原生 Glossary 專案感到興趣。 無論您貢獻新術語、協助本地化 Glossary 成為您的母語， 或者想要幫助他人入門，都有很多方式成為此社群的活躍成員。 本文檔概述了專案中的不同貢獻者角色以及隨之而來的職責和權限。</p>
<ol>
<li>貢獻者 Glossary 歡迎所有人參與。任何人只要有貢獻都可以成為 Glossary 的貢獻者。所有貢獻者都應遵守 CNCF 行為準則。
有多種方式可以貢獻此專案，包括：
內容貢獻者：改進現有術語或新增術語的所有人， 本地化貢獻者：協助將 Glossary 翻譯成另一種語言的人， 幫助者：在 GitHub、Slack 或其他社群成員需要支援時協助他人的人， 大使：幫忙傳達訊息、教育社群如何貢獻，以及為什麼他們應該這麼做的任何人。 貢獻者可以擔任多個角色或僅專注於一個領域。 所有這些貢獻同等重要和有助於促進繁榮的社群。 有關內容和本地化貢獻，請參閱如何貢獻和風格指南。</li>
<li>審核者 審核者提供 PR 的回饋並核准他們。任何活躍的貢獻者都可以成為審核者（參見成為審核者）。 Glossary 區分兩種審核者：（1）英文 Glossary 的審核者和（2）本地化團隊的審核者。
Glossary 審核者應該：
審核 PR 的技術準確性， 分配貢獻者議題並適當地標記他們， 為貢獻者提供反饋並在需要時指導他們， 校對和編輯提交。 如果審核者不再感興趣或無法執行上述職責，他們應讓維護人員知道並下台。
英文 Glossary 審核者 有三種類型的審核者：
1）擁有強大技術背景的審核者， 2）具有扎實的寫作能力的審核者， 3）精通兩者的審核者。
技術審核者：具有強大技術背景的人可以成為審核者，而不必具備扎實的英文寫作能力。但是，如果他們基於技術的優點核准了 PR，則必須確保經由一位（編輯）審核者進行了審核。
編輯者：編輯人員校對術語並確保其根據樣式指南用簡單的語言解釋。如果術語被大量編輯，編輯人員必須要求技術審核者再次審核，以確保含義未被更改。
本地化審核者 Glossary 還有本地化審核者。這些是本地化團隊（翻譯 Glossary 的團隊）之一的審核者。 本地化審核者僅允許為其自己的團隊執行核准任務，並有能力將 PR 合併到其專屬的開發分支。 任何本地化審核者都可以成為英文 Glossary 的審核者，如果符合要求的話。</li>
</ol>
..
是什麼 敏捷軟體開發是一系列強調迭代開發週期和自我組織團隊的實踐方法。 與僅在專案結束時才生成價值的瀑布式專案相比， 敏捷軟體開發著重於價值的持續、增量式的交付，並對過程本身進行漸進式的改善。
解決的問題 在軟體專案中，定義、傳達和理解所有利害關係人的需求非常困難，甚至是不可能的。 然而，客戶希望他們的軟體專案能有高品質，在預算、時程及專案範圍內交付。 相較於於瀑布式策略，敏捷軟體開發的週期特性使其能持續適應需求，並且能更快地適應其他所有情況。
如何幫助我們 敏捷軟體開發包含了傳統（瀑布式）策略的所有階段， 如需求工程、規劃、開發、審核、測試和交付。 最大的不同在於，整個軟體專案的時間跨度被切分為多個迭代， 每個迭代都包含所有這些階段。 在每個迭代結束後，開發團隊可以與客戶一起審查創造的價值，並對需求進行調整以達到最終目標。 此外，開發團隊還會反思需要採取哪些行動來改進過程本身。..
是什麼 混沌工程或 CE，是在正式環境中對分散式系統進行實驗的專業，以建立對系統在承受混亂和意外情況下時能力的信心。
解決的問題 SRE 和 DevOps 實踐注重提高產品的彈性和可靠性技術。 系統在故障容錯時確保有足夠服務品質的能力通常是軟體開發的要求。有幾個方面可能導致應用程式發生故障，例如基礎設施、平台或(基於微服務的)應用程式的其他部分。 在正式環境中高頻率部署新功能會增加導致停機和嚴重事件發生的可能性，這對業務會產生重大影響。
如何幫助我們 混沌工程是一種滿足彈性需求的技術。它用於達成對基礎設施、平台和應用程序故障容錯。 混沌工程師使用混沌實驗來主動注入隨機故障，以驗證應用程序、基礎設施或平台是否能夠自我修復，並且故障不會明顯影響客戶。 混沌實驗旨在發現盲點（例如監控或自動擴展技術），並在嚴重事件期間提升團隊之間的溝通。 這種方法有助於提高系統的彈性和團隊對複雜系統的信心，尤其是正式環境。..
是什麼 單體式應用程式是一個可部署的程式，且包含所有功能在其中。 這通常是開發應用程式時最單純跟最容易的起點。 然而，一旦應用程式變得更複雜，單體便可能變得難以維護。 隨著更多開發人員一起在同一個程式碼庫中開發， 改動之間出現衝突的機會便會增加， 開發人員之間的溝通需求也會變多。
解決的問題 使用微服務來開發應用程式會增加維運成本， 因為會有更多的東西需要測試、部署與執行。 如果能在產品生命週期的初期就建立一個單體式應用程式， 就能把這種複雜度推遲到確定產品成功之後， 或許不失為一個好主意。
如何幫助我們 若要讓一個設計良好的單體式應用程式符合精實原則， 就要把這個應用程式以最簡單的方式跑起來， 當一個單體式應用程式的已經被證明具有商業價值之後， 便可以將其拆解為微服務。 如果在一個應用程式證明其價值之前就使用微服務架構來進行開發， 便可能成為過早的工程投入。 萬一這個應用程式無法提供價值， 這將會變得徒勞無功。..
是什麼 在雲端原生運算中， 虛擬化指的是將一台實體計算機（有時稱為伺服器）， 使其能夠運行多個獨立作業系統的方法。 這些獨立的作業系統以及它們專屬的運算資源（CPU、記憶體和網路）被稱為虛擬機器或 VM。 當我們提到虛擬機器時，在講的其實是由軟體定義的計算機。 這種計算機在外觀上和與行為上都像是真實的計算機，但實際上它會與其他虛擬機器共用硬體資源。 雲端運算 主要是由虛擬化技術所驅動。 舉例來說， 你可以從 AWS 租用一台「計算機」， 但實際上它是一台虛擬機器。
解決的問題 虛擬化解決了多個問題， 比方說它允許更多應用程式在同一台實體機器上運行， 而且還能將它們相互隔離以確保安全性。
如何幫助我們 在虛擬機器上運行的應用程式並不知道它們正在共用一台實體計算機。 虛擬化還能讓資料中心的使用者在數分鐘內啟動一台新的「計算機」（其實是虛擬機器）， 而無需擔心增加新的計算機到資料中心所帶來的實體限制。..
是什麼 虛擬機器（VM）是一台不受限於特定硬體的計算機及其作業系統。 透過虛擬化技術， 我們可以將一台實體的計算機分割成多台虛擬的計算機。 這種分割可以讓組織和基礎設施提供者能輕鬆地建立和刪除虛擬機器， 而不會影響底層的硬體。
解決的問題 當一台裸機綁定到單一作業系統時， 該計算機的資源使用情況通常在某種程度上會受到限制。 另外，當一個作業系統綁定到單一實體計算機時， 其可用性也會與該硬體的直接相關。 如果實體計算機因為維護或硬體故障而離線， 該作業系統也會隨之離線。
如何幫助我們 透過解除作業系統與單一實體計算機之間的直接綁定， 我們便可以解決裸機的幾個問題： 佈建時間、硬體使用率和復原力。
在佈建新的虛擬機器時， 我們不需要為此購買、安裝或設定新的硬體， 所以佈建一台新計算機的時間便可以大幅地縮短。 由於我們可以將多台虛擬機器放置在一台實體計算機上， 這讓我們能夠更有效率地使用既有的硬體資源。 虛擬機器不受特定實體計算機的限制， 因此也比實體計算機更具有復原力。 當一台實體計算機需要離線時， 運行於其上的虛擬機器可以無需或只需極少的停機時間， 便可以轉移到另一台實體計算機上。..
雲端原生 Glossary 雲端原生 Glossary 主要目標在使人們更容易理解，將以複雜而聞名雲端原生領域變得更簡單好懂，不僅限於技術人士，也同樣適用於商業人士。 為了實現這一目標，我們注重簡潔（例如：使用簡單用語描述且不包含流行用語、使用任何技術的人都可以通用的範例、省略不必要的細節）。 Glossary 是由 CNCF 商業價值小組（Business Value Subcommittee; BVS）領導的專案。
貢獻 歡迎所有人對雲端原生 Glossary 提出更改、補充和改進。 我們採用由 CNCF 管理的社群驅動的流程來開發和改進這個共享 Glossary 。 Glossary 提供了一個所有參與者使用且供應商保持中立的平台，以組織雲端原生技術的共享詞彙。 歡迎所有遵守本專案宗旨和章程的參與者做出貢獻。
任何希望貢獻的人都可以提交 GitHub 議題或創建拉取請求。 請確保您遵循風格指南，閱讀如何參與貢獻文件，加入 CNCF Slack工作區，並加入 #glossary頻道。
也有一個 #glossary-localizations頻道，提供想將 Glossary 翻譯為其本地化語言的人們使用。
致謝 雲端原生 Glossary 由 CNCF 行銷委員會 (CNCF Marketing Committee)（商業價值小組委員會）發起，包括來自 Catherine Paganini、 Chris Aniszczyk、 Daniel Jones、 Jason Morgan、 Katelin Ramer、 Mike Foster和許多的貢獻者。 如果想獲得完整的貢獻者名單，請參考此 GitHub page。
Glossary 主要維護由 Seokho Son、 Noah Ispas、 Jihoon Seo、 Nate W. 和 Jorge Castro。..
什麼是雲端原生技術 雲端原生技術，也稱為雲端原生技術棧，是用於構建雲端原生應用程式的技術。 這些技術使組織能夠在現代和動態環境中構建和運行可擴展的應用程式，例如公有、私有和混合雲，同時充分利用雲計算的好處。 它們從頭開始設計，以利用雲計算和容器，服務網格、微服務和不可變基礎設施的能力。
解決的問題 雲端原生技術棧有許多不同的技術類別，解決了各種挑戰。 如果您查看 CNCF Cloud Native Landscape，您將看到它涉及許多不同領域。 但從高層次上看，它們解決了一組主要的挑戰：傳統 IT 操作模型的缺點。 挑戰包括難以創建可擴展、容錯、自我修復的應用程式，以及低效的資源利用率，等等。
如何幫助我們 雖然每種技術都解決了非常具體的問題，但作為一組，雲端原生技術使鬆散耦合的系統具有彈性、可管理和可觀察性。 結合堅強的自動化，它們允許工程師頻繁且可預測地進行高影響的更改，並減少不必要的工作。 雲端原生技術棧有助於實現雲端原生系統的期望特性。..
什麼是雲端運算 雲端運算是一種通過網際網路提供計算資源（如CPU、網路和磁碟功能）的服務，使用戶可以遠端存取位於實體位置的運算資源。一般會根據雲端基礎設施是用於專門為組織而設或是共享用於開放式服務，將其區分為私有雲和公有雲。
解決的問題 普遍來說，當組織需要擴展其運算資源時，會面臨兩個主要挑戰：一方面是購買、支援和設計新的設施來托管物理伺服器和網路，另一方面則是擴充和維護現有設施。透過雲端運算，組織能夠透過外包部分的運算需求以解決這些考驗。
如何幫助我們 雲端供應商讓組織可以按需租用計算資源並根據使用情況付費，從而帶來兩大優勢。第一是組織可以專注於產品或服務，無需等待、計劃和投入資源於新的物理基礎設施。其次，組織可以根據實際需求隨時擴充其運算資源。透過雲端運算，組織可以彈性選擇所需的基礎設施，以適應不斷變化的需求。..
是什麼 傳輸層安全性協議 (TLS) 是一種設計用於在網路通訊中提供安全性的協議。 它確保透過網路傳輸的資料能安全送達， 避免遭監控或修改的可能性。 此一協議廣泛用於各類應用，譬如即時通訊、電子郵件等。
解決的問題 若沒有 TLS，像是瀏覽習慣、電郵往來、線上對話與視訊會議等敏感資訊， 在傳輸過程中可能輕易地被他人追蹤或修改。 使用伺服器與用戶端應用均支援 TLS 的方式， 能確保資料在傳輸過程中被加密，無法被第三方窺看。
如何幫助我們 TLS 透過一系列的編碼技術，為網路資料傳輸時提供安全防護。 TLS 讓用戶端應用與伺服器 (例如網頁瀏覽器與銀行網站) 之間建立一組加密連線。 並且它讓用戶端應用能正確地識別所呼叫的伺服器， 以降低與偽造網站接觸的風險。 藉此確保使用 TLS 的應用間資料傳輸不會被第三方窺看與監控， 保護包括信用卡卡號、密碼、位置等在內的敏感與私人資訊的安全。..
是什麼 節點是一台會與其他計算機（或稱節點）一起運作以完成共同任務的計算機。 舉例來說， 你的筆記型電腦、數據機和印表機都連接在你的無線網路上進行通訊和協作， 其中每個裝置都都代表一個節點。 在雲端運算中， 一個節點可以是一台實體計算機， 或是一台虛擬機器（VM）， 甚至可以是一個容器。
解決的問題 雖然一個應用程式可以（而且很多都這麼做）在一台單獨的計算機上運行， 但這樣會存在一些風險。 主要是因為底層系統的故障會干擾應用程式的運行。 為了解決這個問題， 開發人員們開始建立分散式應用程式， 讓每個行程都在自己的節點上運行。 因此，執行這些應用程式或是行程的節點們便會形成一個節點叢集， 一起合作完成共同的目標。
如何幫助我們 一個節點提供了一個可指派給一個叢集的獨立運算單元（記憶體、CPU、網路）。 在雲端原生平台或應用程式中， 一個節點就代表一個可以執行工作的單位。 在理想情況下，個別的節點是不可區分的， 也就是說，我們無法區分某個類型的任何一個節點與同一類型的其他節點。..
是什麼 零信任架構是一種完全移除信任的 IT 系統設計與實作方法。 其核心的原則是「永不信任，始終驗證」，系統中的裝置或系統本身在與其他元件溝通前，都必須先驗證自己的身份。 在許多企業網路中，由於系統與裝置都在企業網路的邊界內，因此他們大多時候可以自由溝通。 然而，零信任架構卻採取了相反的做法：即使在網路邊界內，系統中的元件在進行任何溝通前，都必須先通過驗證。
解決的問題 在傳統基於信任的方法中，之所以認為存在於企業網路邊界內的系統與裝置是安全的，是因為他們都在受信任的網路邊界內。 但是零信任架構認為，這種信任模式實際上存在著弱點。 如果攻擊者取得了對信任裝置的存取權限，因為攻擊者已經在受信任的網路邊界內，他就可以在系統中自由移動，並且獲得系統賦予該裝置的信任與權限，進而使系統容易遭受攻擊。 不過在零信任的架構下，因為信任被移除了，攻擊者在進入系統的下一個環節前，都必須先通過驗證，所以進而減少了攻擊面。
如何幫助我們 採用零信任架構的主要好處就是減少了攻擊面，讓系統變得更安全。 從企業系統中移除信任，就可以讓攻擊者必須通過更多更強的安全閘門，才能獲得對系統其他區域的存取權限。..
是什麼 網站可靠性工程(SRE)是一門結合了維運和軟體工程的專業。 它主要應用於基礎設施和維運問題。 這意味著，網站可靠性工程師不是建構產品功能，而是建構系統來運行應用程式。 雖然 SRE 和 DevOps 有相似之處，但是 DevOps 主要關注將程式碼部署到正式環境， 而 SRE 則確保正式環境中運行的程式碼正確運作。
解決的問題 確保應用程式運行具備可靠性，需要具備多項能力， 從效能監控、警報、除錯到故障排除都是必要的。 如果缺少這些能力，系統操作員只能對問題做出反應，卻無法主動努力避免它們， 而造成停機僅是時間問題。
如何幫助我們 網站可靠性工程透過持續改進底層系統， 以最大限度地降低軟體開發過程的成本、時間和工作量。 該系統持續測量和監控基礎設施和應用程式的元件。 當出現問題時，系統會向網站可靠性工程師指示何時、何處以及如何修復它。 這種方法通過自動化操作的任務，有助於創建高度的擴展性和可靠性的軟體系統。..
在數學或電腦科學中，冪等被用來描述無論執行多少次都會有相同結果的操作。 如果參數相同，多次執行冪等操作都不會產生額外效果。..
是什麼 一座叢集是指一組由計算機或應用程式為實現共同目標而協同工作。 在雲端原生計算的背景之下，這個詞彙通常用於 Kubernetes。 一座 Kubernetes 叢集是一組執行在它們自己的容器中的服務 (或工作負載)，通常在不同的機器上執行。 所有這些通過網路連接的 容器化 服務集合代表一座叢集。
解決的問題 在單一計算機上執行的軟體若出現單點故障 - 如那台計算機當機、或者有人意外拔掉電源線，那麼某些關鍵的業務系統可能會被離線。 這就是為什麼現代軟體通常被建構成 分散式應用程式，並集結為叢集的原因。
如何幫助我們 雖然分散式叢集應用程式執行在多台機器上，消除了單點故障，但是建構分散式系統確實很困難。事實上，它是資訊工程中的一門獨立學科。 汲取全球級別系統的需求以及多年的反覆試驗下，最終促成了一種新的技術棧的發展: 雲端原生技術。這些新技術是使得建構分散式系統更容易操作和建立的元件。..
是什麼 藍綠部署是一種以最小的停機時間更新執行中的電腦系統的方法。 維運者維護兩個環境，被稱為 “藍” 和 “綠”。 一個提供正式服務的流量（所有使用者目前正在使用的版本），另一個則是需要升級的服務。 一旦非活躍（綠色）環境中的測試結束， 正式服務流量會被切換過來（通常會使用負載平衡器）。 注意，藍綠部署通常意思是要切換整個環境，包括許多服務。 令人困惑的是，有時這個術語被用於一個系統內的單個服務。 為了避免這個歧異，提到單個元件時，最好使用 “零停機部署” 一詞。
解決的問題 在更新那些缺乏向後相容性而必須"同步"改變的軟體時，藍綠部署允許最短的停機時間。 例如，藍綠部署適用於一個由網站和資料庫組成的線上商店， 該商店需要更新，但新版本的資料庫不能與舊版本的網站一起使用，反之亦然。 在這樣的情況下，兩者需要同時改變。 如果在正式環境這樣做，客戶會注意到停機時間。
如何幫助 對於需要以最小的停機時間進行更新的非雲端原生軟體來說，藍綠部署是一種適合的方法。 然而，它的使用通常是一種 “警訊”，老舊系統需要重新設計，以便可以單獨更新元件。..
是什麼 邊緣運算是個分散式系統，它將一些儲存和運算資源從主要資料中心轉移到資料來源。 收集到的資料在本地端（例如：工廠、商店或整座城市）進行計算，而不是傳送到集中式資料中心進行處理和分析。 這些本地端處理單元或裝置代表系統的邊緣，而資料中心則代表系統的中心。 邊緣計算出的結果會被送回主要資料中心做進一步處理。 邊緣運算的例子包括手腕上的小配件或分析交通流量的電腦。
解決的問題 過去十年中，我們可以看到越來越多的邊緣裝置（例如：手機、智慧型手錶、感測器）。 在某些情況下，即時資料處理不僅是一個不錯的選擇，而且極其重要。 想想自動駕駛的汽車。 現在想像一下，汽車感測器的資料必須先傳送到資料中心進行處理，然後再送回汽車，這樣汽車才能作出適當的反應。 如此產生的網路延遲會是致命的。 雖然這是一個極端的例子，但大多數使用者都不願意使用無法即時反應的智慧設備。
如何幫助我們 如上所述，要使邊緣設備發揮作用，它們必須至少在本地端完成部分處理和分析工作，以便於對使用者提供接近即時的回饋。 要做到這點，就必須將資料中心的部分儲存和處理資源轉移到資料生產地：邊緣設備。 已處理和未處理的資料隨後發送到資料中心做進一步處理和儲存。 簡而言之，效率和速度是邊緣運算的主要驅動力。..