避免不完全的雲原生（三）：架構和設計要素

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"},{"type":"strong"}],"text":"本文最初發佈於The Startup博客，經原作者授權由InfoQ中文站翻譯並分享。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"}],"text":"注：本文是本系列文章的第3部分。如果你想從本系列文章第一篇開始閱讀，請點擊"},{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/article\/Qj0SqAEDZZyVOPyhyTXY","title":"xxx","type":null},"content":[{"type":"text","text":"這裏"}]},{"type":"text","marks":[{"type":"italic"}],"text":"。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在本系列文章的"},{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/article\/Qj0SqAEDZZyVOPyhyTXY","title":"xxx","type":null},"content":[{"type":"text","text":"上一部分"}]},{"type":"text","text":"中，我們討論了遷移到雲原生方法可能會對人員組織和流程簡化產生怎樣的影響。在這篇文章中，我們將深入探討它與架構和設計原則之間的關係。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.infoq.cn\/resource\/image\/71\/e0\/71d32aa96b11d7a2251193c293bcabe0.png","alt":null,"title":"","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"雲原生要素：架構與設計"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"是架構方法賦予技術生命。我們可以將傳統的、豎井式的、有狀態的粗粒度應用程序組件部署到現代的基於容器的雲基礎設施上。對一些人來說，這是一種讓他們可以涉足雲的方法，但這應該只是一個開始。如果這樣做，你幾乎體驗不到雲原生的任何優勢。在這一部分中，我們將考慮如何設計一個應用程序，使其有機會充分利用底層雲基礎設施。顯然，使用不可變部署滾動發佈解耦良好的組件與採用敏捷方法和流程同樣重要。下圖展示了雲原生架構的組成部分："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"image","attrs":{"src":"https:\/\/static001.infoq.cn\/resource\/image\/20\/5b\/2044f1d4c6692c1c31a6ef826105c65b.png","alt":null,"title":"","style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":"center","origin":null},"content":[{"type":"text","text":"雲原生架構的組件"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"細粒度組件"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"不久之前，爲了有效地使用硬件和軟件資源，我們還是以大塊的代碼構建和運行軟件。最近的技術發展（如容器），讓我們可以將應用程序分解成更小的塊並單獨運行。我們所說的細粒度涉及幾個不同的方面："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"功能驅動的粒度——每個組件執行一個定義良好的任務；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"自包含組件——在可能的情況下，該組件包括其所有依賴項；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"獨立的生命週期、可伸縮性和彈性——組件從單個代碼庫構建，通過專用管道，並且在運行時獨立託管。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"通常，這種構建應用程序的方式被稱爲微服務，不過應該注意，真正的“微服務方法所涉及的面”比細粒度組件要廣泛得多，而且確實與這裏描述的雲原生概念有很大的重疊。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"更細粒度組件的主要有如下好處："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"更強的靈活性：它們足夠小，可以完全理解並單獨更改；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"彈性伸縮：每個組件都可以單獨伸縮，從而可以最大限度地提高雲原生基礎設施的效率；"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"離散彈性（Discrete resilience）：通過適當的解耦，一個微服務運行不穩定不會影響其他服務。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"雖然在適當的環境中，上面的方法可以帶來顯著的好處，但是設計高度分佈式的系統並不是一件簡單的事情，管理它們更不容易。確定微服務組件的大小本身就是一個"},{"type":"link","attrs":{"href":"https:\/\/kylegenebrown.medium.com\/whats-the-right-size-for-a-microservice-bf1740370d47","title":"","type":null},"content":[{"type":"text","text":"需要深入討論的話題"}]},{"type":"text","text":"，然後還要進行進一步的設計決策，確定它們應該如何解耦，以及如何管理剩下的緊耦合部分的版本。發現必要的內聚性與引入適當的解耦同樣重要，經常會有因爲粒度過細而不得不中止的項目。簡而言之，只有設計良好、方法及流程成熟時，微服務應用程序才能具備靈活性和可伸縮性。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"italic"}],"text":"注意：人們經常會對微服務架構和麪向服務的體系結構（SOA）進行不恰當的比較，因爲它們有相同的詞彙，並且似乎處於相同的概念空間中。然而，它們涉及不同的範圍。微服務與應用程序架構有關，SOA與企業架構有關。這個區別非常關鍵，文章“"},{"type":"link","attrs":{"href":"https:\/\/ibm.biz\/microservicesvssoa","title":"","type":null},"content":[{"type":"text","marks":[{"type":"italic"}],"text":"微服務與SOA：如何分辨"}]},{"type":"text","marks":[{"type":"italic"}],"text":"”對此進行了進一步探討。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"適當的解耦"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果細粒度組件之間不能相互解耦，那麼它們的許多優點（敏捷性、可伸縮性和彈性）就會喪失。這些細粒度的組件需要滿足以下條件："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"清晰的所有者邊界"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"形式化的接口（API和事件\/消息）"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"單獨的持久化存儲"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"編寫模塊化軟件並不是什麼新鮮事。所有的設計方法，從功能分解到面向對象的編程，再到面向服務的體系結構，都旨在將大問題分解成更小的、更易於管理的部分。雲原生領域的機遇在於，利用容器等技術，我們可以將每個容器作爲真正獨立的組件運行。每個組件都有自己的CPU、內存、文件存儲和網絡連接，就像一個完整的操作系統一樣。因此，只能通過網絡訪問它，這本身就在組件之間創建了一個非常清晰的強制性分離。不過，底層平臺提供的解耦只是其中的一個方面。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"從組織的角度來看，所有權要清晰。每個組件都需要由一個能夠完全控制其實現的團隊擁有。這並不是說團隊不應該接受變更請求，即來自其他團隊的pull請求，但是他們可以控制合併什麼以及何時合併。這是敏捷的關鍵，只要是遵循與其他團隊約定的接口，他們就可以修改組件，並且滿懷信心地部署變更。當然，即使這樣，團隊也應該在組織整體設置的架構邊界內工作，但是在這些邊界內，他們應該有相當大的自由。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"組件應該顯式地聲明接口，並且鎖定所有其他的訪問方式。它們應該只使用成熟的標準協議。同步通信最簡單，HTTP的普遍性使其成爲首選項。更具體地說，我們通常會看到RESTful API使用JSON，不過，其他協議（如gRPC）也可以用於特定的需求。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"區分相同所有權邊界（例如應用程序邊界）內跨組件的調用和對另一個所有權邊界內的組件的調用，這很重要，但超出了本文的範圍。更多信息請閱讀這篇"},{"type":"link","attrs":{"href":"https:\/\/community.ibm.com\/community\/user\/middleware\/blogs\/kim-clark1\/2018\/10\/09\/microservices-and-apis-defining-application-boundaries","title":"","type":null},"content":[{"type":"text","text":"文章"}]},{"type":"text","text":"。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"然而，HTTP API的同步特性將調用者與下游組件的可用性和性能綁定在了一起。通過事件和消息進行異步通信，藉助“存儲轉發”或“發佈\/訂閱”模式，可以更徹底地將它們與其他組件解耦。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一種常見的異步模式是，數據的所有者發佈有關數據更改的事件（創建、更新和刪除）。其他需要該數據的組件監聽事件流並構建自己的本地數據存儲，這樣，當它們需要該數據時，就有一份副本。這個流程涉及其他"},{"type":"link","attrs":{"href":"https:\/\/ibm-cloud-architecture.github.io\/refarch-eda\/","title":"","type":null},"content":[{"type":"text","text":"事件驅動的架構模式"}]},{"type":"text","text":"（如事件源和CQRS）。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"儘管異步模式可以提高可用性和性能，但它有一個不可避免的缺點：它會導致各種形式的最終一致性，這可能使設計、實現，甚至問題診斷都更加複雜。因此，對於基於事件和基於消息的通信的使用，應該適當地加以限制。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"最小化狀態"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在雲原生解決方案中，清晰地分離組件狀態至關重要。這通常涉及三個關鍵的主題："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"容易水平擴展"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"沒有調用者或會話關聯"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"組件之間不存在兩段提交"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"無狀態使編排平臺能夠以最佳方式管理組件，根據需要添加和刪除副本。無狀態意味着在組件啓動後，不應該對配置或組件所持有的數據進行任何更改，導致其不同於任何其他副本。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"關聯性是最常見的問題之一。希望特定用戶或使用者的請求在下一次調用時會回到相同的組件，這可能是因爲特定的數據緩存。但突然之間，編排平臺無法進行簡單的負載均衡路由、重定位或副本伸縮了。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"跨組件的兩段事務提交也應該避免，因爲REST和基於事件的協議的語義不支持標準化事務協調通信。每個細粒度組件的獨立性及其最小化狀態，使得在任何情況下，2PC協調所需的耦合都存在問題。因此，必須使用處理分佈式更新的方法，如Saga模式，並且要考慮前面提到過的最終一致性問題。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"請注意，不要把最小化狀態的概念和與保存狀態的下游系統進行交互的組件相混淆。例如，一個與持久化狀態的數據庫或遠程消息隊列進行交互的組件。不管怎樣，這並不會使組件成爲有狀態的，它只是將有狀態請求傳遞到下游系統。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"總會有一些組件需要狀態。像Kubernetes（K8s）這樣的平臺，通過額外的特性及相關限制，提供了處理有狀態組件的機制。關鍵是將狀態最小化，當確實有狀態時，要明確地聲明和管理它。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"不可變部署"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果我們要將控制權交給一個雲平臺，由它來部署和管理我們的組件，就需要讓它儘可能簡單。簡而言之，我們希望確保只有一種方法來部署組件，並且一旦部署，就不能更改。這稱爲不可變部署，它有以下三個特點："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"基於鏡像的部署——部署一個固定的“鏡像”，包含所有依賴項。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"無運行時管理——部署後不直接對運行時進行更改。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"通過替換進行更新和回滾——通過部署組件鏡像的新版本來執行更改。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"通過“適當的解耦”，我們已經知道，組件應該是自包含的。我們需要有一種方式來打包代碼和所有的依賴，從而實現部署的一致性。語言總是會提供機制將代碼構建爲不變的“可執行文件”，所以這並不是什麼新東西。容器使我們有機會更進一步，將代碼\/可執行文件與特定版本的語言運行時，甚至是操作系統的相關內容打包到一個不變的“鏡像”中。我們還可以包括安全配置，比如要提供哪些端口，以及關鍵元數據，比如要在啓動時運行什麼進程。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"這使我們能夠一致地部署到任何環境中。開發、測試和生產都將具有相同的全棧配置。集羣中的每個副本都是相同的。容器鏡像是一個不變的黑盒，可以部署到任何環境、任何位置和（在理想情況下）任何容器平臺上，並且行爲表現完全相同。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一旦啓動，鏡像就不能在運行時進一步地配置，以保證它始終一致。這意味着它不會應用操作系統補丁，不會應用新版本的語言運行時，也不會加入新代碼。如果你想要更改其中的任何內容，就必須構建一個新的鏡像，然後部署它，並逐步淘汰原來的鏡像。這保證我們在任何時候，都對部署到環境中的東西有絕對的把握。它還爲我們提供了非常簡單的方法，讓我們可以回滾任何此類更改。由於之前的鏡像還有，我們可以簡單地重新部署它——當然，前提是你堅持了“最小化狀態”。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"傳統的環境是在部署任何代碼之前預先構建好的，然後隨着時間推移，通過在上面運行命令來對它進行維護。很容易看出，這種方法經常會導致環境之間的配置差異。不可變部署方法確保始終將代碼與其自身的所有依賴項副本和測試時的配置一起部署。這提高了測試可信度，讓我們可以更輕鬆地重建環境，用於功能、性能和診斷測試，並有助於保證彈性擴展的簡單性。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"請注意，理論上我們可以利用虛擬機鏡像進行基於鏡像的部署，但是它們會非常大，難以管理。因此，在一個虛擬機實例上運行多個組件會更高效，這意味着代碼與其依賴項之間不再存在一對一的關係。"}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","marks":[{"type":"strong"}],"text":"零信任"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"簡單地說，零信任就是假定所有威脅都可能發生。威脅建模已經有很長的歷史了，但是雲原生解決方案的特點迫使我們重新考慮這些威脅以及如何有針對性地做好防護。以下是零信任方法的一些（但不是全部）關鍵原則："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"最小特權——在默認情況下，組件和人員應該都沒有特權。所有特權都是基於身份明確授予的。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"隱式數據安全——數據應該始終是安全的，無論是靜態數據，還是在傳輸中的數據。"}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"安全性左移（DevSecOps）——安全性應該在生命週期中儘可能早的被包含進來。"}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"衆所周知，傳統的基於防火牆的訪問控制會導致對內部網絡的不當信任。實際上，在網絡中創建受信任區域充其量只是第一道防線。身份需要成爲新的邊界。對於我們試圖保護的對象，我們應該基於身份進行細粒度地訪問控制：用戶、設備、應用程序組件和數據。基於這些身份，我們應該只提供最低限度的特權。默認情況下，組件之間的連接應該顯式聲明並加以保護（加密）。管理員應該被精確授予其角色必需的特權。我們還必須定期執行漏洞測試，以確保沒有權限升級的路徑。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我們必須接受這樣一個事實：在任何時候，應用程序都有責任保證用戶數據的安全。現在有更成熟的方法可以關聯來自多個源的數據，出於惡意推導出新的信息。應用程序應考慮其所存儲的所有數據的隱祕性，加密任何靜態以及傳輸中的敏感數據，並確保只有明確獲得過許可的身份才能訪問這些數據。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"應用程序組件必須從一開始就安全地構建。我們必須假設所有環境，不僅僅是生產環境，都容易受到攻擊。但更重要的是，通過安全關切“左移”，我們可以確保應用程序設計人員儘早與安全團隊協作，並無縫地嵌入安全實踐，例如在構建和部署管道中。這進一步提高了速度、一致性和信心，我們可以持續地將代碼交付到生產環境。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在下一篇文章中，我們將探討雲技術和基礎設施的獨特之處，以瞭解它們如何賦能雲原生方法。"}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"查看英文原文："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/medium.com\/swlh\/the-how-of-cloud-native-architecture-and-design-perspective-7bb629255bb3","title":"","type":null},"content":[{"type":"text","text":"The “How” of Cloud Native: Architecture and Design Perspective"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"延伸閱讀："}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/article\/Qj0SqAEDZZyVOPyhyTXY","title":"xxx","type":null},"content":[{"type":"text","text":"避免不完全的雲原生（二）：人員和流程要素"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/article\/PfHdeTgybyC47SpAB2fo","title":"xxx","type":null},"content":[{"type":"text","text":"避免不完全的雲原生（一）：雲原生到底意味着什麼？"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"link","attrs":{"href":"https:\/\/www.infoq.cn\/article\/LIRjAI0mhsClCooPtzLw","title":"","type":null},"content":[{"type":"text","text":"避免不完全的雲原生"}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}}]}