软件架构跟盖楼有异曲同工之妙。首先建筑师(软件行业:称之为架构师)在图纸上把大楼外观、主体结构、材料工艺、施工流程等设计好。施工队根据图纸,打好地基,并开始建设能满足抗地震、抗台风、抗沉降(高并发、高性能、高可用)等必备条件的大楼主体结构,然后再浇筑墙体、封顶、室内装饰。
创新互联是工信部颁发资质IDC服务器商,为用户提供优质的四川主机托管服务
建筑师对主体结构的设计,在软件工程中便是架构设计;大楼的主体结构在软件工程中就是架构,它主要处理软件的子系统和组件的开发和部署方式、技术指标和规范,以及它们之间的相互关系。
很多人多架构师可能有误解,认为只是做了好多很炫的PPT,各种的架构图、UML图、流程图、模块拆分、组件拆分、部署图等,感觉完全是纸上谈兵,一行代码没写,夸夸其谈。
其实不然,古代带兵打仗,讲究兵马未动粮草先行,正式开拔前一定要先把准备工作做好。毕竟做设计比写代码推翻重来的成本要低得多。
业务理解转化能力
思维抽象能力
软件建模能力
高并发、高性能、高可用的分布式系统架构设计能力
前沿技术选型把控能力
系统重构能力
快速学习能力
此外,还要懂分布式缓存、消息队列、负载均衡、数据库、NoSQL、搜索、RPC、容器、分库分表、注册中心、分布式配置、链路跟踪、服务治理、系统监控、微服务等等。此处省略1万字。
兵法有云,“战略上藐视敌人,战术上重视敌人!”
有一个自信的意识,意味着你一只脚已经迈入成功的大门。
低头走路,时不时也要抬头看天。要想做好、做精一件事,不能只局限某一个细节点,要做到既有点也有面。放眼全局,才能更好验证细节做的好不好,在整体架构中是否合理。否则,很容易导致 木桶效应
世上没有无缘无故的爱,也没有无缘无故的恨,一切皆有因果。那为什么要做拆分呢?
人类大脑神经信号传递靠的是离子,通过透过钠与钾等离子来传输,其速度被限制在化学扩散的速率,所以我们的大脑内大部分神经信号是以约 30m/s 的速度传播。
由于人脑处理问题的能力是有限的,当面对复杂问题时,会主动去寻找一些方法提升效率(这也是人与动物的最大区别,人具有思考能力)。神器就是 拆分 ,将复杂问题拆解为多个相对简单的小问题。分而治之、各个击破,这样做极大地提高了解决复杂问题的可能性和效率。
简单归纳:应用拆分、服务拆分、数据拆分、应用解耦。
比如常见的电商领域,当用户发展到一定规模后,会拆分成一系列的业务子域:商户、商品、库存、权限、订单、支付、履约、结算、售后、财务、会员、营销、采购、仓储等众多模块,项目实战中可以结合DDD,来帮助我们理清、划分各个子系统的边界。
需求不断叠加导致并行开发和上线时,通过拆分可以减少相互影响。
降低系统的复杂度,让研发人员适当聚焦,提升专业度。
弱化各个模块间的耦合性,降低整体系统风险
大家分工更加明确,各司其职,工作效率更高
拆分微服务后,无状态化部署,更容易横向扩容,方便我们有针对性补齐某块性能短板,提升整体系统吞吐量
顶层按业务及业务流程来垂直拆分
,而不是纯技术视角维度。毕竟研发更多是跟着产品节奏来走读写分离
、 在线离线分离
、 快慢分离
、 场景分离
等方式做进一步的水平拆分。易变与稳定
、 共性与非共性
进行水平拆分拆分是架构设计大型复杂系统的第一步,对降低系统复杂性有着决定性的意义,它也是架构师的必备技能之一。
认知很重要,认知很重要,认知真的重要,重要的话说三遍。大家应该听过一个成语:“一通百通”,出自明·吴承恩《西游记》。
原文:这猴王也是他一窍通时百窍通,当时习了口诀,自习自练,将七十二般变化,都学成了。
翻译过来:一个主要的弄通了,其他的自然也都会弄通。
相信很多人都面试过别人,或者被别人面试过。大家有没有发现一个现象,简历中项目经验很重要,但是有时想招到一个对口业务的人真的很难,这时考量标准就会转变为对求职者的基础技术能力(比如算法)、表达能力、归纳能力、抽象思维能力。正所谓“一通百通”,你在一个行业积累了成功的项目经验,那么再换一个赛道也不会有问题。
现如今,互联网行业快速发展,各种垂直化业务如雨后春笋般涌现出来,腾讯的IM即时通讯、阿里巴巴的电商、滴滴的打车、百度的搜索、饿了么的O2O外卖。
看似形态各异,但细细一想,是不是也可以归纳为:读业务、写业务、扣减业务。
数据尽量前置
应对性能要求。写业务的特点是写入的数据是用户私有的而不是共享的
,同时写入不需要依赖已有的数据。对于 UGC 写业务,只要尽最大可能将数据存储下来即可。可以考虑将大库存拆分N份小库存,从而降低并发写压力。
假如你在微博工作做,知道微博的热搜事件(读事件)如何架构,缓存的热点问题如何解决。那么同样切到电商业务,对一些爆款商品的展示,我们也是有很多 共性化
的技术方案可以参考,我们要学会举一反三。
为什么架构师都喜欢画图呢,一图胜千言啊。人的生理结构更容易接受视觉型知识输入。
《五视图法》描述架构:
逻辑视图:对应逻辑架构,主要关注功能需求,以及系统职责和行为的划分。逻辑视图不仅包括用户可见的功能,还包括相应的辅助功能。比如秒杀系统中的活动场次切换、商品列表、用户登录、活动管理、后台权限等功能
开发视图:对应开发架构,主要关注系统开发过程中的质量属性。它包括软件源码的组织方式、引入开源框架、配置方式、编译打包方式以及与第三方包的依赖关系等。
运行视图:对应运行架构,主要关注软件运行过程中的质量属性,它包括进程、线程、协程、对象之间的并发、同步、通信的问题等。
物理视图:对应物理架构,主要关注安装和部署需求。它包括软件运行时的系统、网络、服务器等基础设施和相关配置,以及如何利用基础设施来实现应用程序的高可用、可伸缩等。
数据视图:对应数据架构,通常用 E-R 图(Entity Relationship Diagram,实体-联系图)表示。主要关注数据需求,它包括数据的格式、属性、关系等。
随着公司业务的扩大,系统也会经历一个演化过程。大致分为这么几个阶段:烟囱式架构 --> 平台化 --> 中台化
就像人一样,每个阶段也都有自己的优点和不足,业务早期追求速度,讲究快速落地,抢占市场,时间就是生命,我们可能采用集中式架构,系统快速落地,后期在慢慢优化、架构升级。
早期的系统很多都是烟囱式架构,自上而下一体化,存在大量的模块重复,导致维护成本很高。另外模块割裂对业务也有很大影响,比如:会员模块,每个渠道都有自己的独立用户体系,用户登录网站系统时需要记住多套账号,体验较差。也不利于数据互通、共享,无法最大化发挥数据的价值。 此时,便有了从烟囱式架构朝着平台化演化。
中台的搭建思路:
业务能力可视化
、 业务能力在线配置化
的方法进行落地改造。业务可视化平台
,将业务平台中的代码流程可视化地 登记
到可视化系统中,按照一定的 连线规则
或 流程引擎规则
,形成 业务流
。另外要保证可视化平台能够在业务代码修改后,实时感知更新相对应的流程。可视化之后,业务逻辑可以直接在可视化平台上展现出来,业务方和产品经理不需要频繁和研发沟通确认需求,可以极大地减少沟通时间,有助于 业务快速落地
。
中台价值:当面对不断出现的新的业务场景和形态时(如电商里新出现的社区团购等),中台需要快速地复用已有能力,去满足业务新建站点或不断扩宽业务边界的诉求。
不管是设计什么样的系统,在做技术方案前一定要充分了解业务背景、客户需求,否则很容易走偏。最终开发出来的系统不是客户想要的。
除了分析功能需求外,还要深入挖掘背后的非功能需求,如:面向的客户群体是哪些?有多少用户?一般什么时候访问系统?可能会做出哪些危害系统的操作?
有针对性的加固系统,如果是秒杀性质,要思考系统如何不被瞬间洪峰流量冲垮。提前准备降级方案,舍小保大。在保证系统的高并发输出外,也要兼顾系统的稳定性。
架构和历史也是一样, 分久必合合久必分,但在分分合合的过程中一定要结合业务现状来设计演化。
千万不要脱离业务,纯技术或心性自由发挥,这样很容易受挫。
最后,这个世界上没有什么是完美的,架构设计也是一样的, 比如拆分后带来的分布式事务、调用链路变长、模块变多,线上服务器增多,排查问题复杂,跨团队沟通成本增加等问题。
不管怎样,满足当前业务发展,且预留一定的扩展性,满足未来短期内的发展需要,这样的架构设计就是合格的架构设计。
分享文章:如何成为一名优秀的架构师?你需要吸取这些经验
URL地址:http://www.36103.cn/qtweb/news16/8166.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联