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]。
此外,对那些链路极长、逻辑极复杂的系统来说,"高可用"架构往往是一个伪命题,只要是人开发的系统,代码就总会携有缺陷。看似”稳定“的系统,它可能在随机某个时刻出现突发的问题。作为负责系统稳定的架构师唯有具备深厚的基础和广泛的知识面,此后面对突发故障,虽可能无法立即解决,但至少可以准确地看出源头,从而找到解决问题的正确路径。
受限于笔者的功力,内容有诸多不足,但”足够的广度和一定范围内的深度“也是本书着重想要表达的内容。
约束理论:在一条业务链中,瓶颈节点的节拍决定了整条链的节拍,即任何一个多阶段生产系统,如果其中一个阶段的产出取决于前面一个或几个阶段的产出,那么产出率最低的阶段决定着整个系统的生产能力。约束即阻碍企业有效扩大产出能力、降低库存和运行成本的环节。 ↩︎