共计 3980 个字符，预计需要花费 10 分钟才能阅读完成。
发现了一篇十分好的无关架构的文章，特此转载过去，分享给大家。
一、架构设计
在架构设计过程中，咱们会依据须要做出不同的架构设计，而在设计时须要波及肯定的架构设计外围因素。
二、架构设计概要
架构设计是从业务需要到零碎实现的一个转换，是对需要进一步深入分析的过程，用于确定零碎中实体与实体的关系，以及实体的模式与性能。架构可依据从业务需要到零碎实现的不同须要分为：业务架构、利用架构、数据架构、技术架构。上面以电商零碎为例进行架构设计。
三、业务架构
业务架构是对业务需要的提炼和形象，应用一套方法论对产品（我的项目）所波及需要的业务进行业务边界划分，简略地讲就是依据一套逻辑思路进行业务的拆分，开发软件必须满足业务需要，否则就是海市蜃楼。软件系统在业务上的复杂度问题，能够从业务架构的角度切分工作交界面来解决。比方在做一个电商网站时，须要将商品类目、商品、订单、领取、退款等性能很清晰地划分进去，不要在业务架构中思考用什么技术开发、并发量是否太大、抉择什么样的硬件，等等。
这里简略布局了电商零碎的业务模块，对其依据业务架构的模块一直细化，始终合成到代码流程。对于软件开发而言，以业务架构为依靠，架构师和开发者能比拟清晰地看到零碎的业务全貌，架构师能更不便地剖析零碎复杂度，合成业务逻辑，做好开发的分工，如图 5.1 所示。
业务架构是决定一个软件我的项目是否顺利开展的总纲，软件架构是业务架构在技术层面的映射，正当的开发分工也应该基于业务架构去做。如果没有业务架构，进行软件开发就会很自觉。业务架构是需要和开发的汇聚点，需要剖析是否做到位，性能开发是否达到预期指标，都以此为依靠。咱们在工作中会遇到一些问题，例如研发人员说需要剖析做得不到位，而做需要的人员会质疑需要做到怎么才算到位，为什么开发出的产品和用户想要的不统一，这些从根上来说，都是因为没有将业务架构梳理分明，没有达成共识。
站在软件我的项目的角度来看，在项目前期做好业务架构设计，对整个我的项目的开发都有重要的意义。例如，对于比拟相似的业务零碎，可能业务架构在比拟粗的颗粒度上是一样的，而在细化过程中不一样。
在做我的项目时，当手头有一个现成的零碎，须要做一个需要相似的我的项目时，大家可能会首先尝试用现成的零碎去笼罩新我的项目，以求利益最大化。对于该想法是否实现，能够通过业务架构来掂量，如果没有业务架构，则接下来的工作会十分自觉。业务架构的设计准则如下。
（1）将业务平台化。
◎ 业务平台化，互相独立，例如交易平台、物流平台、领取平台、广告平台等。
◎ 根底业务下沉，可复用，例如用户、商品、类目、促销、时效等。
（2）将外围业务和非核心业务拆散。
将电商零碎的外围业务和非核心业务如主交易服务和通用交易服务拆散，将外围业务精简（利于稳固），并将非核心业务多样化。
（3）隔离不同类型的业务。
◎ 交易平台的作用是让买家和卖家签订交易合同，所以须要优先保障高可用，让用户能疾速下单。
◎ 履约业务对可用性没有太高要求，但要优先保障一致性。
◎ 秒杀业务对高并发要求很高，应该和惯例业务拆散。
（4）辨别主流程和辅助流程。
要分明哪些是电商零碎的主流程，在运行时优先保障主流程的顺利完成；对辅助流程能够采纳后盾异步的形式，防止辅助流程的失败影响主流程的失败回流。
四、利用架构
利用架构介于业务与技术之间，是对整个零碎实现的总体架构，须要指出零碎的档次、零碎开发的准则、零碎各个档次的应用服务。
如图 5.2 所示为将零碎分为体现层、业务流程层、服务层、服务构建层、数据层、集成层、数据架构层和服务治理层，并写明每个档次的利用提供的服务。
在进行零碎拆分时，要均衡业务和技术的复杂度，保证系统形散神不散。零碎采纳什么样的利用架构，则受到业务复杂度的影响，包含企业的倒退阶段和业务特点；同时受技术复杂度的影响，包含 IT 技术的倒退阶段和外部技术人员的程度。业务的复杂度（包含业务量大）必然带来技术的复杂度，利用架构的指标是在解决业务复杂度的同时防止技术太简单，确保业务架构落地。
利用架构的设计准则如下。
（1）稳固
◎ 所有以稳固为核心。
◎ 架构尽可能简略、清晰，谋求小而美，不要大而全。
◎ 不适度设计。
（2）解耦
◎ 将稳固局部与易变局部拆散。
◎ 将外围业务与非核心业务拆散。
◎ 将电商主流程和辅助流程拆散。
◎ 将利用与数据拆散。
◎ 将服务和实现细节拆散。
（3）形象
◎ 利用抽象化：利用只依赖服务形象，不依赖服务实现的细节和地位。
◎ 数据库抽象化：利用只依赖逻辑数据库，不须要关怀物理库的地位和分片。
◎ 服务抽象化：利用虚拟化部署，不须要关怀实体机的配置，动静调配资源。
（4）松耦合
◎ 跨域调用异步化：在不同的业务域之间尽量异步解耦。
◎ 非核心业务尽量异步化：在外围业务和非核心业务之间尽量异步化。
◎ 在必须同步调用时，须要设置超时工夫和工作队列的长度。
（5）容错设计
◎ 服务自治：服务能彼此独立批改、部署、公布和治理，防止引发连锁反应。
◎ 集群容错：利用零碎集群部署，防止单点服务。
◎ 多机房容灾：多机房部署、多活。
五、技术架构
技术架构就是对在业务架构中提出的性能（或服务）进行技术计划的实现，包含软件系统实现、操作系统抉择和运行时设计。技术架构的边界比拟含糊，对于不同的受众，内容的具体水平也不同，技术栈自上而下比拟关注技术架构，然而各层关注的点不同。技术决策层可能关怀的是零碎或零碎群的技术选型，对整体的把握要保障不因为选型引起其余危险，例如，如果在高性能存储方面抉择 Redis，就要尽量保障网络的封闭性，防止公网拜访；再如，在抉择以 COBOL 语言实现的各类产品时，要思考市场上开发人员数量少，须要承当更高的迭代老本等。
上述业务架构的一个简略技术架构如图 5.3 所示。
技术架构的设计准则如下。
（1）无状态，即尽量不要把状态数据保留在本机上。
（2）可复用。
◎ 复用粒度是有业务逻辑的形象服务，不是服务的实现细节。
◎ 服务援用只依赖服务形象。
（3）松耦合
◎ 跨业务域调用，尽可能异步解耦。◎ 在同步调用时设置超时工夫和队列大小。
◎ 将绝对稳固的根底服务与易变流程服务拆散。
（4）可治理
◎ 服务可降级。
◎ 服务可限流。
◎ 服务可开关。
◎ 服务可监控。
◎ 白名单机制。
◎ 制订服务契约。
（5）根底服务
◎ 根底服务下沉、可复用，例如时效、库存和价格计算。
◎ 根底服务自治、绝对独立。
◎ 对根底服务的实现要精简，并可程度扩大。
◎ 对根底服务的实现要进行物理隔离，包含根底服务相干的数据。
六、数据架构
数据架构是对存储数据（资源）的架构，其设计准则和利用架构
设计大同小异，在设计时须要思考零碎的业务场景，须要依据不同的业务场景对数据进行异构设计、数据库读写拆散、分布式数据存储策略等。如图 5.4 所示是电商零碎中数据架构的一个概要。
数据架构包含两局部内容：动态局部的内容和动静局部的内容。
动态局部的内容的重点是数据元模型、数据模型，包含主数据、共享动态数据和所有业务相干的业务对象数据的剖析和建模；动静局部的内容的重点则是对数据全生命周期的管控和治理。因而，不能单纯地将数据架构了解为纯动态的数据模型。业务架构中数据模型的剖析重点是主数据和外围业务对象，利用架构中数据模型的剖析重点则进一步转换为逻辑模型和物理模型，直到最终的数据存储和散布。
数据分两个层面的生命周期：单业务对象数据的全生命周期，它往往和流程建模中的单个工作流或审批流相干；跨多个业务域对象数据的全生命周期，它体现的是多个业务对象数据之间的转换和映射，
往往和端到端的业务流程 BPM 相干。这里要留神，数据尽管是动态层面的内容，然而数据的生命周期或端到端的数据映射往往间接反映了流程，这是很重要的内容。
数据建模的办法包含面向构造的传统 ER 模型分析方法，也包含面向对象的对象类模型分析方法，它们都是可行的数据建模办法，只是传统 ER 模型分析方法更容易实现向底层物理数据库模型的转换，而面向对象的对象类建模办法更容易体现形象和复用。特地是在企业架构建模中，面向对象和面向构造往往不是严格辨别的，很多时候都会呈现两种办法混用的状况，但重点是辨别每种办法或工具的重点及要解决的问题。与数据相干的矩阵剖析相当多，业务架构阶段的重点矩阵剖析是业务对象和业务流程、业务组件、业务性能间的类 CRUD 矩阵剖析；而利用架构阶段的重点矩阵剖析是逻辑或物理模型对象和具体的利用模块或利用性能间的矩阵剖析。两者的思路根本相似，只是关注的层面不同，前者重点关注主数据的辨认和业务组件的剖析，而后者重点关注利用功能模块的划分和模块间集成接口的初步剖析。
依据后面的思路，咱们依然应该将数据集成剖析合成为两个层面的内容：业务层面的剖析，以及利用和 IT 实现层面的剖析。前者的重点是理清业务流程或业务域之间的业务对象集成和交互，而后者的重点是如何更好地共享数据或如何通过相似的 BI 工具或大数据平台实现数据的集成和交互。
数据架构的设计准则如下。
（1）对立数据视图，即保证数据的及时性、一致性、准确性和完整性。
（2）数据和利用拆散。
◎ 利用零碎只依赖逻辑数据库。
◎ 利用零碎不间接拜访其余利用的数据库，只能通过接口拜访。
（3）数据异构，即在源数据和指标数据内容雷同时做索引异构，在商品库不同维度的内容不同时（如订单数据中的买家库和卖家库）做数据库异构。
（4）数据库读写拆散。
◎ 将访问量大的数据库做读写拆散，例如订单库。
◎ 将数据量大的数据库做分库分表。
◎ 将不同业务域的数据库做分区隔离。◎ 对重要的数据配置备库。
（5）采纳关系数据库。除老本因素外，MySQL 的数据库扩展性和高并发反对能力较强，也比拟容易招聘到相干的研发人员和运维人员。
（6）正当利用 NoSQL 数据库。在数据库有能力撑持时，尽量不要引入缓存。另外，要正当利用缓存做容灾。
原文地址：
程序员架构修炼：架构设计概要、业务、利用、技术、数据架构
如何画好 IT 我的项目中的各种架构图