软件架构跟改楼差不多。首先，建筑师（软件行业：称为建筑师）在图纸上设计建筑物的外观、主体结构、材料工艺、施工工艺等。施工团队根据图纸打好地基，开始搭建能够满足抗震、抗台风、抗沉降（高并发、高性能、高可用）等必要条件的大楼主体结构，然后浇筑墙壁、屋顶和室内。装饰。架构师对主体结构的设计是软件工程中的架构设计；建筑的主体结构是软件工程中的体系结构，主要处理软件子系统和组件的开发部署方法、技术指标和规范，以及它们之间的相互关系。很多架构师可能会误会，就是做了一大堆眼花缭乱的PPT，各种架构图，UML图，流程图，模块拆分，组件拆分，部署图等等，感觉都是纸上谈兵，一行代码没有写，自夸。事实上，并非如此。古时带兵打仗，先看兵马，后运粮草。正式出发前，一定要做好各项准备工作。毕竟做设计的成本要比写代码推翻的成本低很多。成为一名优秀的架构师需要满足很多条件：业务理解能力转化能力思维抽象能力软件建模能力高并发、高性能、高可用分布式系统架构设计能力前沿技术选型与管控能力快速系统重构能力除了学习能力，还需要了解分布式缓存、消息队列、负载均衡、数据库、NoSQL、搜索、RPC、容器、分库分表、注册中心、分布式配置、链路跟踪、服务治理、系统监控、微服务等等。这里省略一万字。..兵法上有句话叫“战略上藐视敌人，战术上重视敌人！”有了自信感，就意味着你已经用一只脚踏进了成功之门。低着头走路，不时抬头看看天空。要想做好一件事情，做好一件事，不能只局限于某个细节，而要做到点和面兼顾。只有看大局，才能更好地验证细节是否做好，在整体结构上是否合理。否则容易造成木桶效应。如何做好架构设计，有哪些经验可以借鉴？下面简单学习一下下一步，“拆分”，降低架构的复杂度。世上没有无缘无故的爱，也没有无缘无故的恨。一切发生的原因。那为什么要拆分呢？人脑中神经信号的传递依赖于离子，离子通过钠钾等离子体传递，其速度受限于化学扩散的速度，所以我们大脑中的神经信号大部分以30m左右的速度传播/秒。由于人脑处理问题的能力是有限的，当面对复杂的问题时，会积极寻找提高效率的方法（这也是人与动物最大的区别，人有思考的能力）。神器就是拆分，将复杂的问题拆分成多个相对简单的小问题。分而治之，一一分解，大大提高了解决复杂问题的可能性和效率。简单总结：应用拆分、服务拆分、数据拆分、应用解耦。比如常见的电商领域，当用户成长到一定规模后，会被拆分成一系列的业务子域：商户、商品、库存、权限、订单、支付、履约、结算、售后、财务、会员、营销、采购、仓储等诸多模块，DDD可以在实际项目中结合使用，帮助我们理清和划分各个子系统的边界。拆分的好处：当需求不断叠加导致并行开发和上线时，可以通过拆分来减少相互影响。降低系统复杂度，让研发人员适当专注，提升专业度。弱化模块之间的耦合，降低整个系统的风险。分工更加明确，各司其职。工作效率更高。是性能上的短板，提高了系统的整体吞吐量。拆分时需要注意的地方：最好从顶层根据业务和业务流程进行垂直拆分，而不是单纯从技术角度进行拆分。毕竟研发是跟着产品的节奏走的。对于拆分得到的具体模块，可以通过读写分离、在线离线分离、快慢分离、场景分离等方式进一步横向拆分。随着业务的升级演进，不断调整策略，横向拆分波动与稳定、共性与非共性。拆分是大型复杂系统架构设计的第一步。对降低系统的复杂度具有决定性的意义。也是架构师必备的技能之一。2.认知抽象，架构模式具有普遍认知很重要，认知很重要，认知真的很重要，重要的话说三遍。你应该听过一句成语：“一师一师”，出自明吴承恩♂。原文：这孙悟空也是一知半解，通晓一切。那时他学了口诀，自学自修，七十二变全学会了。翻译：主要的理解了，其他的自然也就理解了。相信很多人都采访过别人，或者被别人采访过。大家有没有发现一个现象，简历中的项目经验很重要，但有时候真的很难招到一个对口业务的人。这时候考量标准就会转变为求职者的基本技术能力（比如算法）和表达能力。能力，归纳能力，抽象思维能力。俗话说“一个高手，都是高手”，如果你在一个行业积累了成功的项目经验，换到另一个赛道也不成问题。如今，随着互联网行业的快速发展，各种垂直业务如雨后春笋般涌现，如腾讯的IM即时通讯、阿里巴巴的电商、滴滴的打车、百度的搜索、饿了么的O2O外卖等。看似有不同的形式，但仔细想想，是不是也可以归纳为：读业务、写业务、扣业务。阅读业务：对阅读的SLA（服务水平协议）要求非常高。但考虑到数据变化频率较低，通常会尽量使用数据来满足性能要求。写业务：写的SLA要求高。写入业务的特点是写入的数据对用户是私有的而不是共享的，写入不需要依赖已有的数据。对于UGC写业务，尽可能的存储数据即可。扣除业务：与上面的写入业务类似，但是写入的内容少了很多，但是对单个值的并发修改要求非常高。可以考虑将大库存拆分成N个小库存，以减轻并发写入的压力。如果你在微博上工作，你就知道微博的热搜事件（阅读事件）是如何构成的，以及如何解决缓存热点问题。那么在电商业务中，对于一些热门商品的展示，我们也有很多通用的技术方案可以参考，一定要学会举一反三。3、一图胜千言。为什么建筑师喜欢画各种类型的图？一张图片胜过千言万语。人类的生理结构更容易接受视觉知识输入。《五视图法》架构描述：LogicalView：对应逻辑架构，主要关注功能需求，以及系统职责和行为的划分。逻辑视图不仅包括用户可见的功能，还包括相应的辅助功能。例如秒杀系统中的事件切换、商品列表、用户登录、事件管理、后台权限等功能开发视图：对应开发架构，在系统开发过程中主要关注质量属性。包括软件源码的组织、开源框架的引入、配置方式、编译打包方式、与第三方包的依赖关系等。运行视图：对应运行架构，主要关注软件运行过程中的质量属性，包括进程、线程、协程、并发、同步、对象间的通信问题。物理视图：对应物理架构，侧重于安装部署需求。包括软件运行时的系统、网络、服务器等基础设施和相关配置，以及如何利用基础设施实现应用程序的高可用性和可扩展性。数据视图：对应数据结构，通常用E-R图（EntityRelationshipDiagram，实体关系图）表示。主要关注数据需求，包括数据的格式、属性、关系等。4.系统是进化的，初期不要推翻。随着公司业务的扩大，系统也将经历一个演进过程。大致可以分为几个阶段：烟囱结构-->平台化-->中台化就像人一样，每个阶段都有自己的优势和劣势。业务前期追求速度，注重快速落地，抢占市场，时间就是生命，我们可以采用中心化架构，系统快速上线，后期逐步优化升级系统.很多早期的系统都是烟囱式架构，自上而下集成，存在大量模块重复，导致维护成本高。另外，模块的划分对业务也有很大的影响。比如在会员模块中，每个频道都有自己独立的用户体系。用户登录网站系统时需要记住多组账号，体验较差。也不利于数据的互通共享，无法实现数据价值的最大化。这个时候，就出现了从烟囱架构到平台的演进。平台化就是从减少技术重复的角度，将重复的模块进行整合，从而提高效率。集中化，又称企业级能力复用平台。从业务复用的角度，进一步提高业务执行效率。中台建设思路：从平台到中台的演进升级，可以从业务能力可视化、业务能力在线配置等方式进行改造。开发搭建业务可视化平台，将业务平台中的代码流程可视化注册到可视化系统中，按照一定的连接规则或流程引擎规则形成业务流。另外，需要保证可视化平台在业务代码修改后能够实时感知并更新相应的流程。可视化后，业务逻辑可以直接展示在可视化平台上。业务方和产品经理无需频繁与研发沟通确认需求，可以大大减少沟通时间，帮助业务快速落地。中台的价值：当面对不断涌现的新业务场景和新业态（如电商中的新社区团购等）时，中台需要快速复用现有能力，以满足新业务站点或新业务站点的需求不断扩展业务边界的诉求。最后，谈谈对“道”的认识。不管你设计什么样的系统，在做技术方案之前，一定要充分了解业务背景和客户需求，否则很容易误入歧途。由此产生的系统不是客户想要的。除了分析功能需求，还需要深入挖掘其背后的非功能需求，比如：目标客户群是谁？有多少用户？您通常什么时候访问系统？可能会采取哪些措施来损害系统？有针对性的加固系统，如果是尖峰性质的，就要考虑系统如何才不会被瞬时洪峰流量淹没。提前准备保级方案，舍小保大。除了保证系统的高并发输出外，还要兼顾系统的稳定性。结构和历史也是如此。远隔必合，远隔必分。但在分分合合的过程中，设计演进必须结合当前的业务情况。不要脱离商业、纯技术或头脑，很容易受挫。最后，这个世界上没有什么是完美的，架构设计都是一样的，比如拆分后的分布式事务、更长的调用链路、更多的模块、更多的在线服务器、复杂的故障排除、跨团队沟通成本增加等。无论如何，满足当前业务发展并保留一定的可扩展性以满足未来短期发展需求的架构设计，才是合格的架构设计。
