我对云原生架构的理解

最近在团队简单分享了云原生相关的东西,这里整理出来。

我在梳理材料的时候主要参考了《cloud native infrastructure》和《beyond 12 factor app》,这两本书讲的非常好(我个人的学习习惯是要系统学习一门知识首先就是找书或者doc完整过一次,blog只是辅助作为补充),尤其是第一本,建议大家看下。

这里不讲具体的实践和工具(比如k8s)的使用,因为官网的文档和一些blog讲的很好了,这里只说一下宏观层面的一些东西,了解技术细节看doc或者google就好了。也只有了解了宏观的东西,有了一个框架才不至于过早陷入细节,一叶而障目。

cloud native是什么

cloud native,这个词一看就给人高级的感觉,中文翻译是“云原生”,也是每个字都透露着高级感😆。CNCF对cloud native的定义如下:

看着很拗口和繁琐,我这里按照我的理解来解构一下。

首先看一个技术需要了解其背景。云原生出现的背景就是最近七八年云计算发展迅速,大家越来越多的把业务迁移上云。但是如何发挥云的威力,在云上跑进程和传统自建机房物理机跑进程有什么不同?所以就慢慢总结出了一些最佳实践的东西,这些最佳实践的集合就是云原生技术。所以云原生不是特指一个技术,而是一组最佳实践的集合。

我认为要理解云原生的核心之一就是区分两个概念:云原生应用进程(cloud native app,简称CNA)和运行这些进程的云原生架构(cloud native infrastructure,简称CNI)。

普通的App要想满足CNA,需要具备如下的条件:

所以app云原生化的过程不是不需要大家改代码,还是需要改的。不是把之前部署在物理机的进程打包放到k8s跑起来就完了。

有了CNA之后,CNA不能直接放到机器上运行,而是放到CNI上运行,CNI来CNA编制成一个完整的服务。CNA和CNI有明确的分工,CNA只负责业务的实现,CNI来负责服务发现,proxy,弹性,日志收集,灰度部署等等各种“花活”。所以CNA变得更薄。CNI变得更厚(所以为什么k8s和istio都是蛮复杂的东西)。这样CNA的开发复杂度会降低。

实现云原生常用的技术:

  • 微服务架构
  • 健康检查(一般是服务暴露出来一个/heath API,外界通过curl这个API获知服务状态)
  • Telemetry Data/遥感数据,就是收集一些metric,一般采用把数据格式化之后推动到prometheus等数据数据库,也可以从ES中query得出
  • Design for Failture,假设任何地方都会失败,比如网络会失败,node会变得不可用等等,要设计容错机制
  • 声明式API,k8s的设计就是一个很好的例子,我们只需要描述系统期望的状态是什么样子就好了,k8s会不断去拟合帮助我们把系统实际状态拟合为我们期望的状态。

cloud native 不是什么

详细看到这里大家已经知道答案了,不是把进程放到k8s跑起来就是cloud native了,不是用了公有云就是cloud native了,这只是一个开始而已。

如何在组织内部使用 cloud native

使用cloud native其实是对组织和协作的一次变革,并不仅仅是技术的因素,需要业务开发,infra团队等等一起齐心协作才可以做到,一个巴掌拍不响。

流程需要变革,如果每次申请服务器都要层层筛选,搞半天才能申请到一台新机器也不适合,应该改变组织的做事方式。

人的问题解决了,业务开发和infra团队都意识到时需要大家一起才可以完成的事情之后,剩下的技术问题就相对好办了,很多时候最难的问题往往是人的问题。

什么时候不该用

在业务刚起步等等时候不要用,因为云原生需要一定的前期投入研究的成本,业务刚起步流量也不大的时候没必要用云原生这一套。

避免没研究清楚就上业务。