为什么要云原生?

发布于: 2020 年 05 月 21 日
为什么要云原生?

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】【持续交付】【容器化】只是基础门槛,使用这些并不代表云原生了,基本上大厂这些基础设施都是标配。

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

发布于: 2020 年 05 月 21 日 阅读数: 1046
用户头像

Aaron_涛

关注

还未添加个人签名 2018.07.17 加入

互联网搬砖工,热衷分享,喜欢新事物 目前从事营销域技术研发

评论 (1 条评论)

发布
用户头像
云原生的核心是【按需分配】和【弹性伸缩】,这个观点很有趣~
2020 年 05 月 22 日 09:46
回复
个人见解哈
2020 年 05 月 22 日 10:34
回复
没有更多了
为什么要云原生?