图片来自抱图网。架构设计除了掌握技术框架、技术组件、技术原理知识外，还需要系统掌握架构的基础知识。以架构设计原则为指导，掌握架构设计方法论，通过不断优化迭代，实现更好的架构设计。架构设计的本质在理解架构的本质之前，首先要了解架构的定义。百度百科对架构的定义：架构，又称软件架构，是对软件整体结构和组成部分的抽象描述，用于指导大型软件系统各方面的设计。从定义中，我们提取出以下关键词：组件：也可以称为软件元素或架构元素。它可以是子系统、模块和应用程序服务，具体取决于粒度。结构：它是架构之后的输出。不同的软件系统会有不同的结构，而这些结构是为了解决不同的场景而设计的。关系：实现架构组件之间的连接。连接关系可以是JVM内部调用，组件之间，跨应用的分布式调用，也可以是与外部系统接口的集成调用。架构是将软件组件按照一定的结构连接起来。如何找到软件组件，用什么结构将它们连接起来，如何连接它们，都是软件复杂性带来的问题。架构设计的本质是解决软件复杂性带来的问题。软件复杂性有多种形式，例如业务复杂性、性能复杂性、可用性复杂性、可伸缩性复杂性和安全性复杂性。任何系统都有它专注于解决的复杂性问题。了解每个架构方案背后需要解决哪些软件复杂性问题，是判断一个架构设计目的的关键因素。这在架构设计中也经常被提及。系统限制。业务复杂度反映了如何拆解业务，找到合适的软件元素和组件，并按照合适的结构将它们连接起来；性能复杂度反映了如何找到软件元素，进行适当的连接，形成一定的结构，满足高性能要求。例如，大型ERP系统是一个业务复杂度很高的系统。如何拆分成独立完整的组件，业务边界清晰？这是你在做架构设计时需要考虑的。再比如搭建秒杀系统。系统复杂度要求就是性能复杂度。如何承受秒杀的峰值，是性能复杂度上需要解决的问题。软件开发和架构设计的区别软件开发更多的是面向确定性逻辑问题，是根据自己对需求的理解来实现的。实现方式相对固定，通过流程化开发完成所需功能，达到最终目的。比如实现接单能力，有几个步骤：参数校验、商品查询、库存抢占、订单生成、库存扣减、订单状态修改、状态返回。业务逻辑比较固定。如果加上编码规范和框架的约束，除了数据模型和编码设计之外，其他方面涉及的就少了。架构设计更多的是面向不确定性的问题，如何将系统拆分成组件，如何识别是否是组件，如何连接组件与组件，这些都是具有多种可能性的架构解决方案。解决一个软件复杂度问题，有A方案，B方案，甚至C方案，到底该用哪一个，原因是什么，都是架构设计需要考虑的问题。如何在各种选项中做出决定，如何判断自己选择的选项是否合理，当然决策能力不是靠脑子决定的，它其实需要一系列的原则来指导，通过这些指导原则加上实践经验来判断最好的解决方案。架构设计的三大原则说到架构设计，就不得不说到三个基本原则。作为架构设计过程中的参考，更好地帮助分析、决策和支持。①适宜性原则首先提到适宜性原则。凡是不按实景走的建筑设计都是耍流氓。比如你要买车，买贵的车，觉得性价比不高，买便宜的车，又觉得开起来不舒服。最终，你会选择一款适合自己目前经济能力，并且相对舒适的车。这就是适度原则。针对当前业务需求和非功能需求，匹配业务发展阶段，合理利用资源实现价值最大化（买车需要匹配当前经济状况）。需要结合实际场景和合适的系统架构（我买车只是为了代步，不能说我觉得跑车很时尚，所以就买跑车，和实际业务场景）。还需要和现在的业务规模以及最近1-2年的发展规划相匹配（虽然我一次性负担不起，但是我有稳定的经济收入，可以考虑2年后贷款.这样我就可以买到心仪的机型，也不用担心压力了）。新技术的引入必然会解决某个场景下的问题，但并不能解决所有的问题。任何架构都必须根据适当??的原则进行全面的审查和选择。②简单原则遵循简单原则，大道至简，一切从简，用最简单的方案解决问题。KISS（KeepSimpleandStupid）是用户体验的最高境界，同样适用于建筑设计。简单是软件设计的目标。简单的代码花费的时间更少，产生的错误更少，并且易于修改、维护、扩展和重构。不要认为简单的设计就没有技术含量。用简单的设计来处理复杂的问题，需要优秀的架构设计能力。一个软件系统之所以说复杂，就体现在它复杂的结构和复杂的逻辑上，一个复杂的问题是由多个简单的问题组合而成的。难点在于如何拆解，拆解成多个问题，一个一个解决，把复杂的逻辑拆分成单个的执行单元。单个执行单元的代码量要尽可能小。一个复杂的逻辑系统，所有的逻辑功能都在内部实现，几乎每一个环节都会出现问题。它需要面对不断变化的需求。每个人都维护着同一套代码，整个开发、测试、上线的过程变得异常繁重。③进化原理最后是进化原理。只有变化才是永恒的，优秀的架构必须在不断的业务发展中演进。设计的架构要满足当时的业务需求，具有扩展性和持续开发能力，能够应对后续的架构升级和调整。需要在实际应用过程中不断迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，剔除无用的设计，逐步完善架构，区分变化的部分和不变的部分。架构设计方法论说到架构设计方法论，首先介绍一下TOGAF（TheOpenGroupArchitectureFramework），它是由国际标准权威组织TheOpenGroup制定的，是一个行业标准的架构框架。它是一套方法和工具，主要包括TOGAF能力框架、TOGAF架构开发方法、TOGAF企业连续体和工具。下面主要介绍软件开发方法（ArchitectureDevelopmentMethod）ADM。ADM软件开发方法包括一组按照架构领域的架构开发顺序排列成环状的阶段。ADM基础架构图如下图所示：图1：ADM基础架构图前期：梳理业务需求，理解需求背后真正的业务目标。架构愿景：最终要达到一个效果，需要提前规划。业务架构、信息系统架构、技术架构：属于架构领域设计框架。技术与解决方案：遇到技术问题时，需要一套甚至多套解决方案。架构设计的职责是做出权衡和决策。迁移规划与实施治理：为后续线上运维相关事宜提供合理的解决方案。架构设计方法论：指导你如何进行架构设计。它具有体系结构域划分。在软件设计中，架构领域包括：业务架构、数据架构、产品架构、应用架构和技术架构。首先，需要结合业务场景梳理业务需求。熟悉业务后，通过归纳和抽象形成业务架构。基于对业务架构的理解，研发人员需要进一步对业务进行抽象和沉淀，绘制出相应的数据架构和应用架构，最后技术人员通过技术架构实现功能。业务架构是目标和方向，应用架构是抽象和归纳，技术架构是系统实现的手段和参考。下图是ADM架构开发的概念蓝图：图2：ADM架构开发的概念蓝图首先我们来看业务架构。业务一般按照以下四层绘制业务架构图：场景层：描述业务场景。产品功能层：划分产品功能和模块。领域模型层：通过对产品功能的分析，抽象出领域模型。依赖层：从业务层面考虑底层业务依赖于哪些子系统或组件。二是数据架构。数据架构解决：需要什么数据，如何存储，如何设计数据模型。最常用的视图是ER图，主要描述数据实体、属性和关系。实体：领域对象。属性：域对象属性。联系（RelationShip）：两个域对象之间的关系（1:1、1:n或）。然后是应用程序架构。将应用架构划分为不同的功能模块，然后根据功能模块之间的关系组合成子系统。应用架构关系的三个问题：子系统如何划分，子系统之间有什么关系考虑模块的复用和功能的抽象应用架构需要体现应用架构是否清晰，层次划分是否清晰，衔接是否清晰应用系统之间的关系是否合理，系统之间的耦合度是否低，是否统一对外提供一致的服务接口。最后是技术架构。技术架构侧重于如何用技术手段解决实际问题，如何选择技术框架，如何选择技术中间件，如何实现存储，如何实现非功能需求。整体技术方案的输出就是实现技术架构的过程，最终会形成关键的技术实现点，形成完整的技术架构。写在最后，以上阐述了架构设计的一些基本原则，帮助读者思考如何通过架构设计理论知识提升自身的架构能力，从而成为一名合格的架构师。架构设计是一个长期的过程，需要不断打磨。任何系统的架构都不是一蹴而就的。当系统面临技术和业务问题时，需要不断优化和迭代。架构设计除了掌握技术框架、技术组件、技术原理知识外，还需要系统掌握架构的基础知识，以架构设计的原则为指导，掌握架构设计的方法论，通过架构设计实现更好的架构。持续优化和迭代设计。Author:JingdongLogisticsJiangLongfeiEditor:TaoJialongSource:Reprintedfrom公众号JingdongTechnology(ID:jingdongjishu)
