增效降本开源节流,2022年技术趋势前瞻(异步编程/容器技术)

增效降本开源节流,2022年技术趋势前瞻(异步编程/容器技术)

    2022初始,凛冬已至,疫情横跳, 环境繁复,君不见互联网大厂纷纷裁员,银根紧缩。这一切归结为两个字:成本。对于互联网企业来讲,除了最基本的工商财税,办公室、办公设备、人力、产品和公关等等,这一切都是成本。而在疫情因素侵入导致经济下滑的情况下,降本增效就已经成为2022开年很多企业管理者非常重视的 KPI指标,而降本也一定会成为2022年技术发展的一个必然趋势。

    降本增效,到底降什么本,增什么效,有何妙计?

    异步编程

    一直以来,异步编程都是最有经验的开发者的专长,他们孜孜不倦地研究着非线性执行流中的回调方法,念兹在兹的,不过就是有限资源下每秒处理请求数的提升。异步编程方式也许是开发者对自己的严格要求,但带来的收益无疑也是非常可观的,以Python的web开发领域为例:

    2021年web框架性能排行榜中,排名前十的无一例外全部是异步框架,所以,异步编程方式可以给我们带来什么?是更高的每秒处理请求数,而更高的每秒处理请求数又能带给我们什么?是更低的服务器成本。

    那么异步编程到底怎么帮我们节约资源呢?本质上,异步提升的是服务器的吞吐量,而并非系统的性能,因为,CPU密集型的异步任务和同步效率差不多,也就意味着异步这是资源利用率提升,而非系统性能真的提升了。如果使用同样的CPU资源,处理同样的资源也会花费同样的时间。假设同步意味着大量的阻塞,此时CPU的资源利用率较低,吞吐量也会同比降低。如果使用异步,那么CPU很容易就能拉满,此时吞吐量就会升高。

    打个比方,京津高速双向八车道,日均车流量近5万车次,这里有个大前提,所有车道都得有车通行才可以,可是如果车辆根本就不变道,单向通行只用其中的两个车道,那多出来的两个车道意义何在?无疑是成本的浪费,大多数情况下,高并发场景下的同步编程方式就是在浪费系统资源。

    再者,如果一套服务不能有效利用一台服务器的资源,那必然需要更多的服务器通过运行更多的应用实例来弥补需求缺口。

    例如一个百万日活服务应用,假设同步框架单台机器可以抗住400-500并发,大抵需要七台服务器才能堪堪挡住,如果使用 Python 异步框架,重构后由原来的 七台服务器削减至三台,成本骤降 57%。而一台8核16G,10M共享带宽的百度智能云BCC计算型服务器,预付费一年的价格大概为1.2万人民币。

    假设我们不考虑服务器硬件成本,那也会由此引发出效率成本的消耗。当服务器数量堆叠到一定规模后,如果不改进底层逻辑和实现,无脑加机器其实是徒劳,并且运维成本会骤然增加,大批量服务器的监控、持续集成、持续部署都将会是不小的开销。

    综上,想要降低成本,异步编程就会是那一把关键的锁钥,当然了,相应地,对于开发人员的综合业务能力的要求也会有一定的提高,也许有的人认为异步编程会降低开发效率,异步写法也会降低代码可读性,殊不知,学贵大成,不贵小用。如果觉得异步编程晦涩难懂,可读性差,也许应该自我归因,努力提升自己以适应新时代的编程方式才是王道。

    容器技术

    容器,解决了应用打包标准化以及发布标准化的问题。早年间虚拟机方式的标准化程度是远远不够的,Docker容器终结了这一问题。随着 Docker 的不断演进和推广,在应用编排、资源调度等层面又出现了新的问题,早期的 Docker Swarm、Mesos 和 Kubernetes 互相竞争,最后 Kubernetes 胜出,并带来了新的资源编排方面的事实标准。在2022年的今天, Kubernetes 已经成为一个事实标准。

    标准化以后,Kubernetes上的业务类型越来越丰富,从最初的无状态到后来的有状态,如今像人工智能这样比较复杂的计算引擎也都放在 Kubernetes 上了,这就是一个相互促进的过程,这上面的负载类型越来越多,整个 K8S 体系也确实变得越来越复杂,但它能够管理的东西也越来越多。如果所有用户都抛弃传统部署方式,完全使用容器,那容器的复杂度必然会提升。

    但对于互联网企业来讲,要做的就是在容器能做更多事情后去降低它的复杂度和成本,否则容器的门槛就会非常高。现在,无论是阿里云、百度云还是腾讯云都在考虑从智能运维角度做更多的努力。比如在集群管理方面,如何用智能运维的方式发现当前运行中的一些状况,并且能够给出处理办法。现在也有智能应用画像和资源画像方式提高资源利用率。

    综上,智能化运维也会是2022的一个基本技术趋势,而围绕容器的生态可以认为是未来最重要的技术走向之一,它必然会引起一系列的变化,包括企业内部组织的变化。我们会看到,不仅整个运维管理体系在变化,企业内部也会出现新的组织形态,比如 Google 提出的 SRE 团队就是为可用性负责。现在很多深度使用云原生的企业,包括阿里,都有专门的 SRE 团队,这个团队会负责整个可用性相关能力的建设。其次,企业也会出现一些平台横向性的部门,基于云原生体系去支撑上方业务的部门。以前有些企业可能是偏竖井式的业务单元,即一个业务单元下面有支撑团队,容器包括 K8S 会让企业内部有更多平台横向型部门的出现。这也是解决复杂度的一个方法,因为不是每个纵向的业务部门都有足够的资源投入和专业度去解决这个问题。企业足够大的时候一定要考虑在 SRE 层和平台建设层形成横向部门,进行职能分离。

    回到降低成本的主题,互联网企业可以改进的方案其实有不少。从偏底层看,很多云厂商和头部互联网公司在自研芯片,华为的例子告诉我们,进口芯片不仅会导致成本溢出问题,玩不好可能连生命线都被人掐断,所以 软件硬件结合一体才能带来根本上的降本增效。另外就是容器化操作系统,这个领域可以理解为容器技术的一个分支领域,它是基础设施层面一个比较重要的优化方法,降低了操作系统安装、适配以及稳定化的成本。

    此外,弹性应用技术是很多云厂商广泛使用的降本增效的方法。很多互联网公司在尝试弹性离在线混部技术,本质上还是提高服务器利用率。之前各个公司在自购服务器或者云上购买云服务器的利用率往往都低于 10%。这个利用率并不高,很多公司尝试去推高这个水平线,但推高水平线必然会带来很多技术挑战,比如利用率高了之后,多种负载混合跑时,是否会互相影响。几大厂商都在通过开源或商业化产品形式尝试输出离在线混部(多种负载混合部署)技术,相信在2022年,离在线混部技术将迎来进一步的产品化高峰。

    结语:降低成本这件事情其实是所有资本家永远的诉求,只不过当公司在起步或者高速发展的阶段这个诉求并没有那么强烈,会以业务先行。但是随着业务进入平稳期或者遇到大环境的限制时,降本需求会更明显,所以2022年,通过异步编程方式以及容器的技术的改进,提升服务器利用率从而降低成本会是大趋势。是的,不计成本一门心思搞科研的时代也许已经过去了,就像某部香港电影里说的那样:

没错,我是小角色来的,你可以拒绝我,但是,你可以拒绝这个时代吗?