发现一篇关于架构非常好的文章，特此转载分享给大家。1.架构设计在架构设计过程中，我们会根据需要进行不同的架构设计，在设计中需要涉及架构设计的某些核心要素。2.架构设计概述架构设计是从业务需求到系统实现的转换，是对需求进一步深入分析的过程，用于确定系统中实体之间的关系，以及形式和实体的功能。从业务需求到系统实现的不同需求，架构可以分为业务架构、应用架构、数据架构、技术架构。下面以电子商务系统为例进行架构设计。3.业务架构业务架构是对业务需求的细化和抽象。它使用一套方法论来划分产品（项目）的需求所涉及的业务的业务边界。软件必须满足业务需求，否则就是空中楼阁。软件系统的业务复杂性可以通过从业务架构的角度划分工作接口来解决。例如，在建设电子商务网站时，需要明确划分商品分类、商品、订单、支付、退款等功能。不去考虑用什么技术开发，并发量是不是太大，或者在业务架构上选择什么。硬件种类等。这里简单的规划了电商系统的业务模块，按照业务架构不断细化模块，直到分解成代码流。对于软件开发来说，依靠业务架构，架构师和开发人员可以更清楚地看到系统的整体业务图景。架构师可以更方便地分析系统复杂度，分解业务逻辑，做好开发分工，如图5.1所示。业务架构是决定一个软件项目能否顺利开展的总纲。软件架构是业务架构在技术层面的映射。还要根据业务架构进行合理的分工。没有业务架构，做软件开发是盲目的。业务架构是需求和开发的交汇点。需求分析是否到位，功能开发是否达到预期目标，都是基于此。我们在工作中会遇到一些问题。比如研发人员说需求分析不到位，做需求的人员就会质疑需求怎么考虑到位，为什么开发出来的产品和用户想要的不一致。这些从根本上来说，都是因为业务架构没有梳理清楚，没有达成共识。从一个软件项目的角度来说，在项目前期做好业务架构设计，对于整个项目的发展有着重要的意义。例如，对于相对相似的业务系统，业务架构可能在粗粒度上是相同的，但在细化过程中是不同的。在做项目的时候，当手头有一个现成的系统，需要做一个有类似需求的项目时，可以先尝试用现成的系统覆盖新的项目，这样才能发挥最大的效益。想法能否实现，可以通过业务架构来衡量。如果没有业务架构，接下来的工作会很盲目。业务架构的设计原则如下。（一）业务平台化。◎业务平台相互独立，如交易平台、物流平台、支付平台、广告平台等◎基础业务下沉可复用，如用户、产品、品类、促销、时效等（2)核心业务与非核心业务分离。分离电子商务系统的核心业务和非核心业务，如主要交易服务和一般交易服务，精简核心业务（有利于稳定性），并使非核心业务多样化。(3)隔离不同类型的业务。◎交易平台的作用是让买卖双方签订交易合约，因此需要优先考虑高可用性，以便用户可以快速下单。◎性能业务对可用性要求不高，但要优先保证一致性。◎秒杀业务对高并发要求较高，应与常规业务分离。(4)区分主进程和辅助进程。需要了解电子商务系统的主要流程有哪些，在运行过程中优先保证主要流程的顺利完成；对于辅助进程，可以采用后台异步的方式，避免辅助进程的失败影响到主进程的失败。4.应用架构应用架构介于业务和技术之间。它是整个系统的总体架构。需要指出系统层次，系统开发的原则，以及系统各个层次的应用服务。如图5.2所示，系统分为表现层、业务流程层、服务层、服务构建层、数据层、集成层、数据架构层和服务治理层，描述了各层应用所提供的服务.拆分系统时，需要平衡业务和技术的复杂性，保证系统的完整性。系统采用什么样的应用架构受业务复杂度的影响，包括企业的发展阶段和业务特点；同时受技术复杂度的影响，包括IT技术的发展阶段和内部技术人员的水平。业务复杂（包括业务量大）必然带来技术复杂。应用架构的目标是在解决业务复杂性的同时，避免过于复杂的技术，保证业务架构的落地。应用架构的设计原则如下。(一)稳定◎一切以稳定为中心。◎结构尽量简单明了，追求小而美，不求大而全。◎不过度设计。(2)解耦◎将稳定部分与可变部分分开。◎核心业务与非核心业务分离。◎将电子商务的主要流程与辅助流程分开。◎应用与数据分离。◎服务分离和实现细节。(3)抽象◎应用抽象：应用只依赖服务抽象，不依赖服务实现的细节和位置。◎数据库抽象：应用只依赖于逻辑数据库，不需要关心物理数据库的位置和分片。◎服务抽象：应用虚拟化部署无需关心物理机配置，动态分配资源。(4)松耦合◎异步跨域调用：尝试在不同业务域之间异步解耦。◎尽可能让非核心业务异步：尽量让核心业务和非核心业务异步。◎当需要同步调用时，需要设置超时时间和任务队列长度。(5)容错设计◎服务自治：服务之间可以相互独立修改、部署、发布、管理，避免连锁反应。◎集群容错：应用系统集群部署，避免单点服务。◎多机房容灾：多机房部署，多主用。五、技术架构技术架构是对业务架构中提出的功能（或服务）的技术解决方案的实现，包括软件系统实现、操作系统选择和运行时设计。技术架构的边界是模糊的。对于不同的受众，内容的详细程度也不同。技术栈更注重自上而下的技术架构，但每一层关注的点不同。技术决策层可能关注系统或系统组的技术选型。整体把握一定要保证不会因为选择而引发其他风险。比如高性能存储选择Redis，需要尽可能保证网络封闭。避免公网访问；再比如，在选择各种用COBOL语言实现的产品时，需要考虑到市场上开发人员的数量少，需要承担较高的迭代成本。上述业务架构的简单技术架构如图5.3所示。技术架构的设计原则如下。(1)无状态，即尽量不在机器上保存状态数据。(2)可重复使用。◎复用粒度是具有业务逻辑的抽象服务，而不是服务的实现细节。◎服务引用只依赖于服务抽象。(3)松耦合◎跨业务域调用，尽可能异步解耦。◎设置同步调用时的超时时间和队列大小。◎将相对稳定的基础服务从可变流程服务中分离出来。(4)可管理◎服务可降级。◎可以限制服务。◎服务可以开启或关闭。◎服务可监控。◎白名单机制。◎服务合同的制定。(5)基础服务◎基础服务是下沉、可复用的，如时效、库存、计价等。◎基础服务自治且相对独立。◎基础服务的实施应简化并横向扩展。◎基础服务的实现应该物理隔离，包括与基础服务相关的数据。6.数据架构数据架构是存储数据（资源）的架构。它的设计原则类似于应用程序架构的设计。设计时需要考虑系统的业务场景，需要根据不同的业务场景进行数据和数据库读取的异构设计。写分离、分布式数据存储策略等。如图5.4所示，是电子商务系统中数据架构的概览。数据架构包括两部分：静态部分的内容和动态部分的内容。静态部分的内容侧重于数据元模型和数据模型，包括对主数据、共享动态数据、所有与业务相关的业务对象数据的分析和建模；动态部分的内容侧重于数据生命周期的管控和治理。因此，数据架构不能简单理解为纯静态的数据模型。业务架构中数据模型的分析重点是主数据和核心业务对象，应用架构中数据模型的分析重点进一步转化为逻辑模型和物理模型，直至最终的数据存储和分发.数据分为两个层次的生命周期：单个业务对象数据的全生命周期，在流程建模中往往与单个工作流或审批流相关；跨多个业务领域的对象数据的完整生命周期，反映了多个业务对象数据之间的转换和映射，往往与端到端的业务流程BPM有关。这里需要注意的是，虽然数据是静态内容，但数据的生命周期或者端到端的数据映射往往间接反映了过程，这一点非常重要。数据建模方法包括面向结构的传统ER模型分析方法和面向对象的对象类模型分析方法。它们都是可行的数据建模方法，但传统的ER模型分析方法更容易实现到底层物理数据库模型。转换，而面向对象的对象类建模方法更容易体现抽象和重用。特别是在企业架构建模中，面向对象和面向结构往往没有严格区分。很多情况下，两种方法是混用的，但关键是要分清每种方法或工具的侧重点和要解决的问题。与数据相关的矩阵分析相当多。业务架构阶段的关键矩阵分析是业务对象与业务流程、业务组件、业务功能之间的类CRUD矩阵分析；而在应用架构阶段，矩阵分析的关键是逻辑或物理模型对象与特定应用模块或应用功能之间的矩阵分析。两者的想法基本相似，只是关注的程度不同。前者侧重于主数据的识别和业务组件的分析，后者侧重于应用功能模块的划分和模块间集成接口的初步分析。按照之前的思路，我们还是应该将数据集成分析分解为两个层次：业务层面的分析，以及应用和IT实现层面的分析。前者侧重于阐明业务领域之间的业务流程或业务对象集成交互，后者侧重于如何更好地共享数据，或者如何通过类似的BI工具或大数据平台实现数据集成交互。数据架构的设计原则如下。（1）统一数据视图，即保证数据的及时性、一致性、准确性和完整性。(2)数据与应用分离。◎应用系统只依赖于逻辑数据库。◎应用系统不直接访问其他应用的数据库，只是通过接口访问。（3）数据异构，即当源数据和目标数据内容相同时进行索引异构，当商品库不同维度的内容不同时（如买家）进行数据库异构订单数据中的库和卖家库）。(4)数据库读写分离。◎访问量大的数据库，如订单数据库，读写分离。◎将数据量大的数据库和表做成单独的数据库和表。◎对不同业务领域的数据库进行分区和隔离。◎配置重要数据的备份数据库。(5)使用关系数据库。除了成本因素外，MySQL具有强大的数据库扩展能力和高并发支持能力，相对容易招到相关研发人员和运维人员。(6)合理使用NoSQL数据库。在数据库能够支持的情况下，尽量不要引入缓存。此外，还需要合理利用缓存进行容灾。原文地址：程序员架构实战：架构设计总结、业务、应用、技术、数据架构IT项目中各种架构图的绘制方法
