title: 人人都是架构师？！谈何容易！

人人都是架构师？！谈何容易！

作者：Tom哥
公众号：微观技术
博客：https://offercome.cn
人生理念：知道的越多，不知道的越多，努力去学

大家好，我是Tom哥。

软件架构跟盖楼有异曲同工之妙。

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

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

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

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

一名优秀的架构需要具备很多能力

业务理解转化能力
思维抽象能力
软件建模能力
高并发、高性能、高可用的分布式系统架构设计能力
前沿技术选型把控能力
系统重构能力
快速学习能力
此外，还要懂分布式缓存、消息队列、负载均衡、数据库、NoSQL、搜索、RPC、容器、分库分表、注册中心、分布式配置、链路跟踪、服务治理、系统监控、微服务等等。此处省略1万字。。。

兵法有云，“战略上藐视敌人，战术上重视敌人！”
有一个自信的意识，意味着你一只脚已经迈入成功的大门。

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

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

“拆分” ，降低架构复杂度

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

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

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

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

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

拆分带来的好处：

需求不断叠加导致并行开发和上线时，通过拆分可以减少相互影响。
降低系统的复杂度，让研发人员适当聚焦，提升专业度。
弱化各个模块间的耦合性，降低整体系统风险
大家分工更加明确，各司其职，工作效率更高
拆分微服务后，无状态化部署，更容易横向扩容，方便我们有针对性补齐某块性能短板，提升整体系统吞吐量

拆分需注意事项：

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

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

认知抽象，架构模式有通用性

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

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

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

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

现如今，互联网行业快速发展，各种垂直化业务如雨后春笋般涌现出来，腾讯的IM即时通讯、阿里巴巴的电商、滴滴的打车、百度的搜索、饿了么的O2O外卖。看似形态各异，但细细一想，是不是也可以归纳为：读业务、写业务、扣减业务。

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

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

一图胜千言，画各种类型图

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

《五视图法》描述架构：

逻辑视图：对应逻辑架构，主要关注功能需求，以及系统职责和行为的划分。逻辑视图不仅包括用户可见的功能，还包括相应的辅助功能。比如秒杀系统中的活动场次切换、商品列表、用户登录、活动管理、后台权限等功能
开发视图：对应开发架构，主要关注系统开发过程中的质量属性。它包括软件源码的组织方式、引入开源框架、配置方式、编译打包方式以及与第三方包的依赖关系等。
运行视图：对应运行架构，主要关注软件运行过程中的质量属性，它包括进程、线程、协程、对象之间的并发、同步、通信的问题等。
物理视图：对应物理架构，主要关注安装和部署需求。它包括软件运行时的系统、网络、服务器等基础设施和相关配置，以及如何利用基础设施来实现应用程序的高可用、可伸缩等。
数据视图：对应数据架构，通常用 E-R 图（Entity Relationship Diagram，实体-联系图）表示。主要关注数据需求，它包括数据的格式、属性、关系等。

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

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

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

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

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

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

中台的搭建思路：

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

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

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

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

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

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

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

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

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

人人都是架构师？！谈何容易！.md 12 KB لینک دائمی تاريخچه خام