您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 开发技术 > 正文

如何成为一名优秀的架构师? 你需要吸取这些经验

发表于:2021-05-27 作者:TomGE 来源:微观技术

软件架构跟盖楼有异曲同工之妙。首先建筑师(软件行业:称之为架构师)在图纸上把大楼外观、主体结构、材料工艺、施工流程等设计好。施工队根据图纸,打好地基,并开始建设能满足抗地震、抗台风、抗沉降(高并发、高性能、高可用)等必备条件的大楼主体结构,然后再浇筑墙体、封顶、室内装饰。

建筑师对主体结构的设计,在软件工程中便是架构设计;大楼的主体结构在软件工程中就是架构,它主要处理软件的子系统和组件的开发和部署方式、技术指标和规范,以及它们之间的相互关系。

很多人多架构师可能有误解,认为只是做了好多很炫的PPT,各种的架构图、UML图、流程图、模块拆分、组件拆分、部署图等,感觉完全是纸上谈兵,一行代码没写,夸夸其谈。

其实不然,古代带兵打仗,讲究兵马未动粮草先行,正式开拔前一定要先把准备工作做好。毕竟做设计比写代码推翻重来的成本要低得多。

成为一名优秀的架构师需要具备很多条件:

  • 业务理解转化能力

  • 思维抽象能力

  • 软件建模能力

  • 高并发、高性能、高可用的分布式系统架构设计能力

  • 前沿技术选型把控能力

  • 系统重构能力

  • 快速学习能力

  • 此外,还要懂分布式缓存、消息队列、负载均衡、数据库、NoSQL、搜索、RPC、容器、分库分表、注册中心、分布式配置、链路跟踪、服务治理、系统监控、微服务等等。此处省略1万字。。。

兵法有云,“战略上藐视敌人,战术上重视敌人!”

有一个自信的意识,意味着你一只脚已经迈入成功的大门。

低头走路,时不时也要抬头看天。要想做好、做精一件事,不能只局限某一个细节点,要做到既有点也有面。放眼全局,才能更好验证细节做的好不好,在整体架构中是否合理。否则,很容易导致 木桶效应

如何做好架构设计,有哪些经验可以遵循,我们简单来学习下

 一、“拆分” ,降低架构复杂度

世上没有无缘无故的爱,也没有无缘无故的恨,一切皆有因果。那为什么要做拆分呢?

人类大脑神经信号传递靠的是离子,通过透过钠与钾等离子来传输,其速度被限制在化学扩散的速率,所以我们的大脑内大部分神经信号是以约 30m/s 的速度传播。

由于人脑处理问题的能力是有限的,当面对复杂问题时,会主动去寻找一些方法提升效率(这也是人与动物的最大区别,人具有思考能力)。神器就是 拆分 ,将复杂问题拆解为多个相对简单的小问题。分而治之、各个击破,这样做极大地提高了解决复杂问题的可能性和效率。

简单归纳:应用拆分、服务拆分、数据拆分、应用解耦。

比如常见的电商领域,当用户发展到一定规模后,会拆分成一系列的业务子域:商户、商品、库存、权限、订单、支付、履约、结算、售后、财务、会员、营销、采购、仓储等众多模块,项目实战中可以结合DDD,来帮助我们理清、划分各个子系统的边界。

拆分带来的好处:

  • 需求不断叠加导致并行开发和上线时,通过拆分可以减少相互影响。

  • 降低系统的复杂度,让研发人员适当聚焦,提升专业度。

  • 弱化各个模块间的耦合性,降低整体系统风险

  • 大家分工更加明确,各司其职,工作效率更高

  • 拆分微服务后,无状态化部署,更容易横向扩容,方便我们有针对性补齐某块性能短板,提升整体系统吞吐量

拆分需注意事项:

  • 最好是从 顶层按业务及业务流程来垂直拆分 ,而不是纯技术视角维度。毕竟研发更多是跟着产品节奏来走
  • 对于拆分得到的具体模块,可以按 读写分离 、 在线离线分离 、 快慢分离 、 场景分离 等方式做进一步的水平拆分。
  • 随着业务的升级演化,不断调整策略,将 易变与稳定 、 共性与非共性 进行水平拆分

拆分是架构设计大型复杂系统的第一步,对降低系统复杂性有着决定性的意义,它也是架构师的必备技能之一。

 二、认知抽象,架构模式有通用性

认知很重要,认知很重要,认知真的重要,重要的话说三遍。大家应该听过一个成语:“一通百通”,出自明·吴承恩《西游记》。

原文:这猴王也是他一窍通时百窍通,当时习了口诀,自习自练,将七十二般变化,都学成了。

翻译过来:一个主要的弄通了,其他的自然也都会弄通。

相信很多人都面试过别人,或者被别人面试过。大家有没有发现一个现象,简历中项目经验很重要,但是有时想招到一个对口业务的人真的很难,这时考量标准就会转变为对求职者的基础技术能力(比如算法)、表达能力、归纳能力、抽象思维能力。正所谓“一通百通”,你在一个行业积累了成功的项目经验,那么再换一个赛道也不会有问题。

现如今,互联网行业快速发展,各种垂直化业务如雨后春笋般涌现出来,腾讯的IM即时通讯、阿里巴巴的电商、滴滴的打车、百度的搜索、饿了么的O2O外卖。

看似形态各异,但细细一想,是不是也可以归纳为:读业务、写业务、扣减业务。

  • 读业务:对于读的SLA(服务等级协议)要求非常高。但考虑到数据更改的频率低,通常采用 数据尽量前置 应对性能要求。
  • 写业务:对写的SLA要求高, 写业务的特点是写入的数据是用户私有的而不是共享的 ,同时写入不需要依赖已有的数据。对于 UGC 写业务,只要尽最大可能将数据存储下来即可。
  • 扣减业务:与上面写业务类似,但是写入的内容要少很多,但是对单个数值的并发修改能力要求很高, 可以考虑将大库存拆分N份小库存,从而降低并发写压力。

假如你在微博工作做,知道微博的热搜事件(读事件)如何架构,缓存的热点问题如何解决。那么同样切到电商业务,对一些爆款商品的展示,我们也是有很多 共性化 的技术方案可以参考,我们要学会举一反三。

 三、一图胜千言,画各种类型图

为什么架构师都喜欢画图呢,一图胜千言啊。人的生理结构更容易接受视觉型知识输入。

《五视图法》描述架构:

  • 逻辑视图:对应逻辑架构,主要关注功能需求,以及系统职责和行为的划分。逻辑视图不仅包括用户可见的功能,还包括相应的辅助功能。比如秒杀系统中的活动场次切换、商品列表、用户登录、活动管理、后台权限等功能

  • 开发视图:对应开发架构,主要关注系统开发过程中的质量属性。它包括软件源码的组织方式、引入开源框架、配置方式、编译打包方式以及与第三方包的依赖关系等。

  • 运行视图:对应运行架构,主要关注软件运行过程中的质量属性,它包括进程、线程、协程、对象之间的并发、同步、通信的问题等。

  • 物理视图:对应物理架构,主要关注安装和部署需求。它包括软件运行时的系统、网络、服务器等基础设施和相关配置,以及如何利用基础设施来实现应用程序的高可用、可伸缩等。

  • 数据视图:对应数据架构,通常用 E-R 图(Entity Relationship Diagram,实体-联系图)表示。主要关注数据需求,它包括数据的格式、属性、关系等。

四、系统是演化来的,切勿初期就翻天覆地

随着公司业务的扩大,系统也会经历一个演化过程。大致分为这么几个阶段:烟囱式架构 --> 平台化 --> 中台化

就像人一样,每个阶段也都有自己的优点和不足,业务早期追求速度,讲究快速落地,抢占市场,时间就是生命,我们可能采用集中式架构,系统快速落地,后期在慢慢优化、架构升级。

早期的系统很多都是烟囱式架构,自上而下一体化,存在大量的模块重复,导致维护成本很高。另外模块割裂对业务也有很大影响,比如:会员模块,每个渠道都有自己的独立用户体系,用户登录网站系统时需要记住多套账号,体验较差。也不利于数据互通、共享,无法最大化发挥数据的价值。 此时,便有了从烟囱式架构朝着平台化演化。

平台化是从降低技术重复的角度出发,将重复模块进行融合,从而提升效率。

中台化,也称为企业级的能力复用平台。从业务复用的角度出发,进一步提升业务落地的效率。

中台的搭建思路:

  • 从平台化到中台化演化升级,可以从 业务能力可视化 、 业务能力在线配置化 的方法进行落地改造。
  • 开发建设一套 业务可视化平台 ,将业务平台中的代码流程可视化地 登记 到可视化系统中,按照一定的 连线规则 或 流程引擎规则 ,形成 业务流 。另外要保证可视化平台能够在业务代码修改后,实时感知更新相对应的流程。

可视化之后,业务逻辑可以直接在可视化平台上展现出来,业务方和产品经理不需要频繁和研发沟通确认需求,可以极大地减少沟通时间,有助于 业务快速落地 。

中台价值:当面对不断出现的新的业务场景和形态时(如电商里新出现的社区团购等),中台需要快速地复用已有能力,去满足业务新建站点或不断扩宽业务边界的诉求。

最后,聊聊关于 “道” 认知

不管是设计什么样的系统,在做技术方案前一定要充分了解业务背景、客户需求,否则很容易走偏。最终开发出来的系统不是客户想要的。

除了分析功能需求外,还要深入挖掘背后的非功能需求,如:面向的客户群体是哪些?有多少用户?一般什么时候访问系统?可能会做出哪些危害系统的操作?

有针对性的加固系统,如果是秒杀性质,要思考系统如何不被瞬间洪峰流量冲垮。提前准备降级方案,舍小保大。在保证系统的高并发输出外,也要兼顾系统的稳定性。

架构和历史也是一样, 分久必合合久必分,但在分分合合的过程中一定要结合业务现状来设计演化。 千万不要脱离业务,纯技术或心性自由发挥,这样很容易受挫。

最后,这个世界上没有什么是完美的,架构设计也是一样的, 比如拆分后带来的分布式事务、调用链路变长、模块变多,线上服务器增多,排查问题复杂,跨团队沟通成本增加等问题。 不管怎样,满足当前业务发展,且预留一定的扩展性,满足未来短期内的发展需要,这样的架构设计就是合格的架构设计。