云原生：江湖传说

• 云原生，Part 0：什么是 Image ？
• 云原生，Part 1：什么是 Container ？
• 云原生，Part 2：什么是 Pod ？
• 云原生：江湖传说

首先，云（Cloud）是什么？

不是云里雾里，所谓云，我的理解是物理资源的虚拟化，以前是你必须要买一台台硬邦邦的金属，有个机房，放自己的机房里，管水管电，这些管理维护工作都要投入一定的人手。云来了以后，她说你不用管物理机器了，你想用的无非就是操作系统，我提供给你，你想用什么去和操作系统打交道——shell、人机交互界面都提供给你，这样水电都不用你管，你只管给兄弟打点钱就行了😁。

核心逻辑就是企业生存关心的是自己的业务逻辑，而远离业务的这些工作可以交给别人（云厂商）来打理，同意这样干的人多了，业务量起来以后，云厂商能挣着钱了，就专干这个，而且量大从优，企业摆脱了非核心业务逻辑的负担，同时又获得了专业的服务，香不香？这就是通过市场来进行资源的优化配置。

现在市面上很多公有云——阿里云、腾讯云、网易蜂巢、青云等等，不一而足。博主作为传统金融企业的从业人员，出去调研时，对方布道人员一般都会甩给你这样一张基础设施演进图。

看，在“软件正在吞吃世界”的豪言壮语背景下，企业的技术基础设施也正在被拆解蚕食——这是好事。从水电到应用，一层层地被剥离出来，交给专门的厂商负责，而企业最终留下来的只有自己的核心业务诉求。

把物理基础设施吃掉的，叫 IaaS（Infrastructure as a Service）——基础设施即服务；把操作系统都吃掉的，叫 PaaS（Platform as a Service）——平台即服务；把所有的都吃掉，叫 SaaS（Software as a Service）——软件即服务。IaaS 和 PaaS 都有叫云的，IaaS 就不说了，PaaS 有叫着容器云的，基于容器技术进行资源管理分配。当然，别忘了这些划分是从不同人员的角度来说的，比如在企业里，可能这样——运维同学看到的是 IaaS，技术同学看到的是 PaaS，业务同学看到的则是 SaaS。

到这里我们可以引出 Heroku 了，Heroku 就是一个有名的 PaaS 平台，她的用户只需要操心自己的应用代码，Git push 上去就会嗖嗖嗖地给你打包、测试、部署好，什么横向纵向伸缩、应用运行指标监控、负载均衡、失败重试、应用/数据回滚，都给你准备好了。不多说了，再说就要收钱了。总之 Heroku 对如何使用 PaaS 平台构建应用充满了丰富的实战经验，并提炼了 12-factor，大概意思我直接剪过来：

• 1. 基准代码
  • 一份基准代码，多份部署
• 2. 依赖
  • 显式声明依赖关系
• 3. 配置
  • 在环境中存储配置
• 4. 后端服务
  • 把后端服务当作附加资源
• 5. 构建，发布，运行
  • 严格分离构建和运行
• 6. 进程
  • 以一个或多个无状态进程运行应用
• 7. 端口绑定
  • 通过端口绑定提供服务
• 8. 并发
  • 通过进程模型进行扩展
• 9. 易处理
  • 快速启动和优雅终止可最大化健壮性
• 10. 开发环境与线上环境等价
  • 尽可能的保持开发，预发布，线上环境相同
• 11. 日志
  • 把日志当作事件流
  • 正常内容输出到 stdout，异常内容输出到 stderr
• 12. 管理进程
  • 后台管理任务当作一次性进程运行

现在可以回来说说云原生（Cloud Native）应用。

在云计算平台上部署应用，叫云上应用，而应用在设计开发时就考虑到了云平台的支持，进行无缝对接，天生契合，就可以叫云原生应用了。何谓契合？最初就是以匹配 12-factor 这 12 个最佳实践原则来说的，后来 Kevin Hoffman 又补充了三点：

• 13. 遥测
  • 提供应用的指标数据：应用性能监控、业务领域指标、健康及系统日志
• 14. 认证和授权
  • 所有暴露的端点都要做安全检查
• 15. 一等公民：API
  • 优先设计 API，在服务生态中通过 API 划定交互边界

集齐了15颗龙珠，我们落地云原生应用就有底气了。

在2015年7月，云原生的大本营建立了，她就是 CNCF（Cloud Native Computing Foundation）——云计算基金会。CNCF 在 V1.0 版中是这样 定义 云原生应用的：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

世上就没有只收获而不需要付出的事情，除非耍流氓把成本转嫁给别人。为了收获云原生承诺的这些好处，除了需要一大帮朋友来共建一个大大的生态，对准备采用云原生的企业来说也属实是一项不小的工程。怎么把我们传统的应用乾坤大挪移到云原生的赛道上，官方给出了一条打怪升级路径，按部就班就可早登极乐。

咱们来看看这10个升级台阶：

1. 容器化
   • Docker 是一切故事的起点，所以让我们先从使用 Docker 开始，先将应用容器化；
   • 随着时间推移，（你膨胀了）应该渴望将应用分拆为合适的体量，进化到微服务；
2. CI/CD
   • 设置 持续集成/持续交付，使得对源代码的变更能够自动产生新的容器、自动测试、存档甚至发布到生产；
   • 设置自动发布、回滚、测试
   • 推荐 argo 来实践 GitOps
3. 编排和应用定义
   • k8s 是市场领先的编排解决方案
   • 选择经过认证的 k8s 发行版、托管平台，或 cncf.io/ck 里列举的安装程序
   • 使用 Helm Charts 来完成应用定义、安装、升级
4. 可观测性和分析
   • 需要一套方案解决监控、日志收集、跟踪
   • 监控推荐 Prometheus、日志收集推荐 Fluentd、跟踪推荐兼容 OpenTracing 标准的 Jaeger
5. 服务代理、发现、网格
   • CoreDNS 可以用于服务发现
   • Envoy、Linkerd 可以用于搭建服务网格架构
   • 以上都提供了健康检查、路由、负载均衡功能
6. 网络、策略与安全
   • 为了使网络更灵活，应该采用兼容 CNI 标准的插件：Calico、Flannel、Weave Net
   • OPA 作为通用的策略引擎，用于授权和准入控制
   • Falco 作为异常检测引擎
7. 分布式数据库、分布式存储
   • 现在你需要更加具有弹性和灵活性的数据库，Vitess 是一个很好的选项
   • Rook 是一个存储编排器，整合了多种存储方案
   • Etcd 存储了集群节点的信息，是 k8s 的大脑
   • TiKV 是一个支持分布式事务的 K-V 存储方案
8. 流化、消息化
   • 如果想要一个比 restful 接口更高性能的方案，可以采用 gRPC、NATS
   • Cloud Event 是一份描述通用事件数据的规范
9. 容器注册、运行时
   • 可以采用 Harbor 来作为镜像管理的仓库，用于存储、签名、扫描
   • 容器运行时需要采用兼容 OCI 标准的方案，如 containerd、CRI-O
10. 软件分发
    • 如果需要做到安全的软件分发，可以采用 Update Framework 的一个实现—— Notary

来吧，屠龙的勇士