1、云原生架構起源

隨著云服務商的成熟，客戶面臨著將服務直接使用云平臺的服務部署在云平臺上，或者采用本地和云上混合部署的模式來對外提供服務，從解決方案的角度來說，采用云原生架構的優點有：
可以利用云服務的管理，方便的的針對特定服務進行收縮和擴容
可以利用云服務的成熟的監控，針對服務做全鏈路的監控
當然，采用云原生的架構也有缺點，比如：
數據的安全問題，怎么樣保證數據不被泄露
數據遷移問題，如果要更換一個服務提供商怎么遷移，如果要不想使用云服務了，后續數據怎么遷移到本地，作為一個完整的解決方案，都需要對應的策略

2、云原生架構的適用場景

有服務需要動態伸縮，客戶請求的峰值很高，平常的服務有沒有什么壓力
有容災需求，從IT的角度來說自己搭建很麻煩
服務SAAS化，需要針對多個用戶使用，希望擴容更加靈活，可以針對不同的客戶有特殊的處理
一部分中等客戶不希望搭建自己的機房來進行管理，希望直接使用云，系統有一定的規模，可能涉及到動態擴容

3、云原生架構的要點

3.1 云原生的能力

?容器化與編排
?能力：使用容器（如Docker）打包應用及其依賴，通過編排工具（如Kubernetes）自動化管理容器生命周期。
?示例：基于K8s的彈性擴縮容、滾動更新和故障自愈。
?微服務化
能力：將單體應用拆分為松耦合的微服務，每個服務獨立開發、部署和擴展，這個能力本身是技術架構需要考慮的點，并不一定是云提供廠商提供的能力
?示例：使用Spring Cloud、gRPC或服務網格（如Istio）實現服務間通信。
?持續交付與DevOps
?能力：通過CI/CD流水線（如Jenkins、GitLab CI、Argo CD）實現自動化構建、測試和部署。
?示例：基于GitOps的聲明式部署（通過Git倉庫管理基礎設施狀態）。
?聲明式API與自動化
?能力：通過聲明式配置（如Kubernetes YAML、Terraform）定義系統目標狀態，依賴工具自動調整實際狀態。
?示例：使用Helm Chart管理K8s應用模板。
?可觀測性
?能力：集成監控（Prometheus）、日志（ELK Stack）、追蹤（Jaeger）實現全棧可見性。
?示例：通過Grafana Dashboard實時展示應用性能指標。
?服務治理與彈性設計
?能力：實現熔斷（Hystrix）、限流、重試等容錯機制，保障系統高可用。
?示例：通過Istio的流量管理策略實現金絲雀發布。
?無服務器（Serverless）能力
?能力：按需使用函數計算（如AWS Lambda）或事件驅動架構（如Knative），減少運維負擔。
?示例：處理異步任務（圖片壓縮、數據處理）。
?多云與混合云支持
?能力：通過跨云編排工具（如Karmada、Cluster API）統一管理多云資源。
?示例：在AWS和Azure之間動態遷移負載。

3.2 設計思考

3.2.1 弱使用

使用情況：將云服務提供商當做一個虛擬主機+中間件提供商
考慮因素：使用云服務商動態增加虛擬機器的能力，另外使用中間件因為云中立的中間件集群和監控都比較完善
注意事項：
是否需要自己基于虛擬主機搭建自己的k8s或者ci/cd環境，還是利用云提供商的是一個考慮因素，從架構的角度來說，自己自己搭建k8s，使用云上的docker鏡像倉庫，本地打包到鏡像倉庫上去即可，CI/CD還是本地環境進行
關于云上承載的服務，建議納入到統一監控當中，可以使用云上的，也可以自己搭建
優缺點：和云服務廠家的綁定比較少，是優點也是缺點，有 一些云服務需要數據和資源都在云服務廠商上才能使用，但是遷移云的時候相對比較輕量一些。

3.2.2 強使用

使用情況：將云服務提供商當做一個虛擬主機+服務編排+中間件提供商
考慮因素：使用云服務商動態增加虛擬機器的能力、服務編排的能力和中間件的能力
注意事項：
CI/CD是否也要使用云上的服務，這一部分可以不強綁定
統一監控怎么設計，在服務編排也使用云上服務的話，統一監控只能接入云上的監控平臺
優缺點：這種場景下和云服務商的綁定比較死，要充分考慮到云上遷移的工作量

3.2.3 小結

在弱使用和強使用的場景下，整體的監控以及服務失敗后如何處理這二個方面，非常影響我們的選擇，可以直接選擇云上的服務，但是遷移到另外一個云可能又不太一樣，完全搭建自己一套也是一種選擇，但是可能工作量又比較大。

4、云原生架構中的混合云和云中立

4.1 云中立

從開發的角度來說，一旦使用了云服務，可能就和這些服務提供商有了強綁定，比如：如果使用了對象存儲，那么各家的對象存儲還是有細微的差異，這種差異針對上層程序員來說非常不友好；另外，一旦涉及到遷移到另外的云上，這個改動是特別大。
從架構的角度來說，盡量的提供一個抽象的中間服務來屏蔽這些底層服務的不同，盡量讓上層服務不要使用這種云廠商特定的接口API，這種設計的思路就是云中立設計的思路，典型的場景是針對各個云提供商的對象存儲做一層封裝適配供上層服務使用。

4.2 混合云部署

典型的，在to B的案例中，實際上從提供解決方案的角度，希望一部分不隨著客戶變化的服務放在云端，另一部分定制化服務放在客戶本地，這種混合云的方式。
這種方式下，需要客戶的角度要考慮是否有數據泄露的問題，包括數據存儲的安全性，是否可以存在云端，是否足夠的安全措施；本地和云端通信的安全性，可靠性等。

知乎本人文章地址