为什么要云原生？

比眉伴天荒 2023-02-11 03:13 164阅读 0赞

### 为什么要云原生？ ###

### 文章目录 ###

*   *   *  为什么要云原生？
         *   *  1.写在前面
             *  2.服务的发展之路
             *   *  2.1 单体架构阶段
                 *  2.2 RPC架构阶段
                 *  2.3 微服务架构阶段
             *  3. 当下矛盾点
             *  4. 解决之道
             *  5. 问题就解决了？
             *  6. 总结

#### 1.写在前面 ####

目前业界对于云原生的声音越来越大，很多业界大牛给云原生布道，但是对于普通程序员来说，总有一些问题在困扰着，云原生到底是什么？云原生有什么好？怎么才能做到云原生？

本文希望探讨云原生的诞生场景。以及解决的问题。

#### 2.服务的发展之路 ####

简单总结下过去十多年服务的演化之路，总体可以分为如下3个阶段

【单体架构阶段】->【RPC架构阶段】->【微服务架构阶段】

##### 2.1 单体架构阶段 #####

在互联网之前，传统软件公司时候

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center]

##### 2.2 RPC架构阶段 #####

随之互联网的发展，流量激增，单体应用面临着许许多多的问题，例如：

1.  单体应用增加机器以及无法带来性能上的提升
2.  代码量巨大，启动服务都要几分钟
3.  不方便系统维护，经常合并代码冲突。

为了解决上述问题，将单体服务中的一些功能模块抽离出来，作为独立的服务，逐渐形成稳定的服务中心。服务与服务之间存在远程调用，多个服务一起完善业务功能

例如 用户服务，交易服务，库存服务等等，分别由不同团队维护，并且可以独自的增加机器，方便支持更大的业务量

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 1]

##### 2.3 微服务架构阶段 #####

当服务越来越多，服务越来越小，服务与服务之间的调用关系。成为单靠人肉无法理清的关系图

单个服务的如果出现问题，可能引起服务雪崩，拖垮调用方服务

新上线的服务如何被调用方即使发现？

服务的状态监控？

等等一系列的问题，等待解决

所以这块提出服务治理的概念，去解决上述提出的一系列问题。

如果没有一系列的服务治理基础设施，所谓的微服务架构阶段与RPC架构阶段没有很大区别

#### 3. 当下矛盾点 ####

**（从一个矛盾点切入来探寻问题本质）**

目前，互联网微服务架构大行其道，那么我们需要认识到当前服务的主要矛盾的点所在

过去3-5年时期，互联网处于流量红利期，那个阶段业务野蛮生长，每日的业务量都是一个新的高峰，在那个时期，往往都是不在意成本抢占市场，机器资源利用率普遍不高。

随之互联网流量红利期结束，业务野蛮生长的时期也随之结束。公司开始关心成本，关心服务器的资源利用率

但是，提高资源利用率缺不是简单的缩容，或者代码优化可以搞定的

**举个例子**

假设你的代码处于一种完美状态，最大程度的压榨的机器性能，但是业务是有高峰低谷时期之分的，例如猫眼电影

重要档期是业务的最高峰，但是周一到周五业务量其实没有很大；或者一天中，凌晨1点到凌晨5点基本没有人购

票，晚上8点是购票高峰。

那么这个时候如何提高资源利用率呢？难道我每天晚上1点缩容，早上6点起来扩容？这不得累死人

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 2]

#### 4. 解决之道 ####

针对当前面临的矛盾点，有人提出一种解决方案【弹性扩容】【按需计费】

啥叫【弹性扩容】【按需计费】

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 3]

大白话解释就是说通过流量，或者机器负载等一些指标判断是否需要扩容或者缩容，然后服务器的使用成本是按使用时间计费

**举个例子**

猫眼电影，一个服务机器假设有100台机器。在晚上8点前，发现流量在逐步增加，集群机器的负载也在逐步增加，资源利用率已经超过60%【弹性扩容】根据这个指标判断未来是业务上涨阶段，就提前扩容了10台机器，如果过一段时间发现还是集群机器负载逐步增高，那说明扩容不够，还要再扩容10台。等到了凌晨1点，大家都睡觉了，没有看电影了。发现集群机器负载降低了好多，流量也降低了好多，资源利用率不到3%【弹性扩容】判断未来是业务下降阶段，那么就缩容80台机器。

这么做有什么好处？

原来没有【弹性扩容】一天我服务器费用是100 \* 24 \* 60 \* 60 \* M M=每秒钟的服务使用费。

现在有【弹性扩容】因为我业务不同时间段的机器数量不同，业务低峰期的服务器费用基本可以节省80%，那么服务器的费用将大大降低 。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 4]

#### 5. 问题就解决了？ ####

看到这里是不是觉得发现的银弹，觉得找到了未来之路？

但是通过【弹性扩容】【按需计费】就把当前问题的矛盾点解决了？

可以说是，也可以说不是！

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 5]

说解决了，是因为确实指明解决当前资源利用率不高的问题

说没有解决，说因为它引出了一个新的问题。

什么问题？**如何快速拉起一个高性能服务进程**

什么是**高性能服务进程**？

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 6]  
**举个例子**

目前一个业务高峰来临，弹性扩容正在扩容机器，部署服务。但是扩容机器需要申请机器，初始化机器环境等一系列操作，初始化服务器之后，又得重新打包服务代码，编译，然后运行。全部执行下来，可能业务高峰期已经到来，流量早已把你的服务击垮。

好吧，就算上面这些你都是十分迅速的完成了，假设你服务是一个Java程序，你发布的服务还未经过JIT即使编译器的优化，虚拟机解释执行的效率十分感人，你的服务性能TP99线急剧升高，接口的超时严重，引起服务雪崩拖垮调用方服务。

**那如何解决这个问题？**

**如何快速拉起一个高性能服务进程**？

这个问题分为两个部分解决：服务器快速生成，高性能应用快速启动

**服务器快速生成**的目前解决方案是容器化部署，传统应用都部署在虚拟机或者物理机器上，相较于前两者，容器化启动速度往往远超前两者

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 7]

**高性能应用快速启动**

高性能应用快速启动也有两个部分解决

1.  编译后做成镜像包，二次部署无需从服务代码开始执行编译，打包等耗时过程
2.  使用更加轻量级的框架，减少程序包中的代码数量，并且使用AOT技术，将Java实现编译成二进制码，跳过部署完成后，解释执行的阶段

第一点还好理解，传统发布服务，需要在仓库中拉Master分支代码，然后编译，打包，运行才能启动起来，如果实现就将打包好程序包做成镜像，自然可以跳过上述那些十分耗时的时间。

第二点怎么理解 **轻量级框架**和**AOT技术**呢？

传统的基于 Java 和 J2EE 的编程模型和框架开发的程序，存在高内存需求和启动速度（Class文件需要类加载）缓慢等限制

为了解决上述两个问题，所以需要一种轻量级的框架去解决。

目前业界**Quarkus**开始崭露头角，本质上就是一款轻量级框架，并且可以AOT结合直接编译成二进制码。可以迅速拉起一个服务，经过测试启动一个HelloWorld只需要**12ms**

#### 6. 总结 ####

上述带大家了解了下当前服务面临的主要矛盾点，以及业界探索的解决方案。

当然云原生要解决的问题绝不是单纯上面描述的资源利用率的问题，还有**支持业务务快速迭代、业务组合复杂、海量用户、流量突增、7\*24小时高可用，故障转移，自动恢复**等等

上面只是从一个点切入给大家讲解问题的云原生的诞生背景

至于云原生的【微服务】【DevOps】【持续交付】【容器化】只是基础门槛，使用这些并不代表云原生了，基本上大厂这些基础设施都是标配，

所以我们应该清晰认识到云原生的**核心**是【按需分配】和【弹性伸缩】

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200521133246587.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20200521133317715.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20200521133330721.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 3]: https://img-blog.csdnimg.cn/20200521133342117.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 4]: https://img-blog.csdnimg.cn/20200521133353778.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 5]: https://img-blog.csdnimg.cn/20200521133410938.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 6]: https://img-blog.csdnimg.cn/20200521133429416.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3_size_16_color_FFFFFF_t_70_pic_center 7]: https://img-blog.csdnimg.cn/2020052113344688.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzMzMwNjg3,size_16,color_FFFFFF,t_70#pic_center