Spring Cloud？Dubbo？还是K8s？

本篇分享主要围绕以下 4 个主题进行：

• 什么是云原生?
• 为什么要用云原生架构?
• 微服务的概念
• 微服务的技术选型

什么是云原生?

①云计算和云原生

云计算不同于传统的自建机房，云计算就是将计算的抽象为基础设施然后通过网络分发。

得益于云计算的无限扩展能力，使得“云计算”就像自来水厂一样，我们可以随时接水，并且不限量，按照自己家的用水量，付费给自来水厂就可以。

以下云计算的五个基本特征：

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

云原生顾名思义，就是基于云计算特性所设计的应用服务，得益于云计算快速发展，基于云计算特性所设计的云原生应用相比传统的单体应用在安全性，扩展性，快速迭代，运维等各方便都有巨大的领先优势。

云原生并不是指某一种技术，它是一种架构设计理念，只要符合这种架构设计理念的应用，都可以称为云原生应用。

看看 CNCF 官方对于云原生的定义：

②容器云技术的发展

虚拟化技术的发展历史

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

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

2013 年 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 应用自动恢复的三种策略：

• Always：当容器终止退出后，总是重启容器，默认策略。
• OnFailure：当容器异常退出(退出状态码非 0)时，才重启容器。