1.6 云原生架构设计概论
理解云原生的代表技术之后，这一节，我们再谈谈如何利用这些技术切入到架构设计中。
没有完美的能够应对所有变化的架构，技术架构很多时候是依据当时的技术条件来设计的，当制约因素改变的时候，技术架构也要相应变化。所以说好的架构是演进而来的，不是设计出来的，架构演进的目的一定是解决某一类问题，我们不妨从“解决问题”的角度出发，来聊一下云原生架构如何设计，如图 1-38 所示，传统架构向云原生架构的演进。
图1-38 传统架构与云原生架构对比
- 为了解决单体架构 “复杂度问题”，使用微服务架构。
- 为了解决微服务间 “通讯异常问题”，使用治理框架 + 监控。
- 为了解决微服务架构下大量应用 “部署问题”，使用容器。
- 为了解决容器的 “编排和调度问题”，使用 Kubernetes。
- 为了解决微服务框架的 “侵入性问题”，使用 Service Mesh。
- 为了让 Service Mesh 有 “更好的底层支撑”，将 Service Mesh 运行在 Kubernetes 上。
从单个微服务应用的角度看，自身的复杂度降低了，在“强大底层系统”支撑的情况下监控、治理、部署、调度功能齐全，已经符合云原生架构。但站在整个系统的角度看，复杂度并没有减少和消失，要实现“强大底层系统”付出的成本是非常昂贵（很强的架构和运维能力）。
为了解决项目整体复杂度，选择上云托管，将底层系统的复杂度交给云基础设施，让云提供保姆式服务，最终演变为无基础架构设计，通过 YAML 声明式代码、编排底层基础设施、中间件等资源，即应用要什么，云给我什么，企业最终会走向开放、标准的“云”技术体系。
1.7 云原生时代对架构师的要求
云原生架构是”优雅的、灵活的、弹性的…“，但云原生技术也过于抽象和复杂。云原生架构中，复杂只是被转移到云基础设施中，并没有无故消失。作为架构师，如果有志构建一个高可用的云原生架构，对能力要求已提升到史无前例的程度。总结来说，在云原生工程实践中除掌握 Docker 和 Kubernetes，还需要知晓以下几个领域，如图 1-39 所示。
图 1-39 云原生代表技术栈
- 容器和镜像：Docker、containerd、CRI-O、Kata Containers。
- 镜像仓库：Harbor、Nydus。
- 应用封装：Kustomize、Helm。
- 持续集成：Gitlab、Tekton。
- 持续部署：FluxCD、argoCD。
- 容器编排：Kubernetes。
- 网关：Ingress-Nginx、APISIX。
- 日志：Fluentd、Grafana loki。
- 监控：Grafana、Prometheus。
- 应用开发：Nocalhost。
行文至此，云原生技术概论的篇章已经结束，细心的读者会注意到一个小问题，本书的命名是“深入架构原理…”，而不是“深入云原生架构…”，虽然云原生是一个足够宏观、广泛的课题，但对于构建高品质的软件产品而言，其影响服务质量还包括前端、网络、后端等等，云原生并不能涵盖所有环节，约束理论也是要求优化整体而不是单个的“孤岛^1。
此外，对那些链路极长、逻辑极复杂的系统来说，"高可用"架构往往是一个伪命题，只要是人开发的系统，代码就总会携有缺陷。看似”稳定“的系统，它可能在随机某个时刻出现突发的问题。作为负责系统稳定的架构师唯有具备深厚的基础和广泛的知识面，此后面对突发故障，虽可能无法立即解决，但至少可以准确地看出源头，从而找到解决问题的正确路径。
受限于笔者的功力，内容有诸多不足，但”足够的广度和一定范围内的深度“也是本书着重想要表达的内容。
添加评论