月度归档:2022年10月

cbyh

一年节省 40%的技术成本:基于云服务的技术成本精细化运营策略

降本增率是今年的主旋律,对于技术团队来说,最大的成本除了人力成本,就是我们的技术成本。这里的技术成本包括各种 CDN、网络带宽、服务器、存储、云计算服务等。

如果你是一个运维总监,或者是技术负责人,需要在技术成本上节流提效,这篇文章应该对你有一些帮助。

今天所讲的策略是当我们面对一个已有的技术基建和系统,如何有计划地针对技术成本做优化,如何持续运营,让成本降下来,让钱花得有理有据。

整体分为两个阶段,成本优化和精细化运营

1 成本优化

成本优化是一个「止血」的过程,如果之前没有刻意关注过技术成本,可能存在较多的浪费或者不合理,特别是当业务在高速野蛮发展的时期,一不留神就会出现你想象不到的成本浪费。

我们做成本优化一般有如下几步:

1.1 组建团队

一件事情要想做得比较好,得先有一个团队。对于技术成本优化这种可能会跨团队,跨业务的事情,更需要有一个合适的团队。

在项目成立时,我们可以成立专项小组,小组由以下成员角色组成:

  • Owner(组长/负责人) :负责整个项目的规划、计划安排、人员协调以及对外沟通汇报等,为整个项目负责;
  • 运维的负责人(运维总监/ SRE 负责人):负责整体技术成本的评估、公共技术成本的评估、优化,以及云服务商上相关操作的评估,规划和人员安排, Owner 和运维的负责人可以是同一个人;
  • 业务侧的技术负责人(各业务的技术总监/技术经理):负责各业务侧技术成本的评估、优化落地;
  • 财务的负责人(财务总监/财务经理):负责组织安排技术成本资金的确认、核对以及预决算等。

以上为主要小组成员,一般各负责人还会拉上具体操作的核心同学一起参加,这些同学由以上的负责人自行安排调协。

1.2 现状分析

技术成本之所以浪费,大概率是不知道钱花在哪里了,账有点糊涂,或者说没有人去关注里面的细节,是一个大大的黑盒子。可能大家都依着惯性往前跑,有业务要申请资源,直接上操作台或系统买了分配完事,没有考虑这些投入的价值在哪里。

现状分析主要的作用是把这个黑盒子打开,把里面的东西一个个拿出来,把数点清楚,把每个云产品、去服务使用的情况摸清楚。

在做现状分析时,我们建议先定量分析,再定性分析。

这里的定量分析并非严谨的科学实验中的定量分析,而是以云产品为项,分析其成本金额、实例数等的情况,再在此基础上确认优化的策略。

咱们的定量分析有两个维度,一个是基于时间维度,看每个月的成本,年度成本,对成本有一个大的概览;另一个是基于当月各个云产品的使用情况,看有哪些优化的空间。

如果没有比较好的报表支撑,并且存在多账号,多云服务商等情况,建议直接拉一个 Excel 表格,表结构大概如下:

月份 云厂商 1 成本 …… 合计
2021-01 阿里云 …… 合计

在以上数据表的基础上,以总的趋势图和饼图等较直观的方式展示出来,趋势图能看到涨跌的情况,饼图能看到组成部分,可以以云产品为维度,也可以自行分类查看,此处建议使用飞书的多维表格,生成仪表盘,当然,如果你 Excel 操作很强,那随意。

通过以上的表格,能大致了解整体成本的情况,对于后续成本的优化评估,年底预算等都会有一个较为直观的印象,以后续决策打下基础。

了解了整体成本的情况,接下来就是要打开盒子,在不明确业务归属的情况下,我们先从云产品的维度来梳理整个成本的情况,对此,我们的定量分析有一个简单的模型表格,如下:

云厂商 云产品 当月成本 优化策略 优化预计收益 操作难度 业务风险 优先级
阿里云 OSS 108万 XXX bucket 转低频 10 万

基于以上的模型表格,我们可以快速地确认能「止血」的部分,我们对其做一些定性的分析,如分类。 一般技术成本优化大概有如下的一些情况:

1.2.1 折扣和计费方式

折扣是一个很明显的优化点,当你在某个云厂商消费到一定的金额,应该是有对应的折扣,具体的折扣情况需要和你对接的商务来聊,不同的区域,不同的人,聊的结果不同,但是一定是有空间的;而且不同的产品可以折扣不同,如果你某个产品的消费金额特别高,可以单独申请很低的折扣,很低很低。

不同的计费方式在不同的量级,成本不同,需要根据业务评估,或者是一些续费的方式,不同的续费方式成本也是不同的,如按年或按月的价格差异也蛮大的;

1.2.2 存储

现在的存储大家基本都会用云存储,而不是自己来搭一套。每个业务都往存储里面存东西,基本上没有人太去管。而实际上这里的浪费往往较多,常见的情况有:

  • 历史存储,没有人维护,如一些临时性的文件、过期的文件、用户不要的内容等等;
  • 无用存储,原来是给业务使用,但是业务新申请一个 Bucket,旧的没有删;
  • 冷热存储,用户的一些文件,但是很久没有访问了,属于冷数据了,但是这些冷数据还在存在标准存储中,而在云厂商的逻辑中,除了标准存储,还有低频存储,归档存储,冷归档存储等,建议根据实际的使用场景规划使用哪种存储,以及使用哪种存储过期策略;
  • 日志存储,特别是链路跟踪的日志存储,链路跟踪数据的价值是随着时间的推移急速降低的。从我们实际的生产情况看,但凡你发生一个线上的调用异常,如果是真正的问题,我们在半小时以内发现解决,甚至几分钟之内就处理掉。几天后,它就变成了一个无关紧要的异常,也就没有什么价值了。但是如果我们对这些链路跟踪的数据不做处理,其存储量随着时间推移会越来越大,成本也就越来越高。所以我们可以把过去一小时或两小时以外的数据进行采样、清洗最终只保留有价值的数据,实行差异化的链路跟踪数据存储,从而降低存储成本;
  • 存储带宽,像阿里云的 OSS 提供外网直接访问服务,如果开放了外网直接访问,建议评估一下,是否走 CDN + 回源更合理,或者有没有本来可以走内网的,却去了外网访问;
  • 存储计算,有些存储带有一些图片处理等的计算能力,这些能力也是单独收费的,如果此处费用较高,建议评估以空间成本换计算成本,或者从业务上考虑减少计算量。

1.2.3 机器

主要指我们常见的云服务器,数据库等,其常见的优化点:

  • 没人用的机器,这个特别常见,比如某个业务想跑一个定时任务,一段时间后不跑了,也没有知会运维同学,机器就会一直在那里花钱,但是啥价值也没有;
  • 线上负载低的机器,一些线上的服务配置超高,如最开始评估容量是 100,但是实际只用到了 10 或者 10 都不到,但是并没有把机器降配,毕竟对于使用方来说,在不考虑成本的情况下,配置高更好一些,特别对于一些 GPU 的机器,特别贵,如果只是偶尔用用,考虑是否直接在内网本地部署;又或者一些小业务在独熟某个实例,此时可以合并这些小业务到一个实例,释放其它的实例;
  • 非线上环境闲置的机器,一些开发测试环境配置了非常好的机器,或者多个业务各有一套,但是实际使用频次很低的情况;
  • 数据库存储浪费,有些存储的数据因为版本升级或迁移等原因,一直留着,没有删除,也没有地方用上,或者是一些没有用的数据也一直存在数据库中,此时可以沟通后删除,释放空间,降低配置;

1.2.4 流量带宽

主要指 SLB、一些网络网关等的流量,常见的优化点:

  • 内外网错乱,比如一些请求可以走内网,却走了外网
  • 计费方式,流量有按带宽和按流量,根据历史数据测算,哪种更划算一些,可能前期用流量划算,到后期量大了后用带宽更划算一些,这里就需要具体问题具体分析。

1.2.5 CDN

  • CDN 带宽,带宽优化最常见的就是压缩了,看 CDN 的压缩机制开了没,特别是对一些图片的压缩,有些甚至可以省一半的带宽;
  • CDN 的其它计算成本,如 HTTPS 的费用,不同的云厂商不一样,有些没有这个成本,可以考虑多谈谈折扣。

1.2.6 云服务

像一些安全服务,如 WAF、DDoS,或者云计算之类的服务基本都是云厂商提供的,我们常见的情况:

  • 服务共用,像 DDoS 是按实例收费,如果是多业务,可以考虑共用一个实例以减少成本;
  • 服务空转,比如像一些治理类的服务,可能当时确实需要,或者试了一把,最后没有用起来,导致云服务还在继续跑,而没有人在用;又或者某些云的数据库各种附加功能,有些是默认开启的,其实可能用不上,一直开着一直浪费成本,如此种种;
  • 服务版本,有些服务,不同的版本其价格不同,比如阿里云的 DMS,新版的价格和旧版的价格就不一样;
  • 服务超配,服务有其不同的档位,可能是一些历史原因,或者一些奇怪的需求,导致申请了比较高配置的服务,后面没有调下来,一直在消耗成本,没有物尽其用,和业务方沟通后把配置降下来;
  • 多服务商对比,如内容安全审核,短信服务等等超公共的业务,可以选择多家云厂商,一个是灾备,另一个是成本控制,像内容安全审核,网易易盾的价格就和阿里云 CDI 价格差距挺大的。

1.3 项目计划和里程碑

基于上面的现状分析,我们大概清楚了我们能做什么,以及做了这些后可以得到的收益。根据收益的大小、操作的难易度、风险的大小来评估优先级,对于收益大的,操作简单,风险小的先快速落地;对于收益小,复杂且风险高的往后放放。

根据优先级,我们下一步是制定详细的计划表和里程碑。

大的里程碑可以分为三个:

  1. 止血,第一批快速落地里程碑,尽量控制在当月底,快速把通过运维部门操作能优化的点做了,解决明显的浪费和不合理使用的情况,快速见效;
  2. 业务优化,一些需要业务侧优化的高收益的优化,一些需要和云厂商重新签合同等依赖于第三方的操作,属于有些难度的止血疗伤操作,此时需要业务侧一起参与进来评估,优化,见效时间为一到三个月;
  3. 精细化运营,建立技术成本控制体系,对技术成本进行精细化运营,解决业务演化过程中成本出现的变化,应对突发事件产生的成本增加;

在里程碑的基础上,列出每一个里程碑中的详细计划跟进表,大概如下:

业务 优化专项/措施 解决的问题描述 预计节省成本 当前状态 计划完成时间 负责人 相关文档
基建 SLB 计费方式梳理及调整 解决当前 SLB 计费方式不合理的问题 5000 计划中 2022-11-10 张三 文档XXX

1.4 沟通和汇报

在我们执行成本优化过程中,需要和业务方打交道、需要和财务交互打款,核对消费金额,需要和老板们汇报项目进展,基于此,我们需要构建针对本项目的沟通和汇报渠道。

我们可以通过报告/文档,以及月度会议的方式沟通和汇报。

文档包括以下几种:

  • 月度分析报告,主要是在月度账单出来后,按月分析上个月的成本花费情况,回顾上月计划执行情况,成本优化目标达成情况,如果没有达成,分析原因并做出对应的解释和应对计划,同时对比上上个月的的成本情况,按云产品比对,发现增长了的云产品,以及减少未达标的项,比如 11 月 5 号出 10 月的分析报告,对比 9 月的情况。
  • 业务技术成本分析报告,与上一个报告的不同点在于增加了业务维度的,不同的业务其在云产品的消耗不同,能看出业务侧云产品的涨跌,为后续精细化运营的业务分摊做准备分析;
  • 财务分析报表,基于财务的角度对技术成本分析,这个报告是由财务同学输出,以一个非技术同学的角度看技术成本事项,可能会列更关注成本花在哪里,以及各种维度的涨跌。

在准备了这些文档后,我们按月召开技术成本优化月度会议,与会人员为上面我们所列的小组成员。会议主题主要是同步月度成本情况,以及协调资源做业务成本的优化。这里可能逐渐要形成各业务自己为自己的成本负责的逻辑和意识。

每个月所以以上的报告,会议完成后,和小组各成员确认了结果,可以整理文档和说明,邮件或 IM 将相关结果发送给与本项目相关的老板们,如 CTO、CFO 等。

技术成本的优化基本在 3 个月到半年内完结,再接下来就是针对技术成本的精细化运营,在已优化好的成本水位的基础上,保持水位的不增/随业务体量正常增加,或者减少。

1.5 其它原则和注意事项

  1. 以不影响公司业务为前提;
  2. 在激进的方案中,可以少量影响一些工作的效率;
  3. 先止血,再优化,即把能快速节省成本的操作先做了,如空闲或负载低的服务器,用得少的云服务,不合理的折扣等,对于报表建设,需要改动线上代码的优化往后排一些;
  4. 部分优化的生效具有滞后性,即某些优化当月操作后,需要下个月才能生效,因为有很多云服务的计费项是按月收取的,如 CDN 带宽;
  5. 分清主次,看业务的主要成本在哪里,优先处理可节省成本高的部分,比如存储的费用多,可能一点小优化就抵其它的全部成本;
  6. 掰开了,揉碎了去优化,把每项的成本都列出来,评估每项成本的合理性和必要性;
  7. 把业务方和财务拉到一起来搞,部分压力传导给业务方,一些成本项的责任人放到业务方,让财务加入,是想通过财务的沟道,把成本优化透明化出来,让公司更快的知道,同时从财务的角度看成本优化的问题;
  8. 多厂商对比,优先选择大厂商,他们的客户多,遇到的问题多,一下你所难解决的问题,可能他们在其他客户那里就已经解决过了,你只需要接入使用就可以了。比如短信服务,被攻击的情况很多,不停的对抗,在大的云厂商已经在海量客户和用户的基础上形成了很强的安全策略;
  9. 从一个云厂商 A 迁移到另一个云厂商 B,建议找云厂商 B 分摊一些迁移成本,比如你有 5 个 PB 的数据迁移,这个过程中会产生机器成本,流量成本以及过渡阶段的存储成本等,就这体量算是一个大单了,可以要求 B 搞定迁移成本。从云厂商的角度看,这个成本算是拉新的成本,如果能在未来挣回来,大概率是会愿意掏这个钱的。但是,这个操作尽量在迁移之前搞定,否则当你迁移完后再提这茬,就会有点被动,但是也不至于完全不行,只是难度会大一些,如商务同学和他们内部的产品同学去聊的时候,逻辑是不一样的,有点像男女朋友最开始选择是否在一起的时候样子,求而不得才是议价选择权最高之时

2.精细化运营

精细化运营和前面讲的成本优化不一样,成本优化考虑的是短期效益,为的是解决历史的问题,而精细化运营是一个长期的逻辑,解决的是未来的持续发展的问题。

精细化运营分为三个层面,组织分工,流程机制,系统支撑。

2.1 组织分工

2.1.1 按业务分摊成本

前面短期的成本优化大多数以运维部门为主,少部分需要修改业务方配合,为了快速见效,这里需要有一个强有力的集权性质的组织,让整个项目快速成功。

当成本优化到一定阶段,没有那种短平快的措施后,我们需要结合业务来做深度的优化,整个分工逻辑会有所变化。

原来是运维部门为成本负责,主导成本优化,业务侧以配合为主,当需要修改业务时由业务侧配合修改上线,运维部门来验收确认。

在新的逻辑里面,成本由各业务侧来承接,业务侧的技术负责人为自己业务的成本负责,技术成本优化小组为整个公司的技术成本负责,技术成本优化小组和各业务、财务、运维等部门对于成本分摊逻辑达成一致,认可自己的成本有多少。在此基础上,根据业务的情况,技术成本优化小组可以提出优化建议,各业务侧自行评估或者推动成本优化达成目标。

2.1.2 基于业务的成本优化策略

之所以要把成本分摊给业务侧,是一个「屁股决定脑袋」的问题,是一个责权利对等的问题。

当我们的成本优化进入持续运营阶段,一些优化需要深入到业务才能达成,以及在业务扩张或者有新业务时,只有业务方才能评估成本是否合理,是否是有价值的。

举两个例子:

一个是微信收藏功能的例子,在微信里面我们发的消息,如视频这些是没有永久存储在服务器,而只是临时存储了三天,当你把消息收藏后,这条消息就会永久收藏。这个功能用得人不多,但是却耗费了很多存储空间,并且用户在收藏后很少去看收藏的内容。但是这块的成本又非常高,在 2016 年那个 2TB 是主流存储的年份里面已经有 7PB+ 的数据,相当于至少要用 1000 多台服务器来存放这些内容。这里有明显的业务优化空间,于是腾讯的成本优化团队和微信团队一起对其产品逻辑和播放逻辑做出了优化,减少几百台服务器的量。到现在,收藏功能对于每个用户都有一个存储上限,当到达上限后就无法收藏内容,这也是通过产品策略来减少技术成本的一个方面。

另一个是某网盘的例子,某网盘是一个临时性网盘,用户可以临时传一个文件分享给朋友,朋友拿到分享链接后直接下载,上传的内容七天有效;除此之外,用户还可以上传文件,永久保存,随着用户的增多,成本急剧上升。深入业务后发现,网盘系统做了全局唯一的存储,以实现秒传功能,所有上传的文件都会存下来,不管是不是临时的,成本优化团队和业务侧讨论后做了两个优化,临时文件过期删除,永久存储的文件一个月后从标准存储转为低频存储,六个月后转为归档存储并提供解冻功能,此举节省了将近一半的存储成本。

2.2 流程机制

成本要长效的得到控制,需要有对应流程的保证。在成本的流程中,核心是要控制成本的显性增加,以及在过程中监控并检查成本的变化趋势,以快速应对成本的变化。

2.2.1 资源申请流程

资源申请流程主要是通过资源申请的集中管控来控制成本的无序扩张。 各公司对于流程的落地实现不同,有些的有流程系统,有些的直接在钉钉等应用中直接使用其 OA 流程,也有用类似于 Jira 等系统走任务处理流程的,所有的这些都只是咱们流程的落地实现方式。

资源申请流程的核心点有两个:

  1. 资源申请模板,以模板的方式承载资源申请的考量因素。模板中至少要包含资源申请原因、使用业务方、规格、容量估算、成本估算等;
  2. 流程中必须包含技术成本小组的审批,以评估成本是否超出预算,以及评估成本的合理性,如果成本的业务方过多,考虑多级架构。

对于紧急情况或者没有人能及时审批的场景,可以走紧急流程,先处理,后续再走确认成本变化。

2.2.2 成本预核算机制

在一年结束的时候,我们会对来年的成本做预算。在成本预算的时候我们需要先进行预测,即通过历史数据、业务目标预测来年的成本,从而做成预算。

无论是从成本控制的角度,还是从技术运营的角度,我们所使用的设备、带宽、流量、存储,必须要预核算管控。

如果公司已经有现成的预核算系统或流程,直接走现成的即可,如果没有系统化的做预核的逻辑,可以以相对「土」的方式实现预核算管控。这里所说的「土」的方式,可以是一个EXCEL 或一个文档,说明指标体系和预测模型。

预测的技术成本等于预测的固定成本和变动成本。固定成本是指不会随着业务的增长,用户的增长而有一定趋势增长的成本,如一些管理系统、安全基础设施等。变动成本是指会随着业务增长而增长的成本,如机器、带宽、流量,存储等等。我们这里要做的预测工作主要是围绕变动成本来做。 变动成本的预测需要先有预测指标。预测指标是指在技术成本中和在我们做预测的时候,需要先有预测指标,即技术成本是如何随着业务的变化而变化的,如 CDN 带宽可能和日活强相关,存储和存量用户数相关等等。常见的指标如下:

  • 每用户存储成本 = 存储成本 / 总用户数
  • 每活跃用户 CDN 带宽成本 = CDN 月成本 / DAU(如果有明显活跃周期,可以用活跃周期的 DAU,如活跃日 DAU,因为 CDN 一般是按 95 峰值计费)
  • 每活跃用户接入带宽成本 = 接入带宽月成本 / DAU(如果有明显活跃周期,可以用活跃周期的 DAU,如活跃日 DAU)
  • 每活跃用户机器成本 = 当月机器成本 / DAU ,机器成本包括ECS、K8S、各种数据存储、数据传输、消息队列等等,DAU 逻辑同上,月使用的上限决定机器的成本
  • 每活跃用户流量成本 = (月 CDN 流量成本 + 回源成本 + 负载均衡流量成本 + 网络流量成本)/ MAU(流量成本一般是按流量计费,用多少算多少,所以用 MAU 来算更准确一些)

除此之外,还可以有数据存储,日志存储,网络带宽、媒体计算、大数据成本等等,根据实际的业务情况拆分。不过也不用太细,按大的分类就行。

在确定了预测指标后,根据业务目标估算指标中的 DAU、MAU、用户数等等分母的值,求和或加权求和得出预测值。

得出预测值后,根据公司流程走完预算逻辑。

在持续运营的过程中,每个月持续的迭代预算,当遇到不可抗力时,可以考虑申请预算滚动,即重新调整预算。

比如公司战略在年中有调整,需要新增业务线,又或者业务调整,某块业务不做了等等。

在每个月初,通过系统的方式,复盘核算上个月的总成本情况,各云产品的成本情况,各业务的成本成本情况,得出下个月的重点关注点和行动事项,持续迭代,保证年度成本预算不超。

2.3 系统支撑

在项目早期,不用着急着上系统,一些事情可以手动先搞,如一些报表,数据统计,信息同步等。

在持续运营的时候,系统就成了一个必选项,通过系统支撑前段时间我们的手动逻辑,可能包括如下一些内容:

  1. 各云,各产品,各业务的成本日报,月报,周报;
  2. 月度小结报表,增加了多少,减少了多少,每个产品的变化趋势,各业务的变化趋势,总成本;
  3. 自动形成报表,邮件或 IM 消息发送;
  4. 定时报表,产品报表,部门报表。

基于业务情况,成本情况,对当月,当年的成本预测等等

除了成本以外,我们在系统中还需要包含资源利用率,纯粹从技术出发,查看资源的使用情况,如机器的使用率,内存/CPU 的使用率,将资源利用率和成本关联上,以更好的控制成本。

我们通过系统,提供成本的透明度以支持成本优化。 提高透明度的目的是想知道发生了什么,将要发生什么。

系统支撑除了报表等透明化逻辑,还有监控提醒逻辑,通过对业务的监控和成本的监控,快速知道成本的变化和过程中的问题,以快速解决这些问题。

3 写在最后

技术成本优化是一个持续的工作,以精细化运营的方式,责任到人,把成本管控起来。

技术成本运营没有终点,成本优化和精细化运营只是其中的一个环节,需要持续迭代和优化,不断的升级。

从现在的阶段来看,我们还可以朝统一可视化,自动化,智能化等方向再迭代迭代。

你好,我是潘锦,超过 10 年的研发管理和技术架构经历,出过书,创过业,带过百人团队,也在腾讯,A 股上市公司呆过一些年头,现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM,对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣,平时喜欢读书、思考,终身学习实践者,欢迎一起交流学习。微信公众号:架构和远方,博客: www.phppan.com

kd

跨端架构的技术选型 2022

1. 跨端架构的意义

在《The Pragmatic Programmer》(中文翻译为《程序员修炼之道》)中,作者提了一个 DRY(Don’t Repeat Yourself)原则,主要指在程序设计以及计算中避免重复代码,因为这样会降低灵活性、简洁性。 把一切重复的代码抽象出来复用,当需要修改的时候只需要修改一次。 这里的复用有如下一些级别:函数级复用、对象级复用、模块级复用、类库级复用、框架级复用。 咱们今天聊的跨端是更高层面的复用,是端的复用。

现实中我们常见的工作方式是安卓的同学写安卓,iOS 的同学写 iOS,前端写 Web,小程序,H5 等等。 随着整体技术的进步,前端技术的发展,大前端的兴起,跨端实现越来多了,一些跨端的框架层出不穷。最终想要实现的跨端架构希望能做到:一次编写,多端运行

这里的端包括如下:

  • PC 端(苹果,Windows、Linux)
  • 移动端(安卓、iOS)
  • Web 应用、插件
  • 小程序(微信小程序,企业微信小程序、钉钉小程序、快手小程序)
  • H5

以上跨端的逻辑分为三个层面

  1. 硬件形态,或者说是设备,如 PC 电脑,移动设备、物联网设备
  2. 相同硬件形态下的不同平台,或者说是跨操作系统,如 PC 下的 Mac、Windows
  3. 相同平台下不同的应用或应用中的衍生应用,如 iOS 平台下浏览器应用(H5),微信小程序,支付宝小程序等

应用运行在某个操作系统之上,操作系统位于硬件设备与用户之间,是两者沟通的桥梁。不同的硬件有不同的架构和指令集,其对应也会有不同的操作系统。不同的操作系统其对应的执行程序结构不同,如 Windwos 下的 exe 结尾的程序不能在 Mac 下执行。这就是所谓的平台。

那么如何跨平台?

跨平台也是跨端的一部分,我们常见的跨平台应用,如浏览器,它所实现的跨平台是指运行在浏览器中的网页是跨平台的,而浏览器本身并不会跨平台,浏览器的生产厂商根据不同的平台,不同的操作系统分别实现了对应的版本,在应用层面抹平了平台和操作系统的差异,实现了跨端的目的。

浏览器在实现过程中会提供一个容器给到开发者,屏蔽平台差异,提供统一的 API 接口,让一份代码可以在不同的平台运行。 与浏览器类似的还有 Docker、JVM、Node 等。

在浏览器跨端的基础上,Electron 整合 Chromium 的渲染引擎、NodeJS 和用于调用系统本地功能的 API,使用 JavaScript,HTML 和 CSS 构建跨平台的桌面应用程序,其可构建出兼容 Mac、Windows 和 Linux 三个平台的应用程序。

在跨平台之外,我们还需要跨应用,如在不同的小程序、H5 之间,既然是应用,那就一定会包含界面,业务逻辑,如何只写一次业务逻辑,在不同的应用中执行,在代码重复层面追求更极致的体验,遵从 DRY 原则,让代码一次编写,多端运行。

我们在追求跨端的同时,也希望跨端的体验能趋近于原生的体验。

2. 跨端架构的本质

跨端架构的本质用稍微文艺一点的话来说就是:「世上本没有什么岁月静好,只不过是有人替你负重前行

一个跨端的架构至少包含渲染、逻辑和原生能力支撑、端的构建方式。一般会通过实现自己的容器来抹平(或者兼容)端的差异。

这个容器一般会提供两个能力:一个是渲染,另一个逻辑和原生能力支撑。 看我们常见的几种方案:

2.1 H5 hybrid 方案

浏览器自带跨端属性,通过各平台都有的浏览器,我们可以直接实现跨端,除了浏览器应用,我们也会把浏览器引擎嵌入到 APP 中,部分或全部使用浏览器渲染引擎,常见的如 Webkit、Blink 等。我们通过 Javascript 实现逻辑并且通过 JSBridge 调用 Native 的 API,透出的 API 需要应用在内部定制。我们一般用原生来实现要求高的界面,对于一些比较通用型,展示型的页面完全用 web 来实现,达到跨平台效果,各家的区别在于对于这块的定制和优化到了什么程度。

组成:渲染:WebView,逻辑:JS Engine,底层能力:JSBridge + 原生能力

优点:

  1. 接入成本极低,基本可以复用前端的技术栈和生态;
  2. 效率平衡性较好;
  3. 支持热更新,发版效率高;

缺点:

  1. 受限于 webview 等原因,动画复杂、无限流类的页面性能较差;
  2. 首开等对时间要求高的场景不能很好地做到极致;

如:网易云音乐,腾讯 QQ 中的大部分运营功能

2.2 框架 + 原生渲染

以 React Native 和 Weex 为代表的方案,通过结合 Web 的生态和 Native 的组件,尽可能地取长补短,让 JS 执行代码后用 Native 的组件进行渲染,实现了远超 webview 的效果。以 React Native 为例

组成:渲染:原生组件;逻辑:JS Engine + JSI;底层能力:原生组件;

优点:

  1. 开发成本均衡,大于 hybrid 模式,但是小于原生开发模式,一次开发,多端可用;
  2. 学习成本低,前端同学可以较快上手,上手速度快;
  3. 复用了前端生态,生态成熟,遇到问题,较容易解决;
  4. 有 Facebook 背书,发展相对靠谱;

缺点:

  1. 对于不同的平台特性的内容,需要有一些兼容的写法,甚至各平台各写一套;
  2. 交互复杂时,可能存在性能问题,新的架构已经大部分缓解了这个问题;
  3. 使用各端的原生组件渲染,相同代码渲染效果可能不一致性,已在尝试统一渲染。

使用 RN 的 APP: Facebook、youtube、discord、QQ、百度等等 使用 Weex 的 APP: 淘宝、天猫、饿了么等

2.3 框架 + 自渲染引擎

以 Flutter 为代表,Flutter 将代码编译成原生代码,并且直接在各个平台中使用高效渲染引擎 Skia 进行渲染,没有桥接,不调用平台相关控件。Flutter 没有直接借用原生能力去渲染组件,而是利用了更底层的渲染能力,自己去渲染组件。这种方式的链路会比 RN 的链路跟短,性能也会更好,同时在保证多端渲染一致性上效果更优。

组成:渲染:Skia;逻辑:Dart VM;底层能力:原生组件

优点:

  1. 性能好,更接近原生;
  2. 跨平台体验优秀,跨多种平台,减少开发成本;
  3. UI 跨平台稳定;
  4. 同时支持 JIT 和 AOT 两种编译方式的特性,在不同场景下可以使用不同的编译方式。

缺点:

  1. UI 跨平台,但原生能力没有,脱离不开原生,开发人员需要具备原生(Android、iOS)基础开发能力,兼容适配性较差;
  2. 稳定性、可能会因为引入了 flutter 而导致线上的 crash 率增加;
  3. 代码可读性较差,Widget 的类型难以选择;
  4. 生态中的 SDK,各种第三方包鱼龙混杂,没有一个官方的标准

除了最开始的 Android 和 iOS 跨平台支持,最新已经开始支持 Web 和 MacOS,未来还会继续支持 Win 和 Linux 平台的。在 Web 场景下,目前 Flutter 只能说可以用,但是还有挺多需要优化的空间,比如编译后 Web 文件大小,特定场景下的性能以及不同浏览器内核的兼容等等。

使用 Flutter 的应用:如钉钉(定制了较多的功能)、美团外卖、马蜂窝等

2.4 DSL 编译 + 混合渲染

该方案提供自定义 DSL 静态编译转化成目标源代码,包括 iOS、Android,H5 以及中国特色的各小程序平台。主要包括 uni-app、taro、Chameleon、Rax 等等。但各家实现不同,支持的平台类型也不一致,以 uni-app 为例:

组成:渲染:混合渲染、weex原生渲染、webview渲染,小程序和 app-vue 页面属于混合渲染,app-nvue 页面全部是 weex 原生渲染,H5 全部为 webview 渲染;逻辑:JS Engine + VUE; 底层能力:原生组件、原生插件;

优点:

  1. 支持多种小程序,多端;
  2. 开发成本低、学习成本小,本质上就是在写前端;
  3. 插件多,但是以个人开发者居多,质量参差不齐,没有保证;

缺点:

  1. 什么都想要,而什么都没有到极致,如果只是做一个能用的应用,是合适的,如果对于性能要求高,或者有比较复杂的交互,需要谨慎调研考虑一下;
  2. 兼容性问题依然有很多小细节问题,存在多端同时上线,某一端存在 bug 的情况;
  3. 原生功能依赖于 nvue ,对于没有提供的原生功能,需要对应的原生开发同学来开发;

我们要做到应用的跨端,在 PC 端相对好确定一些,以前端为主,客户端辅助实现部分前端薄弱的部分,如安装过程和一些和操作系统打交道或对性能要求比较高的部分。我们常用的 PC 端架构可以基于 Electron 、Tauri,在多平台客户端和 Web 端实现跨端。

在移动端,则更复杂一些,不仅要跨 iOS 和安卓这种操作系统级,还要跨微信小程序、支付宝小程序这种应用的衍生应用。下面我们聊聊一些有人在用的方案。

3. 实际落地的几种方案

在考虑实际落地之前需要明确一下是在什么层面的跨端,最理想的是跨全端,即跨硬件平台,在 PC、移动端设备,另一种是分两种,大屏和小屏,大屏主要是针对 PC 端、小屏主要是针对移动端。

如果是跨全端,不仅仅要考虑技术实现,从产品、到设计都要考虑,产品要考虑针对不同的端的应用场景,设计要考虑不同的屏大小下的体验效果和交互方式。这里我们只考虑移动端的情况。

3.1 Qunar 的 React Native 优先的多端统一化方案

Qunar 方案的主要逻辑是基于 Qunar 已有的 RN 技术栈,已经解决了 iOS 和 Android 的跨端问题,在此条件下,其问题变成了如何将 RN 转换为 H5 和各小程序。业内没有现成的方案,只能曲线救国,分别处理:

  • 对于 RN 到 H5,选择使用 Twitter 开源的 react-native-web,将 RN 代码运行在 H5 上,这个把 RN 的组件和 API 都用 H5 实现适配一遍,适配其行为和默认样式,在打包的时候使用 webpack 的别名机制将用到的组件替换成 react-native-web 里的对应组件。react-native-web 对原项目没有侵入性,无需改动原来的代码,只需在项目中加入一些 webpack 构建配置即可构建出运行出和 React Native 应用一致效果的 Web 应用。
  • 对于 RN 到 小程序,选择使用 Remax 组件实现一套 RN 的组件库,借用 remax 来适配到多端。Remax 的运行时本质是一个通过 react-reconciler 实现的一个小程序端的渲染器。Remax 通过 react-reconciler 生成一份自定义的 VNode Tree,再遍历 Tree 递归模版(微信小程序模板不支持递归,Remax 会为微信小程序生成一个 20 层的模板调用)渲染出对应的小程序页面。在生成之前 Remax会 为每个组件生成一份模版,然后把这份模版写入每个 page 页面里。由于小程序本身 View 与 JS 分离,因此在拿到 Vnode 时,需要通过小程序自身的 setData 触发小程序渲染。

3.2 Flutter 全平台方案

Flutter 可以理解为使用 Dart 语言定义了一套和原生一样的图形系统,其底层使用和 Android 原生一样的 Skia 引擎,安卓下直接用系统引擎,苹果生态下用自带的 SKia,这样就完全避免了 RN 中 JS Core 和原生模块通信造成的各种开销。

Flutter 这种自实现的引擎能带来目前体验最好的两端一致性,同一套代码,在 Android 和 iOS 上执行,从业务逻辑到页面布局再到最终渲染,都是在 Flutter 内部完成,通过 Flutter 实现的功能,在不同系统手机上的呈现效果是高度一致的。

Flutter 在 Android 和 iOS 上对跨端的支持较好,现在也有较多的业务在用 Flutter 完成这两端的跨端。对于 H5 而言,2019 年 2 月 Flutter1.2 版本和后面 5 月发布的 1.5 版本都主要支持了 Web ,但是到现在为止,Flutter 在 Web 端目前只支持 Dart–>JS 的转换,以及 UI 层的对齐,在工程化和性能优化方面做的工作并不多。Google 官方对 Flutter Web 性能优化所做的事项还比较少,编译输出的页面存在较大的性能问题,主要体现在以下两方面:

  • 首屏渲染时间长。即使使用了 FutureBuilder 把业务代码拆分成 xxx.part.js 之后,main.dart.js 体积依然维持在 1.1M。单一文件加载、解析时间过长,且静态资源缺少 CDN 化的支持,势必会影响首屏的渲染时间。
  • 滚动性能较差。 Flutter Web 自身实现了一套页面滚动机制,在页面滚动过程中,会频繁的创建 Canvas,最终导致滚动性能问题,甚至引起页面 Crash。

在阿里钉钉,基于 Flutter 构建的跨四端研发框架 Dutter,自己解决了数据通信问题、实现了自己的组件库,目前核心组件可以做到四端兼容,具体可以见:钉钉 Flutter 跨四端方案设计与技术实践

3.3 Hybrid 方案

这种反而在大厂是更常用的方案,其主要原因是大厂一般会有自己的框架团队,能够做比较多的定制,甚至有些把 Flutter 改吧改吧,自己实现一套,或者以容器化的方式实现自己的 Hybrid 方案。具体实现就不介绍了,这里主要介绍一下常用的一些性能优化的点,Hybrid 方案的性能优化的关键点就六个字:更早,更近、更快。

  • 更早:提前创建或初始化一些基础组件,如 WebView,减少用户体验层面等待的时间,让用户感觉更快了,也就是我们常说的预加载;
  • 更近:把资源提前缓存在本地,这里的资源可以是 Web 的资源,也可以是常用的配置数据等等,本地可以是客户端,也可以是移动端,如我们常见的「离线包」,特别是一些大流量的应用,一些资源的提前下发可以解决 CDN 等的突发流量等问题;
  • 更快:通过 Native 的方式替换一些跨端方案中的薄弱点,如一些网络控制的能力,一些视频播放或加载速度的优化等等

4. 小结

为什么标题中带一个 2022 呢? 因为技术是不断演进的,是不断发展的,今年的方案不一定适用于明年,期望有更好的方案出现。

写了这么多,把跨端的问题粗略的过了一遍,给自己温习一下,也分享一下。

任何跨端都是有成本的,当你选择跨端的时候,需要想的第一件事情,是否有必要这么做?ROI 如何?

跨端的问题很多最终都需要回归到当前端来解决,特别是一些对性能,对底层要求比较高的问题往往要在端来解决。

整体来看,跨端技术选型需要考虑如下 4 个问题:

  1. 战略和业务的问题,从公司产品战略和业务产品的角度探讨是否有必要跨端,如你的业务是否有强依赖的多端需求,各端的用户体量是否值得有如此投入?还是只要一端强就可以了?
  2. 人和组织的问题,在确认有跨端的强需求后,再看是否有合适的人和人才梯队来构建你想要的跨端架构,并且在确定跨端架构后考虑关于分工的问题,如一部分同学(如原移动端的同学)负责框架和能力,一部分的同学(如前端的同学)负责业务。在考虑现有人和组织的问题的时候,考虑一下后续人才招聘和团队人才密度的情况;
  3. 生态的问题,生态的问题会决定研发效率,是否有成熟的生态,是否有前从把坑都踩过了,当遇到某个场景是否有现成的解决方案或者类似的解决方案等等;
  4. 性能和体验的问题,随着业务的复杂,交互,场景也会越发的复杂,当遇到因复杂交互,或者复杂业务场景引起的性能问题时,是否有成熟的解决方案,或者退一步,是否可以解决?在多端一致性的问题上,是否能满足需求,或者兼容处理的成本有多高?

最后,祝大家国庆节快乐~

参考文档: