标签归档:技术管理

jbrz

技术团队管理中的 4 个基本认知

在技术团队的日常管理工作中,一个管理者做得最多的事情是决策、开会,最不想看到的是线上事故,线上事故给技术团队带来非常大的冲击,而给线上系统带来风险最大的研发环节是线上环境的变更,甚至有人说:「没有变更就没有问题」,对此我们不置可否,但这些变更之所以会导致事故,从根源上来讲大部分是技术同学犯了错。

这里的决策、会议,变更,错误合起来是我们日常工作中的大部分。而对于这些的基本认知是一个技术管理者在带团队过程中逐步提升的,今天我们就来聊聊这 4 个基本认知。

1 决策

在带团队的过程中我们会做非常多的决策,如去决策是否投入足够大量的人力满足某个业务,或者升级架构,或者构建某个流程机制等等。

这些决策中从服务于时间维分为两种:

  • 当下的决策,如评估需求优先级,先做什么,后做什么,关注的是当下和已有的
  • 未来的决策,如评估技术架构演进、团队演化和发展等等,关注的是未来

当下的决策在我们的工作中最常用于评估产品需求、评估技术方案或实现方案。

对于产品需求,技术管理者的作用是把价值不高,或者没有价值的需求干掉,不让其进入研发,不让公司的人力成本白白浪费掉。一般我们会对于提需求的同学问如下的问题:

  1. 为什么会有这个需求? 一般是想看这个需求是怎么来的,用户故事是怎样的;
  2. 这个需求的价值是什么? 一般是想看这个需求做了之后对产品或业务的好处,看产出;
  3. 如何度量这些价值? 一般是想通过数据看到需求的价值,把价值反馈在指标上,如营收指标、效率指标等。

对于技术需求或技术方案,技术管理者的作用是来评估当下的选择是否正确。一般我们会评估如下的点:

  1. 有没有做过方案评估,即有没有评估过业内的方案、公司内的方案以及对于当下的现况的分析;
  2. 是否合理的方案,有没有明显的缺陷或漏洞;
  3. 有没有显得特别高大上,特别先进,防止过度设计,浪费资源。

未来的决策更多是管理者站在当下思考团队的发展,人员的发展和技术架构的发展等,是一种未雨绸缪的远见。

是基于公司战略,在组织的先进性、技术的先进性的前瞻性布局。如现有的人才梯队和人才密度是否能满足公司三到五年的发展,现在的技术架构是否能满足公司三到五年后的战略,对于行业内新的技术是否我们需要扩大资源投入,去预研并应用在业务中。

这些前瞻性的决策都是管理者基于对公司业务和业务未来发展有足够的认知和理解后做的。

我们所做的这些决策都是以有限的资源达成我们的目的,其本质是资源的分配。当我们分配资源的时候,最最重要是看投入产出比以及和公司战略的方向是否一致。

2 变更

这里的变更是指生产环境的变更。首先我们看一下定义,什么叫生产环境?生产环境是指服务于客户的应用及其运行环境,以及和这些环境相关联的环境和系统。

如果一个应用或环境和生产环境有接触,那它也是生产环境。

什么叫变更管理,变更管理包括什么?

变更管理是指以可控的方式对线上的服务、配置或基础设施进行变更,从而减少变更对业务和服务质量的影响,快速处理变更可能带来的问题,提升系统的稳定性。

在日常工作中我们见到变更有如下 4 种:

  1. 应用变更,也称为代码变更,是我们最最常见的变更类型,主要是通过修改代码改变应用程序并通过发布系统发布到线上。这也是我们变更管理中风险最大的地方,因为变更的人,变更的位置和逻辑等都是不确定的。除了正常的发布变更,应用的回滚也是应用变更的一种,因为其改动了线上的应用;
  2. 配置变更,是指应用系统的配置变更,一般是通过配置系统来变更,触发线上应用的热更新或滚动,配置如果是写死在代码中,会变为代码变更;
  3. 基础设施变更,此变更一般是运维同学来操作,可能涉及网络设施变更,服务解析变更等等,如 DNS 的解析,网络安全配置等等,这些都算到基础设施变更里面,而不是配置变更,又如宿主机挂了,需要替换宿主机,此时也会导致基础设施的变更;
  4. 容量变更,此处单独列出是因为相对于基础设施,容量变动的影响逻辑不一样,其主要是通过垂直或水平的方式提升系统的容量,特别是当出现容量告警的时候,此变更经常由运维同学手动,或者系统自动触发。

那么如何控制变更?这里我们先提一下变更管理的标准流程。

变更管理的标准流程:

  1. 变更申请:在我们的流程中可能是创建发布记录,或者申请紧急发布
  2. 变更评审:变更评审主要是检查变更过程是否完备,以降低变更的风险,其包括如下内容:

    1. 就绪分析:材料是否完备,人员、设备、软件、网络是否就绪,测试是否达到上线要求等。
    2. 风险分析:架构、性能、业务、合规等方面的风险评估,变更内容是否属于需求范围,变更是否可控。
    3. 重要程度:变更属于一般、重要、紧急、标准哪一种。
    4. 变更审查:内容是否满足业务需求,内容是否通过测试,测试是否全面、有效。
    5. 应急管理:变更步骤、应急方案、回滚方案、应急预案是否完备。
    6. 变更实施:变更计划时间如何安排,发布及回退操作步骤是否完备,自动化步骤情况。
    7. 变更验证:变更涉及的业务、技术验证方法与时间安排。
  3. 变更审批:相关负责人对于变更评审的结果进行确认,并审批通过。
  4. 变更执行

    1. 根据发布计划执行发布操作,一般应该有一个灰度的过程;
    2. 验证线上功能并回归主流程;
    3. 持续灰度,观察用户直到灰度完成。
  5. 变更验收

    1. 对发布的功能进行验收,对于影响范围内的功能进行验收,对业务主流程进行回归验收;
    2. 留守,并观察日志、监控服务负载等,这个操作是为了及时发现验收检查漏掉的问题,或者及时处理隐藏的问题,以减少变更后产生的问题对线上业务的影响。

我们做这个流程是形式上的安慰,还是僵化的惯性,还是能真正地解决问题,是我们在做这个流程以及执行这个流程中需要着重思考的问题。

在变更前,即我们变更线上环境前需要自己做 Code Review,以及交叉的检查,以尽量减少问题流转到后面的操作中,节省问题的处理成本。

变更管理没有银弹,我们能做的是控制节奏,敬畏线上,以更机制化的方式提前发现问题并解决问题。

3 会议

会议是一个相互沟通、交互信息、形成一致看法,从而解决问题的管理工具。

从会议的定义来看,会议是一些人有组织、有领导地为了某种目的而进行讨论和商议的集会。

当我们思考一个会议要不要开时,可能需要先思考这个会议的目的是什么。

如果一个会议没有需要讨论的地方,没有明确的目的,可能大概率是一个不需要开的会的,又或者仅仅是一个简单的信息同步,直接文档或者在群里同步就可以了。除非文档没法完全解决问题,比如一些战略的宣讲,一些大的事项的发布,需要有一个仪式感的会,现场答疑的会。

如果发现两个会的参会人差不多,那么是否取消其中的一个会呢?不一定,看目的是否一致,如果解决的问题不一样,可以同时存在。

回顾我们常开的几种会议。

  • 项目例会:项目信息同步,问题卡点讨论,待办相关同步,这里的项目例会又包括常规项目例会和专项的项目例会,是项目管理中的信息渠道;
  • 管理例会:团队仪式感必不可少的部分,除了事项的讨论,还有一个作用是发散的聊天,不用那么严肃,闲谈之中迸发一些火花,并达成一些共识和认知上的一致;
  • 单独定期沟通会议:更私密一些的沟通会议,除了常规事项同步,更多的是一个散而不散的个人想法、规划、思路等的探讨;
  • 复盘会议:对特定事项和问题的总结,讨论,属于常规会议机制的一种,起总结,沉淀的作用;
  • OKR 会议:目标对齐,起方向对齐的作用;
  • 需求规划会:有计划的对于需求进行规划,评审,然后进入迭代,开发测试并交付;
  • 技术方案评审会:严格准入技术方案,集众人之力评估方案的可行性,看是否有什么缺漏。

着点讲一下周会,周会我们一般是指周例会,属于例行会议的一种,按周或双周召开。

周会的目的是根据会议的属性,定期回顾讨论总结指定的项,可能是专项,也可能是过程中的事项或突发的事情等。开会的目的主要是交流和讨论,那么在周会上我们讨论什么,在确定讨论内容之前,我们先看看哪些不要在周会上讨论:

  1. 紧急的事情不适合在周会讨论,出现的时候直接搞定;
  2. 非跨团队的问题不适合周会讨论;
  3. 纯执行细节问题不适合周会讨论;
  4. 大方向决策问题不适合周会讨论。

总结下来,就是涉及与会各团队的,对整体性计划或者需要协同配合的问题,或者里程碑式的改进型问题适合在周会上讨论。

当然,也不绝对,这还是一个人治的过程。

如果是你一个会议组织者,在组织一个会议的时候,需要考虑以下三件事:

  1. 这个会议最重要的事情是什么,是想解决什么问题?想讨论什么?
  2. 能否达到目标? 大家对于目标是否有所了解?
  3. 如何达到目标? 达到目标的关键路径是怎样的?干系人都在吗?

4 错误

工作中我们会出一些错误,生活中我们也会出一些错误,这些错误可能会影响同事朋友,或者影响线上产品,公司业务,甚至可能会造成个人或公司的经济损失,错误有其类型,在了解了这些类型后,我们可以适当的减少出错或规避这些错误。

从个人的角度来看,错误可分为成长之错,无心之错和性恶之错。

  1. 成长之错,我们都是从懵懂孩童,成长为有知识的学生,到长大成人,出来工作,工作中也是从不会到会,到熟练和精通,在这个过程中,正是因为一个个的错误,才成就了我们的成长,成长之错为正常之错,可允之;
  2. 无心之错,非有意为之的错误,一时失察导致工作出现错误,从而给别人带来不好的影响,或者粗心导致过错,其出发点都非有意,出错了就认,改过即可,不可连续;
  3. 性恶之错,以人性之恶为出发点或者动机,此种错不可原谅。

从工作的角度,错误可以分为超出型错误,信息型错误,粗心错误,态度型错误和风险型错误。

  1. 超出型错误,当你尝试去做能力之外挑战的时候,或者你不熟悉的领域或知识盲区,或者超出当前因为自身能力或其他条件的束缚,做得不够好而犯的错。比如一些新的想法的落地,一些新技术的试点等等,这些都没有人前人尝试过,至少在当前范围内没有,此时可能会遇到想象不到的坑,或者无法解决的问题,从而出现错误,甚至失误。这种创新或者超前的错误是可以接受的;
  2. 信息型错误,属于信息不对等,或者信息不全,知识不全面导致的错误,特别是对于工作中面对某个项目一些信息没有,或者没有去全面了解背景信息从而做出错误的决策,这种错误不会反复出现,但尽可能避免在不同类型的事情上犯同类型的错误;
  3. 粗心错误,这种比较常见,与无知错误不同,这种情况是你明明知道怎么回事,但是因为不小心或者忘记了而导致的错误,如果是粗心之人,可能会一错再错,此时需要反思自己,以某种方式规避;
  4. 态度型错误,指做事的态度有问题,比如眼看自己负责的一件事情要出问题或者已经出问题了,但是没有想办法去解决,没有付出努力,而是躺平,让事情自己变坏,甚至影响面不可控,这种错误是不允许的;
  5. 风险型错误,主动去做事情,但风险很高,是否会犯错不受自己的控制。比如你面临一个重要的选择,但在结果出来之前,你之前掌握的所有信息都无法告诉你哪个选择是绝对正确的,你只能去做自己认为是大概率的选择。而这种错误在工作中是极有可能遇到的。

对于工作中的错误我们应该如何减少或者规避呢?

  1. 超出型错误,从公司层面或者团队层面提供一些培训,或者在新人安排导师,提升大家的能力,或者通过流程机制让更有经验或者能力更强的人对于新的内容做一些把关;
  2. 信息型错误,信息型错误可以在公司层面搞定完善的文档和快捷的查询机制,任何技术或产品讨论以及达成的共识,要尽可能用某种沟通渠道发送到所有相关的人。让大尽可能的掌控更全面的信息;
  3. 粗心错误,设定一些机制来规避,如复盘机制,通过复盘,深挖过程中的问题,总结经验,为后续减少此类问题做准备,同时可以在流程上做一些 check 机制,通过多人的 check 减少错误的出现;
  4. 态度型错误,本着治病救人的态度先看看,如果实在不行,考虑换个人吧;
  5. 风险型错误,针对高风险的事情,尽可能的准备一个 PlanB,当事情没有按我们预想的方向发展时,启用 PlanB,减少损失,这也是我们下棋时通常会用到的策略,走一步,想三步。

从团队来看,一个人犯错,可能是人的问题,一群人犯错,一定是机制或系统出了问题。

当然,工作中我们允许试错,但是不能一错再错,避免一些不应该犯的错误,最大可能从错误中成长,这才是我们应有的态度。

除了以上,《清单革命》中说人类的错误可以分为两大类型。第一类是「无知之错」,我们犯错是因为没有掌握相关知识。第二类是「无能之错」,我们犯错并非因为没有掌握相关知识,而是因为没有正确使用这些知识。

现在,我们面临的错误更多的是「无能之错」,也就是如何持续、正确地运用我们所掌握的知识。「无知之错」可以原谅,「无能之错」不被原谅。

5 后记

管理是门实践的科学,大多数的书籍和文章都是个人或组织的经验之谈,没有公理,只能在俗世不断修行和精进,以求能「知行合一,止于至善」。

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

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. 性能和体验的问题,随着业务的复杂,交互,场景也会越发的复杂,当遇到因复杂交互,或者复杂业务场景引起的性能问题时,是否有成熟的解决方案,或者退一步,是否可以解决?在多端一致性的问题上,是否能满足需求,或者兼容处理的成本有多高?

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

参考文档: