为什么要云原生？

1.写在前面

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



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



2.服务的发展之路

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

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

2.1 单体架构阶段

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

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



2.2 RPC架构阶段

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

1. 单体应用增加机器以及无法带来性能上的提升

2. 代码量巨大，启动服务都要几分钟

3. 不方便系统维护，经常合并代码冲突。

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

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

2.3 微服务架构阶段

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

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

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

服务的状态监控？

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

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

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



3. 当下矛盾点

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

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

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

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

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



举个例子

假设你的代码处于一种完美状态，最大程度的压榨的机器性能，但是业务是有高峰低谷时期之分的，例如猫眼电影，重要档期是业务的最高峰，但是周一到周五业务量其实没有很大；或者一天中，凌晨1点到凌晨5点基本没有人购票，晚上8点才是购票高峰。

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

4. 解决之道

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

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



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



举个例子

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



这么做有什么好处？

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

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



5. 问题就解决了？

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

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

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

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

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

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

什么是高性能服务进程？



举个例子

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



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



那如何解决这个问题？

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

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

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



高性能应用快速启动

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

1. 编译后做成镜像包，二次部署无需从服务代码开始执行编译，打包等耗时过程

2. 使用更加轻量级的框架，减少程序包中的代码数量，并且使用AOT技术，将Java实现编译成二进制码，跳过部署完成后，解释执行的阶段

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

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

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

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

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



6. 总结

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

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

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

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

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