1、什么是建筑，建筑的本质是什么？你说的结构不一定和你理解的结构一样。因此，在讨论架构之前，我们先讨论一下架构的概念定义。概念是人们认识世界的基础，是用来交流的。如果对架构概念的理解不同，那么沟通自然不会顺畅。Linux有架构，MySQL有架构，JVM也有架构，业务系统使用Java开发，MySQL存储，运行在Linux上也有架构，我们应该重点关注哪一个？为了弄清楚以上问题，有必要梳理几个相关的、相似的概念：系统与子系统、模块与组件、框架与架构：1.系统与子系统系统：泛指一组相关的个体，根据一定的规则运作，一组能够完成个别组件无法独立完成的工作能力。子系统：也是由一组相关个体组成的系统，可能是更大系统的一部分。2.模块和组件都是系统的一部分，系统只是从不同的角度拆解。模块是逻辑单元，组件是物理单元。模块就是对系统进行逻辑分解，即分而治之，把复杂的问题简单化。模块的粒度可大可小，可以是一个系统、若干个子系统、某个服务、功能、类、方法、功能块等。组件可以包括应用服务、数据库、网络、物理机以及MQ、容器、Nginx等技术组件。3、Framework和架构Framework是组件实现的规范，如：MVC、MVP、MVVM等，是提供基本功能的产品，如开源框架：RubyonRails、Spring、Laravel、Django等.,可以直接使用或者在此基础上二次开发。框架是规范，架构是结构。我在这里重新定义架构：软件架构是指一个软件系统的顶层结构。架构是在现有资源约束下，经过系统思考、权衡利弊，最终形成清晰的系统骨架的最合理决策：包括子系统、模块、组件，以及它们之间的协作关系、约束规范、指导原则。它指导团队中每个人的想法一致。它涉及四个方面：系统的思考和合理的决策：如技术选型、解决方案等。清晰的系统骨架：清楚系统由哪些部分组成。系统协作关系：各个组件如何协作实现业务请求。约束规范和指导原则：保证系统有序、高效、稳定运行。因此，架构师具备了解业务、掌控全局、选择合适的技术、解决关键问题、指导研发实施的能力。架构的本质是对系统进行有序的重构，以适应当前的业务发展，并允许快速扩展。架构设计应该考虑什么样的系统？技术不会无缘无故的出来自己驱动发展，但是架构的发展和需求是由业务驱动的。架构设计完全是为了业务，需求比较复杂。非功能性需求在整个系统中占有重要地位。系统生命周期长，有扩展性要求。该系统基于组件或集成需求。业务流程再造需求。层次与分类架构分类可以细分为业务架构、应用架构、技术架构、代码架构、部署架构。业务架构是战略，应用架构是战术，技术架构是设备。其中，应用架构是承前启后的纽带。一方面承担业务架构的实现，另一方面影响技术选型。熟悉业务，形成业务架构，根据业务架构做出相应的应用架构，最后实现技术架构。如何根据当前需求选择合适的应用架构，以及如何面向未来并保证架构的平稳过渡，是软件开发者尤其是架构师需要深入思考的问题。1、业务架构（俯瞰架构）：包括业务规划、业务模块、业务流程，对整个系统的业务进行拆分，设计领域模型，将真实的业务转化为抽象的对象。没有最优的架构，只有最合适的架构。所有系统设计原则必须旨在解决业务问题。一个脱离实际业务的技术情怀架构，往往会让系统掉进一个大坑。任何不以业务为基础的异想天开的架构都是耍流氓。一切问题的前提都是弄清楚我们今天面临的业务量有多大，增长趋势是什么样的，而解决高并发的过程一定是一个循序渐进、循序渐进的过程。合理的结构可以提前1到2年预测业务发展。这样才能付出更合理的代价，换取真正达到技术引领业务增长的效果。看一下京东的业务架构（网上分享的）：2.应用架构（段架构，也叫逻辑架构图）：从硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的。业务架构的每一部分都有应用程序架构。类似于：应用架构：应用作为一个可独立部署的单元，为系统定义了清晰的边界，深刻影响着系统功能组织、代码开发、部署、运维等各个环节。如何分工合作。这里所谓的应用是指各个逻辑模块或子系统。应用架构图中有两个关键点：①．职责分工：明确应用（各个逻辑模块或子系统）边界、逻辑分层、子系统和模块定义。重点班。②.职责之间的协作：接口协议：应用程序对外输出的接口。协作关系：应用程序之间的调用关系。应用分层有两种方式：一种是水平划分（horizo??ntal），按照功能处理的先后顺序来划分应用，比如将系统划分为web前端/中间服务/后台任务，这是针对业务的划分深度。另一种是垂直划分（vertical），根据不同的业务类型划分应用。比如进销存系统可以拆分成三个独立的应用，这是对业务广度的划分。应用集成反映了应用如何协作共同完成复杂的业务用例，主要体现在应用之间的通信机制和数据格式上。通信机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/Binary等。应用的划分偏向业务，反映业务架构，而组合应用偏向技术，影响技术架构。分离降低了业务复杂度，使系统更加有序，而组合则增加了技术复杂度，使系统更加无序。应用架构的本质是通过系统拆分来平衡业务和技术的复杂性，从而保证系统的完整性。系统采用什么样的应用架构受业务复杂度的影响，包括企业发展阶段和业务特点；同时受技术复杂度的影响，包括IT技术发展阶段、内部技术人员水平等。业务复杂（包括业务量大）必然带来技术复杂。应用架构的目标是在解决业务复杂性的同时，避免技术过于复杂，保证业务架构的落地。3.数据架构数据架构指导数据库的设计。不仅要考虑开发中涉及的数据库和实体模型，还要考虑物理架构中数据存储的设计。4.代码架构（也称开发架构）：子系统代码架构主要为开发者提供实践指导。如果代码架构设计不足，会影响整体架构设计。比如公司内部不同的开发团队使用不同的技术栈或组件，这样一来，公司的整体架构设计就会失控。代码架构的主要定义：①．代码单元：配置设计框架、类库。②.代码单元组织：编码规范、编码约定。项目模块划分顶层文件结构设计，如mvc设计。依赖关系5.技术架构技术架构：确定组成应用系统的实际运行组件（lvs、nginx、tomcat、php-fpm等），这些运行组件之间的关系，以及部署到硬件上的策略。技术架构主要考虑系统的非功能特性，从系统层面把握系统的高可用、高性能、扩展性、安全性、可扩展性、简洁性。系统架构的设计要求架构师对软硬件的功能和性能有很好的了解，这也是架构设计工作中难度最大的任务。6.部署拓扑架构图（实际物理架构图）：拓扑架构，包括架构中部署了多少个节点，节点之间的关系，服务器的高可用性，网络接口和协议等，决定了应用程序如何运行，运行性能、可维护性和可扩展性是所有架构的基础。这个数字主要是运维工程师主要关心的。物理架构主要考虑硬件选择和拓扑、软件到硬件的映射以及软件和硬件的交互。3.架构层次我们用金字塔的架构层次来说明。上层包括下层：系统层：即整个系统中各个部分之间的关??系以及如何治理：分层应用层：即单个应用的整体架构，以及它与系统的关系Relationships模块级：指应用程序内部的模块架构，如代码模块化、数据和状态管理等。代码级：即从代码层面保证架构的实现。战略设计和战术设计基于架构金字塔，我们将系统架构的战略设计和战术设计完美结合：战略设计：业务架构用于指导架构师如何设计系统架构。战术设计：应根据业务架构设计应用架构。战术实施：应用架构确定后，就是技术选型。4、应用架构的演进业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适应业务架构，与业务架构一起演进。同时，应用架构依赖于技术架构最终落地。架构演进路径：单体应用→分布式应用服务化→微服务1.单体应用企业一开始的业务比较简单，只应用某个简单的场景。车身应用可以满足要求。典型的三层架构，前端（Web/移动端）+中间业务逻辑层+数据库层。这是一个典型的JavaSpringMVC或PythonDjango框架应用程序。其架构图如下：单体应用的非功能需求：性能需求：使用缓存提升性能并发需求：使用集群提升并发读写分离：使用反向代理和CDN加速使用数据库读写分离具有分布式文件和分布式数据库单体架构的应用程序更易于部署和测试。在项目的早期阶段，单体应用程序可以很好地运行。但是，随着需求不断增加，越来越多的人加入开发团队，代码库也迅速膨胀。慢慢地，单体应用越来越臃肿，可维护性和灵活性逐渐下降，维护成本越来越高。以下是单体架构应用的一些缺点：复杂度高：以一个百万行级别的单体应用为例，整个项目包含了很多模块，模块边界模糊，依赖不明确，代码质量参差不齐，乱七八糟地堆在一起。可以想象整个工程非常复杂。每次修改代码，我都感到毛骨悚然。即使增加一个简单的功能或修改一个bug也会带来隐藏的缺陷。技术债务：随着时间的推移，随着需求的变化和人员的变化，应用程序的技术债务会累积起来。“Ifitdoesn'tbreak,don'tfixit”，这种思想在软件开发中很普遍，在单体应用中更是如此。使用过的系统设计或代码很难修改，因为应用程序中的其他模块可能会以意想不到的方式使用它。低部署频率：随着代码的增长，构建和部署时间也会增加。在单体应用程序中，每个功能更改或缺陷修复都将导致需要重新部署整个应用程序。全量部署方式耗时长、影响范围大、风险高，使得单体应用项目上线部署频率较低。部署频率低导致两次发布之间有大量的功能变更和缺陷修复，错误率比较高。可靠性差：一个应用程序的bug，比如死循环、内存溢出等，都可能导致整个应用程序崩溃。可扩展性有限：单个应用只能作为一个整体进行扩展，不能根据业务模块的需要进行扩展。例如，应用程序中的某些模块是计算密集型的，需要强大的CPU；有些模块是IO密集型的，需要更大的内存。由于这些模块一起部署，因此必须在硬件选择上做出妥协。技术创新的障碍：单体应用往往使用统一的技术平台或解决方案来解决所有问题。团队的每个成员都必须使用相同的开发语言和框架。引入新框架或新技术平台将非常困难。2、分布式随着业务的深入，业务需要的产品功能越来越多，各个业务模块的逻辑也越来越复杂。业务的深度和广度增加，使得单体应用越来越臃肿。可维护性和灵活性逐渐降低，增加新功能的开发周期越来越长，维护成本越来越高。这时候就需要按照业务功能模块对系统进行拆分，将各个模块变成一个分布式系统。业务模块分别部署在不同的服务器上，各业务模块之间的数据交互通过接口进行。与单体架构相比，该架构提供了负载均衡能力，大大提高了系统负载能力，解决了网站的高并发需求。此外，它还具有以下特点：降低耦合：将模块拆分，使用接口进行通信，降低模块之间的耦合度。职责清晰：将项目拆分成多个子项目，不同的团队负责不同的子项目。易于扩展：增加功能时，只需再增加一个子项，调用其他系统的接口即可。部署方便：分布式部署灵活。提高代码的复用性：比如Service层如果不采用分布式rest服务架构，那么手机Wap商城、微信商城、PC、Android、iOS各端都要写一个Service层逻辑，这样需要大量的开发。很难一起维护和升级。这时可以采用分布式rest服务的方式，共享一个服务层。缺点：系统间交互需要远程通信，接口开发增加工作量，但利大于弊。3.微服务所遵循的业务模型越来越复杂。订单、产品、库存、价格等每个模块都非常深入。还有大量的价格促销活动。这些规则非常复杂并且容易相互冲突。需要将分散在各个业务中的价格逻辑统一管理，并以基础价格服务的形式透明地提供给上层应用，成为面向服务的微内核。架构，即微服务。微服务的特点：易于开发和维护：微服务只关注特定的业务功能，业务清晰，代码量小。开发和维护单个微服务相对简单。整个应用是由几个微服务构建而成的，所以整个应用会保持在一个可控的状态。单个微服务启动速度更快：单个微服务的代码更少，因此启动速度会更快。本地修改部署方便：只要修改单个应用，整个应用都要重新部署。微服务解决了这个问题。一般来说，修改一个微服务，只需要重新部署服务即可。不受限制的技术栈：在微服务架构中，可以根据项目业务和团队的特点，合理选择技术栈。比如一些服务可以使用关系型数据库MySQL；一些微服务可以使用Neo4j来满足图形计算需求；甚至有些微服务可以用Java开发，有些微服务可以用Node.js开发。虽然微服务有很大的吸引力，但它不是免费的午餐，使用它是有代价的。使用微服务架构的挑战。更高的运维要求：更多的业务意味着更多的运维投入。在单体架构中，只需要保证一个应用程序正常运行。在微服务中，需要保证几十个甚至上百个服务的正常运行和协同，这给运维带来了很大的挑战。分布式的内在复杂性：你用微服务构建的是一个分布式系统。对于分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。接口调整成本高：微服务通过接口进行通信。如果修改了某个微服务的API，可能所有使用该接口的微服务都需要调整。重复劳动：很多服务可能使用同一个功能，但是这个功能还没有被分解成一个微服务。这时候每个服务都可能开发这个功能，造成代码重复。虽然可以使用共享库来解决这个问题（比如可以把这个功能封装成一个公共组件，供需要这个功能的微服务引用），但是共享库不一定能在多语言环境下工作。5、衡量架构的合理性架构为业务服务。没有最优的架构，只有最合适的架构。架构的合理性总是以效率、稳定性和安全性为目标来衡量的。合理的架构设计：1.业务需求的视角，可以解决当前的业务需求和问题高效的完成业务需求：可以用一种优雅的、可重用的方式解决当前所有的业务问题这种方式满足业务，让业务的每一次演进，它不会导致架构发生翻天覆地的变化。2.从非业务需求的角度①。稳定。指标：高可用性：尽可能的提高软件的可用性，我想每个运维人员都不愿意看到自己的工作不能正常进行。黑盒和白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方法逐步推进。②.效率指标：文档化：不管是整个生命周期的全部还是部分，文档化都要做好。变更来源包括但不限于BUG和需求。可扩展性：软件的设计秉承低耦合的理念，注重在合理的地方进行抽象。方便功能变更、新增、应用技术的迭代，支持架构的及时重构。高复用：为了避免重复劳动和降低成本，我们希望能够复用以前的代码和设计。这是对架构环境的最大依赖。③.安全指标安全性：机构运行过程中产生的数据具有商业价值，保障数据安全也是当务之急。为了避免XX门等丑闻。加密、https等常用手段6.常见的架构误区高高在上未能落地，遗漏关键约束和非功能需求，为虚无的未来买单，过度设计和过早做出关键决策努力，缺乏具有前瞻性的架构设计，还要考虑系统的可测试性。架构设计不应试图一步到位。常见误区误区一——架构是架构师专门干的，业务开发人员不用关注：架构再好，终究需要代码落地，而且组织越大，越多着陆困难。不仅是系统架构，每个解决方案、每个项目也有自己的架构，比如分层、设计模式等，如果每一块砖都不够坚固，整个系统还是有倒塌的风险。所谓“千里堤崩于蚁穴”。误区二——架构师确认了架构蓝图后任务就结束了：架构不是“空中楼阁”，最终会落地，但架构师怎么知道“地”在哪？根本不深入前线？我怎么能稳稳地跌倒。误区三——没有完美的架构设计就没有开始工作：世界上没有最好的架构，只有最合适的架构，不要试图一步到位。我们需要的不是一下子造车，而是从独轮车→自行车→摩托车，最后到汽车。想象一个产品只能在2年后生产。市场还存在吗？误区四——过度设计徒劳无功：在创业公司的早期阶段，很难把握业务场景和需求边界。产品需要快速迭代变现，需求更新频繁。这个时候需要的是快速实施。以后的扩展不要想太多，说不定功能就完了，效果不好就白搭了。如果业务模型和应用场景的边界比较清晰，就需要适当考虑未来的可扩展性设计。误区五——盲目追随大公司的解决方案：由于大公司巨大成功的光环效应，加上从大公司挖来的技术专家的影响，网站上讨论架构决策时最有说服力的一句话是Itbecome“淘宝就是这么干的”或者“腾讯就是这么干的”。大公司的经验和成功模式很重要，值得借鉴，但如果因此而盲目服从，就会失去坚持自己的勇气，迟早会在架构进化的道路上迷失方向。误区六——为了技术而技术：技术是为业务而存在的，否则就没有意义。在技??术选型和架构设计上，如果脱离网站业务发展的实际，一味追求时髦的新技术，可能会把技术开发引入坎坷之路，架构之路会越来越艰难。实现的成本、时间、人员等方面都要综合考虑，理想和现实需要做出妥协。七、架构知识体系1、架构演化初期：LAMP，部署在一台服务器上应用服务器和数据服务器分离使用缓存提高性能使用集群提高并发数据库读写分离使用反向代理和CDN加速使用分布式文件和分布式数据库业务拆分分布式服务2.架构模式分层：横向分层：应用层、服务层、数据层切分：纵向切分：拆分功能和服务分布式分布式应用和服务分布式静态资源分布数据和存储分布式计算集群：提高并发性和可用性缓存：优化系统性能CD??N方向代理访问资源本地缓存分布式缓存异步：降低系统耦合提供系统可用性，加快响应冗余：冷备和热备，保证系统的可用性自动化：发布、测试、部署、监控、告警、故障转移、故障恢复安全性：3.架构核心要素高性能：网站的灵魂性能测试前端优化应用优化数据库优化可用性：保证服务器不宕机，一般通过备份服务器的冗余部署来完成负载均衡：主要围绕功能需求，响应业务扩展，快速响应业务变化。是否实现开闭原则，系统耦合取决于分布式消息服务安全：网站的各种攻击，各种漏洞是否被堵住，架构是否能实现限流功能，防止ddos攻击。xss攻击，sql注入，csr攻击，web防火墙漏洞，安全漏洞，ssl8.架构书籍推荐1.《大型网站技术架构：核心原理与案例分析》这是较早的一本系统介绍大型网站技术架构的书籍。通俗易懂，充满智慧，即使你之前没有接触过网站开发，通读前几章，你也可以快速掌握常见的网站技术架构及其应用场景。非常好。2.《亿级流量网站架构核心技术》相对于《大型网站技术架构》的高层计划，凯涛的书《亿级流量网站架构核心技术》实现了细节。网站架构中的各种常用技术，如缓存、队列、线程池、代理等，一应俱全。它在这里，并带有核心代码。甚至还有Nginx的配置！如果你想在实现高流量网站时寻找参考技术和代码，这本书是最合适的。3.《架构即未来》这是一本“神书”。它超越了具体的技术层面，着重于分析架构问题的根源，帮助我们弄清楚如何管理、领导、组织和配置团队。4.《分布式服务架构：原理、设计与实战》本书全面介绍了分布式服务架构的原理和设计，并结合作者在微服务架构实现过程中的实践经验，总结出保证在线服务健康可靠的最佳方案。这种架构级别的、实用的重量级作品。5.《聊聊架构》这是一本关于建筑的魔法书。从架构的起源，从业务的拆分，到架构的目的，架构师的作用，架构师如何实现架构……强烈推荐。但是，对于没有架构实践经验的朋友来说，可能会觉得这本书比较空洞，概念多，实战少。但如果你有过一两个项目的架构经验，你就会对书中所讨论的架构概念深表认同。6.《软件架构师的12项修炼》很多时候所谓的“技术玻璃天花板”其实只是缺乏软技能而已。这些技能是可以学习的，知识的不足可以通过决定努力改变来弥补。
