从架构角度谈谈云原生架构

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的案例中，实际上从提供解决方案的角度，希望一部分不随着客户变化的服务放在云端，另一部分定制化服务放在客户本地，这种混合云的方式。
这种方式下，需要客户的角度要考虑是否有数据泄露的问题，包括数据存储的安全性，是否可以存在云端，是否足够的安全措施；本地和云端通信的安全性，可靠性等。

知乎本人文章地址