服務存儲設計模式：Cache-Aside模式
Cache-Aside模式一種常用的緩存方式，通常是把數據從主存儲加載到KV緩存中，加速后續的訪問。在存在重復度的場景，Cache-Aside可以提升服務性能，降低底層存儲的壓力，缺點是緩存和底
圖片
Gartner 將平臺工程列為 2024 頂級戰略技術趨勢之一
說起平臺工程（Platform Engineering） ，經常聽到有人說是：新瓶裝（平臺工程）舊酒（DevOps）。
今天根據過去自服務平臺的實踐經驗，聊聊我所理解的平臺工程。
說到平臺工程，不可不免地要聊聊云原生，不過這里不會針對是否轉向云原生進行討論。
云原生的三駕馬車：微服務、Kubernetes、DevOps。根據過往的實踐經驗，我認為云原生技術平臺的核心能力（包括但并不限于）可概括為：
容器平臺：專注于容器化技術和 Kubernetes 編排，實現應用的彈性、高效存儲和網絡通信。這為微服務和 DevOps 的實現提供了基礎架構支持。
微服務平臺：集中管理微服務，包括統一的服務治理、配置管理、API 網關和支持多樣的微服務框架，以適應復雜的服務交互和靈活的開發需求。
監控平臺：提供全方位的監控系統，包括日志收集、性能指標監控、鏈路跟蹤、實時告警以及監控數據的可視化展示，助力于系統的穩定運行和故障迅速定位。
DevOps 集成平臺：集成持續集成和持續部署（CICD）流程，以及文檔中心和代碼質量管理，實現自動化、高效和標準化的軟件開發和運維流程。
對于風靡多年的云原生（近來也有降溫的趨勢？），業界的褒貶不一：提升了研發效率和資源的利用率，；浪費資源、部署維護困難、可觀測性變差等等。
云原生技術所面臨的眾多負面反饋，很大程度上源于其本身的復雜性。云原生平臺向開發人員展現了過多的復雜性。
云原生技術，盡管帶來了許多優勢，比如靈活性、可擴展性和高效的資源利用，但同時也引入了一定的復雜性：
技術棧的復雜性：云原生環境通常涉及到容器化、微服務架構、CI/CD、以及基于 Kubernetes 的容器編排等技術。這些技術各自有其學習曲線，并且技術之間需要集成并協同工作，增加了系統的整體復雜性。
管理和運維的復雜性：在云原生環境中，應用程序通常被分解為多個微服務，每個微服務部署在不同的容器中，這使得監控、日志記錄、故障排查和性能優化變得更加復雜。
網絡復雜性：微服務架構意味著服務之間有大量的網絡通信，再疊加容器、混合多云的網絡環境，管理這些服務間的網絡流量、確保高可用性和網絡安全，以及實現服務發現等都增加了網絡管理的復雜性。
可觀測性和監控的挑戰：確保對在不斷變化的環境中運行的眾多微服務有足夠的可見性，需要復雜的監控和日志系統。
安全挑戰：云原生架構中的分布式和動態性質引入了新的安全挑戰。例如，需要確保容器安全、服務間通信的安全，以及在動態環境中持續地管理和更新安全策略。
這些復雜性給開發人員帶來了顯著的摩擦和認知負擔，從而降低了他們的開發體驗。在專注于業務開發的開發人員與底層基礎設施之間，形成了一個模糊的交界區域。平臺工程正是專注于這個模糊地帶，旨在縮小這一差距并簡化開發流程。
平臺工程是一個膠水層。
圖片
平臺工程是一門在云原生時代為軟件工程組織設計和構建工具鏈及工作流程的學科，旨在提供自助服務能力。平臺工程師提供的綜合產品通常被稱為“內部開發者平臺”，涵蓋了應用程序整個生命周期的運營需求。
Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era. Platform engineers provide an integrated product most often referred to as an “Internal Developer Platform” covering the operational necessities of the entire lifecycle of an application.
來自 平臺工程社區的介紹[1]
平臺工程致力于構建和維護一個橋梁，這座橋梁把復雜的基礎設施轉化為簡化的抽象，使得開發人員能夠專注于業務邏輯的開發，無需深入鉆研底層技術細節。同時，他們也努力將業務邏輯層的通用功能整合并下沉，進一步簡化開發流程。
此處，我更傾向于將“工程”理解為一個動詞，即對平臺進行工程化。
軟件開發的過程標準化、系統化和規范化是為了提高軟件開發效率、質量和可維護性。這三個方面通常包括以下內容：過程標準化、系統化、規范化。
隨著平臺工程化水平的提升，開發人員得以享受到更高水平的自服務能力。這樣的自服務平臺的實施，進一步縮短了開發人員與基礎設施平臺之間的距離，使得開發人員能夠更便捷地使用平臺資源，而無需深入了解底層技術細節。
自服務平臺正是工程化的產物，或者是平臺工程的具象化。
自服務平臺使開發人員能夠直接管理和操作資源，讓他們親自參與到軟件的整個生命周期中，同時無需關注幕后的基礎設施和實現細節，并減少了平臺團隊成員的直接介入。這種平臺遵循著“You build it, You run it”的理念，但不強求開發人員深入理解底層技術（“Know-how”）。
從我的角度看，自服務平臺更像是流程和工具的結合體。在工具層面，無論是開源還是商業軟件，都提供了對通用能力的抽象。然而，在流程方面，由于每個企業都有自己特定的管理需求和對支撐部門的依賴，流程設計上會有所不同。雖然工具可能實現標準化，但流程很難做到這一點。
我認為，將平臺工程簡單比喻為‘新瓶裝舊酒’是不夠全面的。實際上，平臺工程代表的是對傳統方法（例如 DevOps）的進一步沉淀和提升，為其賦予了新的表現形式和能力。
在技術與人的互動中，我們不應該忽視連接和協調的重要性。軟件系統作為現實世界的一個反映，應當始終堅持以人為本的原則。
[1] 平臺工程社區的介紹: https://platformengineering.org/blog/what-is-platform-engineering
本文鏈接：http://www.www897cc.com/showinfo-26-66198-0.html聊聊我所理解的平臺工程
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： C++范圍for循環詳解
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號