wxya云原生架构
云原生架构的演进
- 为了解决单体架构“复杂度问题”，使用微服务架构。
- 为了解决微服务间“通讯异常问题”，使用治理框架 + 监控。
- 为了解决微服务架构下大量应用“部署问题”，使用容器。
- 为了解决容器的“编排和调度问题”，使用 Kubernetes。
- 为了解决微服务框架的“侵入性问题”，使用服务网格。
- 为了让服务网格有“更好的底层支撑”，将服务网格运行在 Kubernetes 上。
从单个微服务应用的角度看，自身的复杂度降低了，在“强大底层系统”支撑的情况下监控、治理、部署、调度功能齐全，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现“强大底层系统”付出的成本（人力成本、资源成本、技术试错成本）是非常昂贵的。
为了降低成本，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计。
最后，通过 yaml 声明式代码、编排底层基础设施、中间件等资源，即应用要什么，云给我什么，企业最终走向开放、标准的“云”技术体系。
1 容器运行时：Docker、Containerd、CRI-O、Kata Containers。
2 镜像和仓库：Harbor、Dragonfly、Nydus。
3 应用封装：Kustomize、Helm。
4 持续集成：Gitlab、Tekton。
5 持续部署：ArgoCD、FluxCD。
6 容器编排：Kubernetes、Koordinator、Volcano。
7 服务网格: Istio、Envoy、Linkerd。
8 网关：Ingress-Nginx、Kong、APISIX。
9 日志：Grafana Loki、Elastic Stack、ClickHouse。
10 监控：Prometheus、Grafana。
11 可观测：OpenTelemetry。
12 机器学习/混合部署：volcano、Koordinator...。
解读：概念随着新的技术发展而演化
- 第一阶段：容器化封装+自动化管理+面向微服务
- 第二阶段：DevOps、持续交付、微服务、容器
- 第三阶段：DevOps、持续交付、容器、服务网格、微服务、声明式API
结构图
前端可以通过CDN + OSS方式打包部署，或者SSR
后端架构一般就是这样
Loading...