写点什么

一位架构师的感悟:过度忙碌使你落后

  • 2020 年 9 月 18 日
  • 本文字数:4009 字

    阅读完需:约 13 分钟

一位架构师的感悟:过度忙碌使你落后

我踩过的坑,希望大家不用再踩。


到现在我工作 17 年了, 担任架构师的职位也超过了 10 年,担任过像 HP、Amazon 这样的世界级团队的架构师,也担任过像汇量科技这样快速成长的中小企业的技术领导。应 InfoQ 邀请分享一下我的工作感悟,分享内容部分来自成功总结,更多是来自失败的反思,希望我踩过的坑大家可以不用再踩。


“提出问题”难于“解决问题”

作为技术人员,我们已经习惯于作为问题的解决者给出设计方案,而很少以问题提出者的身份去思考设计方案。团队中常见的典型矛盾,就是产品团队和研发团队之间的矛盾。作为研发团队,我们常吐槽产品团队的需求不合理、不懂技术等。其实我们可以试着把自己的工作再往前移一下,不仅仅是去设计架构、实现产品的需求,同时也试着去实现客户的需求,甚至发现潜在的需求。


这时我们就变成了在设计上提出问题的人,你会发现提出问题的同时,在很多时候也需要同样深入的思考。设计一个好的问题,甚至比解决问题更难。


其实即便是软件开发领域的大神 Frederick P. Brooks Jr.(《人月神话》的作者)也会有同样的感叹。


“The hardest part of design is deciding what to design.”

– 《The design of design》, by Frederick P. Brooks Jr.


决定“不要什么”比“要什么”更难

也许是由于人性的贪婪,对于软件系统我们同样想要更多:更多功能、更好的性能、更好的伸缩性、扩展性等等。作为软件架构师要明白软件架构设计就是一种取舍或平衡。当大家都在往里面加东西的时候,架构师更应该来做这个说“不”的人。


软件设计和定义过程中存在很多取舍,例如:


  • 完善功能和尽早发布的取舍。

  • 伸缩性和性能的取舍。


著名的 CAP 原则,就是一个很好的取舍指导策略。为了更好的取舍,保持架构风格的一致性,在一开始架构师就应该根据系统的实际需求来定义一些取舍的原则,如:


  • 数据一致性拥有最高优先级。

  • 提前发布核心功能优于完整发布等。


非功能性需求决定架构

因为软件是为了满足客户的功能性需求的,所以很多设计人员可能会认为架构是由要实现的功能性需求决定的。但实际上真正决定软件架构的其实是非功能性需求。


架构师要更加关注非功能性需求,常见的非功能性包括:性能,伸缩性,扩展性和可维护性等,甚至还包括团队技术水平和发布时间要求。能实现功能的设计总是有很多,考虑了非功能性需求后才能筛选出最合适的设计。



以上架构模式来自《面向模式的软件架构》的第一卷,这套书多年来一直是架构师的必读经典。面向架构的模式就是为不同的非功能性需求提供了很好的参考和指导。图中的 Micro-Kernel 模式,更加关注可扩展性和可用性(错误隔离)。


“简单”并不“容易”

很多架构师都会常常提到保持简单,但是有时候我们会混淆简单和容易。简单和容易在英语里也是两个词“simple”和“easy”。


“Simple can be harder than complex:

You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.

To be truly simple, you have to go really deep.”

–SteveJobs


真正的一些简单的方法其实来自于对问题和技术更深入的理解。这些方案往往不是容易获得的、表面上的方法。简单可以说蕴含着一种深入的技巧在其中。


下面我来举一个例子。


首先我们来回顾一下软件生命周期中各个阶段的成本消耗占比。以下是来一个知名统计机构的分析报告。我们可以看到占比最大的是维护部分,对于这一部分的简化将最具有全局意义。



我曾经开发过一个设备管理系统,移动运营商通过这个系统来管理移动设备,实现包括设备的自动注册、固件和软件的同步等管理功能。这些功能是通过一些管理系统与移动设备间的预定义的交互协议来完成的。


电信专家们会根据业务场景及需求来调整和新增这些交互协议。起初我们采用了一种容易实现的方式,即团队中的软件工程会根据电信专家的说明,将协议实现为对应代码。



之后我们很快发现这样的方式,让我们的工作变得没那么简单。


“I believe that the hardest part of software projects, the most common source of project failure, is communication with the customers and users of that software.”

–Martin Fowler


正如软件开发大师 MartinFowler 提到的,“沟通”往往是导致软件项目失败的主要原因。前面这个项目最大的问题是在系统上线后的运行维护阶段,电信专家和开发工程师之间会不断就新的协议修改和增加进行持续的沟通,而他们的领域知识和词汇都有很大的差别,这会大大影响沟通的效率。因此这期间系统的运行维护(协议的修改)变得十分艰难,不仅协议更新上线时间慢,而且由于软件工程对于电信协议理解程度有限,很多问题都要在实际上线使用后才能被电信专家发现,导致了很多的交换和反复。


针对上面提到的问题,后来我们和电信专家一起设计了一种协议设计语言(并提供可视化的工具),这种设计语言使用的电信专家所熟悉的词汇。然后通过一个类似于编译器的程序将电信专家定义好的协议模型转换为内存中的 Java 结构。这样整个项目的运行和维护就变得简单高效了,省去了低效的交流和不准确人工转换。



我们可以看到一开始按电信专家的说明直接实现协议是更为容易的办法,但就整个软件生命周期来看却并不是一个简单高效的方法。


永远不要停止编码

架构师也是程序员,代码是软件的最终实现形态,停止编程会逐渐让你忘记作为程序员的感受,更重要的是忘记其中的“痛”,从而容易产生一些不切实际的设计。


大家可能听说过在 Amazon,高级副总裁级别的 Distinguish Engineer(如:James Gosling,Java 之父),他们每年的编码量也非常大,常在 10 万行以上。


风险优先

架构设计很重要的一点是识别可能存在的风险,尤其是非功能性需求实现的风险。因为这些风险往往没有功能性需求这么容易在初期被发现,但修正的代价通常要比修正功能性需求大非常多,甚至可能导致项目的失败,前面我们也提到了非功能性需求决定了架构,如数据一致性要求、响应延迟要求等。


我们应该通过原型或在早期的迭代中确认风险能够通过合理的架构得以解决。


绝对不要把风险放到最后,就算是一个项目要失败也要让它快速失败,这也是一种敏捷。


从“问题”开始,而不是“技术”

技术人员对于新技术的都有着一种与身俱来的激情,总是乐于去学习新技术,同时也更有激情去使用新技术。但是这也同样容易导致一个通病,就是“当我们有一个锤子的时候看什么都是钉子”,使用一些不适合的技术去解决手边的问题,常常会导致简单问题复杂化。


我曾经的一个团队维护过这样一个简单的服务,起初就是一个用 MySQL 作数据存储的简单服务,由团队的一个成员来开发和维护。后来,这位成员对当时新出的 DynamoDB 产生了兴趣,并学习了相关知识。


然后就发生下面这样的事:


  • 用 DynamoDB 替换了 MySQL。

  • 很快发现 DynamoDB 并不能很好的支持事务特性,在当时只有一个性能极差的客户端类库来支持事物,由于采用客户端方式,引入了大量的额外交互,导致性能差别达 7 倍之多。这时候,这个同学就采用了当时在 NoSQL 领域广泛流行的最终一致技术,通过一个 Pub-Sub 消息队列来实现最终一致(即当某对象的值发生改变后会产生一个事件,然后关注这一改变的逻辑,就会订阅这个通知,并改变于其相关数据,从而实现不同数据的最终一致)。

  • 接着由于 DynamoDB 无法提供 SQL 那样方便的查询机制,为了实现数据分析就又引入了 EMR/MapReduceJob。


到此,大家可以看到实现一样的功能,但是复杂性大大增加,维护工作也由一个人变成了一个团队。



过度忙碌使你落后

对于 IT 人而言忙碌已成为了习惯,加班常挂在嘴边。“996”工作制似乎也变成了公司高效的标志。而事实上过度的忙碌使你落后。经常遇见一些朋友,在一个公司没日没夜的干了几年,没有留一点学习时间给自己。几年之后倒是对公司越来越“忠诚”了,但忙碌的工作同时也导致了没有时间更新知识,使得自己已经落后了,连跳槽的能力和勇气都失去了。


过度忙碌会导致没有时间学习和更新自己的知识,尤其在这个高速发展的时代。我在工作经历中发现过度繁忙通常会带来以下问题:


  • 缺乏学习导致工作能力没有提升,而面对的问题却变得日益复杂。

  • 技术和业务上没有更大的领先优势,只能被动紧紧追赶。试想一下,要是你都领先同行业五年了,还会在乎通过加班来早一个月发布吗?


反过来上面这些问题会导致你更加繁忙,进而更没有时间提高自己的技术技能,很快就形成了一个恶性循环。


练过健身的朋友都知道,光靠锻炼是不行的,营养补充和锻炼同样重要。个人技术成长其实也一样,实践和学习是一样重要的,当你在一个领域工作了一段时间以后,工作对你而言就主要是实践了,随着你对该领域的熟悉,能学习的到技术会越来越少。所以每个技术人员都要保证充足的学习时间,否则很容易成为井底之蛙,从而陷入前面提到的恶性循环。


最后,以伟大诗人屈原的诗句和大家共勉:“路漫漫其修远兮,吾将上下而求索“。希望我们大家都可以不忘初心,保持匠心!


作者简介:


蔡超,Mobvista 技术 VP 兼首席架构师,SpotMax 云服务创始人。拥有超过 15 年的软件开发经验,其中 9 年任世界级 IT 公司软件架构师/首席软件架构师。2017 年加入 Mobvista,任公司技术副总裁及首席架构师,领导公司的数字移动营销平台的开发,该平台完全建立于云计算技术之上,每天处理来自全球不同 region 的超过 600 亿次的请求。


在加入 Mobvista 之前,曾任亚马逊全球直运平台首席架构师,亚马逊(中国)首席架构师,曾领导了亚马逊的全球直运平台的开发,并领导中国团队通过 AI 及云计算技术为中国客户打造更好的本地体验;曾任 HP(中国)移动设备管理系统首席软件架构师,该系统曾是全球最大的无线设备管理系统(OMA DM)(客户包括中国移动,中国联通,中国电信等);曾任北京天融信网络安全技术公司,首席软件架构师,领导开发的网络安全管理系统(TopAnalyzer)至今仍被政府重要部门及军队广为采用,该系统也曾成功应用于 2008 北京奥运,2010 上海世博等重要事件的网络安全防护。


2020 年 9 月 18 日 13:3813239

评论 10 条评论

发布
用户头像
说的真有水平,点赞!!
2020 年 10 月 18 日 19:01
回复
用户头像
写的很好
2020 年 10 月 09 日 09:43
回复
用户头像
从机械和不规范的编程,到迈向高效,持续更新学习的状态转变,这个越早越好。学习了
2020 年 09 月 30 日 15:08
回复
用户头像
过度忙碌使你落后,大实话
2020 年 09 月 29 日 10:05
回复
用户头像
“996”工作制似乎也变成了公司高效的标志, 说反了吧
2020 年 09 月 28 日 19:40
回复
用户头像
可以有
2020 年 09 月 28 日 09:22
回复
用户头像
一直认为:倡导996的公司实际上就是没有灵魂和核心竞争力的公司。
2020 年 09 月 27 日 17:53
回复
用户头像
真棒
2020 年 09 月 27 日 17:05
回复
用户头像
很有启发 对“简单”并不“容易”这一小节 有共鸣
“后来我们和电信专家一起设计了一种协议设计语言(并提供可视化的工具),这种设计语言使用的电信专家所熟悉的词汇。然后通过一个类似于编译器的程序将电信专家定义好的协议模型转换为内存中的 Java 结构。”
这一块能否更详细的介绍一下呢 因为日常开发中 很有可能会遇到这种场景
2020 年 09 月 27 日 09:40
回复
用户头像
怒赞
2020 年 09 月 27 日 09:25
回复
没有更多了
发现更多内容

CMMI V2.0丨如何通过CMMI真正在企业中的实施规模化敏捷开发

渠成CMMI

软件 研发管理 CMMI

Pulumi 如何在 Windows 环境中设置

HoneyMoose

关于OpenHarmony 2.0共建进展

罗燕珊

开源 鸿蒙 OpenHarmony

快成物流科技 x mPaaS | 小程序容器加持下的技术架构“提质增效”

蚂蚁集团移动开发平台 mPaaS

小程序 移动开发 mPaaS

浅谈负载均衡

Damon

负载均衡 5月日更

保障实时音视频服务体验,华为云原生媒体网络有7大秘籍

华为云开发者社区

云原生 音视频 华为云 媒体网络 架构分层

Windows Terminal 安装和运行

HoneyMoose

Flutter开发:Another exception was thrown:Unable to load asset:…的解决方法

三掌柜

5月日更

微软 WSL 重装操作系统

HoneyMoose

“为爱而生 温暖陪伴”——2021年中国洗地机行业发展峰会圆满落幕

DT极客

高并发调优backlog多大合适?

运维研习社

运维 Nginx PHP-FPM 5月日更 并发调优

Hadoop定位问题日志跟踪

InfoQ_Springup

hadoop

从技术趋势看质量赋能

BY林子

敏捷 软件测试 质量赋能

Golang function

escray

学习 极客时间 Go 语言 5月日更

音频均衡器EQ

floer rivor

音视频 Eq

【和平精英x TcaplusDB】两周年,让我们一起加油!

tcaplus

数据库

中公、马士兵、千锋、拉勾入局,腾讯课堂“薪选”IT人才培养按下加速键

DT极客

并行文件存储和分布式 NFS 文件存储有何不同

焱融科技

容器 云原生 高性能 文件存储 技术博客

❤【520特别祝福篇】愿有情人终成眷属,已成眷属爱情稳固

浩宇天尚

爱情 5月日更 520单身福利 520 单身福利

珠联壁合地设天造|M1 Mac os(Apple Silicon)基于vscode(arm64)配置搭建Java开发环境(集成web框架Springboot)

刘悦的技术博客

Java vscode spring Boot Starter JDK11 m1

Nginx基础配置-反向代理

梁龙先森

nginx 大前端

Too many open files 的四种解决办法

ilinux

5G进京 “赶考”记:“占得上、保持稳、体验优、信号好”四道考题,分别打几分?

脑极体

浪潮云洲链斩获2020-2021年度新一代信息技术创新产品殊荣

浪潮云

这一次,彻底搞懂 Go Cond

HHFCodeRv

Go 语言

多方安全计算:隐私保护集合求交技术

华为云开发者社区

数据集 PSI 隐私保护集合交集 可信 伪随机函数

拥有5大核心竞争力的华为云GaussDB,成SACC2021最靓那一个…

华为云开发者社区

数据库 华为云 GaussDB 存算分离 GaussDB(for Redis)

聊聊dubbo协议

捉虫大师

人人都爱Kubernetes,Docker难道就不香了吗?

守护石

Docker Kubernetes DevOps

Windows 任务管理器中如何显示 CPU 逻辑处理器情况

HoneyMoose

PKI系统简介

上海派拉基础研发

CA PKI

一位架构师的感悟:过度忙碌使你落后-InfoQ