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

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

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

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

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

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

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

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

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

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

拆分带来的好处：

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

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

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

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

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

拆分需注意事项：

• 最好是从顶层按业务及业务流程来垂直拆分，而不是纯技术视角维度。毕竟研发更多是跟着产品节奏来走

• 对于拆分得到的具体模块，可以按读写分离、在线离线分离、快慢分离、场景分离等方式做进一步的水平拆分。

• 随着业务的升级演化，不断调整策略，将易变与稳定、共性与非共性进行水平拆分

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

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

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

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

• 读业务：对于读的SLA（服务等级协议）要求非常高。但考虑到数据更改的频率低，通常采用数据尽量前置应对性能要求。

• 写业务：对写的SLA要求高，写业务的特点是写入的数据是用户私有的而不是共享的，同时写入不需要依赖已有的数据。对于 UGC 写业务，只要尽最大可能将数据存储下来即可。

• 扣减业务：与上面写业务类似，但是写入的内容要少很多，但是对单个数值的并发修改能力要求很高，可以考虑将大库存拆分N份小库存，从而降低并发写压力。

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

《五视图法》描述架构：

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

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

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

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

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

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

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

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

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

中台的搭建思路：

从平台化到中台化演化升级，可以从业务能力可视化、业务能力在线配置化的方法进行落地改造。

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

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

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

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

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

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

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