聊聊云原生和微服务架构

什么是云原生 ？

云计算和云原生

云计算不同于传统的自建机房，云计算就是将计算的抽象为基础设施然后通过网络分发，得益于云计算的无限扩展能力，使得“云计算”就像自来水厂一样，我们可以随时接水，并且不限量，按照自己家的用水量，付费给自来水厂就可以。以下云计算的五个基本特征。

以下是一些目前比较主流的公有云厂商：

云原生顾名思义，就是基于云计算特性所设计的应用服务，得益于云计算快速发展，基于云计算特性所设计的云原生应用相比传统的单体应用在安全性，扩展性，快速迭代，运维等各方便都有巨大的领先优势。云原生并不是指某一种技术，它是一种架构设计理念，只要符合这种架构设计理念的应用，都可以称为 云原生应用， 看看 CNCF 官方对于云原生的定义：

容器云技术的发展

云原生是依赖容器作为技术技术来实现的，但是容器并不是什么新潮技术，以下是容器云技术的发展历史，其中有几个关键的历史节点

早在 06 年的时候 Amazon 基于容器技术构建的 IaaS 平台 AWS，成为所有云计算厂商的鼻祖，由于技术领先的优势 AWS 现在依然也是云计算行业老大

13 年 Docker 的诞生进一步简化容器技术的使用门槛，Docker 公司自以为掌握云时代的核心技术，开始野心勃勃的有意挑战传统的云计算大厂例如 RedHat，Google 的江湖地位，公司股价也是一骑绝尘，却不料被 RedHat 联合 Google 发布的 Kubernetes 击溃，Kubernetes 的成功让大家以为容器技术并非云时代的核心技术，容器编排 才是核心技术。（备注：2020 年 K8S 官方宣布只要满足 K8S CRI 接口的容器均可以被 K8S 进行编排，Docker 被时代抛弃）

2015 年借助 Kubernetes 的成功，Google 宣布成立 CNCF 基金会，这是云原生时代的代表性的组织。致力于完善云时代的基础设施，帮助开发者构建更出色的产品

下图是 CNCF 的全景图：

为什么用云原生架构 ？

主要从 4 个方面来聊聊：

自动恢复

服务安全

弹性扩展

快速发布

自动恢复

早期刚参加工作的时候接手过一个年久失修的遗留系统，这个系统又一个很神奇的 Bug 每天晚上会自动宕机，谁也不知道什么原因。只要重启就能恢复正常，当时为了保证业务系统的正常使用，我总是在半夜爬起来重启服务器，我当时就在想：要是有一种工具可以检测到系统宕机后，就自动重启恢复就好了，这样我就可以睡一个好觉了。

这就是云原生架构想要解决的第一个问题：应用系统挂掉后，无需人工的介入，可以自动在最短的时间恢复来保证系统的健壮性。

当然除了未知的 BUG，还有诡异的异常会导致服务崩溃了，例如：

代码没写好，系统发生 OOM

服务器本身的资源不足

死锁，磁盘，网络等问题

等等……

Kubernetes Pod 应用自动恢复的三种策略：

spec: restartPolicy: Always # 当容器终止退出后，总是重启容器，默认策略 containers: - image: nginx name: web

Always：当容器终止退出后，总是重启容器，默认策略

OnFailure：当容器异常退出（退出状态码