一文读懂架构设计

Posted 2021-04-10 小马技术圈

是新朋友吗？记得先点蓝字关注我哦～

导读

    架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

    在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。

    架构是系统的骨架，支撑和链接各个部分，包括组件、连接件、约束规范，以及指导这些内容设计与演化的原理。

01 组件

类似应用服务，独立模块、数据库、nginx等等

02 连接件

分布式调用、进程间调用、调用使用http协议还是tcp协议、组件之间的交互关系、

03 约束规范

定规则做限制：例如设计原则、编码规范等等。

架构=组件+交互

    这类似建筑设计规划，城市总体规划等，其实就是架构，只是应用的场景不同。盖一座小房子，可以拍脑袋干起来，但是当你要盖一座大楼，如果没有一个建筑设计规划，可以想象搭建完成后是什么样？

    架构的本质就是对系统进行有序化地重构以致符合当前业务的发展，并可以快速扩展。

    那什么样的系统要考虑做架构设计?

1. 需求相对复杂；

2. 非功能性需求在整个系统占据重要位置；

3. 系统生命周期长,有扩展性需求；

4.系统基于组件或者集成的需要；

5.业务流程的需要。

架

构

分

类

    架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构。

    业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。

    熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。

    如何针对需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。

01、业务架构

    包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。

    没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。

    所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

    下面给大家分享看一下京东的业务架构（网上分享图）：

02、应用架构

    应用架构也叫逻辑架构。

    硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

    类似：

    应用架构：应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面。应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

应用架构图关键有2点：

1、职责划分: 明确应用（各个逻辑模块或者子系统）边界

①逻辑分层；

②子系统、模块定义；

③关键类。

2、职责之间的协作：

①接口协议：应用对外输出的接口；

②协作关系：应用之间的调用关系。

应用分层有两种方式：

    1、一种是水平分（横向）：

    按照功能处理顺序划分应用，比如把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。

    2、一种是垂直分（纵向）：

    按照不同的业务类型划分应用，比如进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。

    应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。

    应用架构的本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。

    系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

03、代码架构

    代码架构也叫开发架构。

    子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。

    代码架构主要定义：

    1、代码单元:

    ①配置设计

    ②框架、类库。

    2、代码单元组织：

    ①编码规范，编码的惯例。

    ②项目模块划分

    ③顶层文件结构设计，比如mvc设计。

    ④依赖关系

04、技术架构

    技术架构也叫系统架构。

    技术架构：确定组成应用系统的实际运行组件（lvs，nginx，tomcat，php-fpm等），这些运行组件之间的关系，以及部署到硬件的策略。

    技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

    系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。

05、部署拓扑架构

    拓扑架构，包括架构部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。这个图主要是运维工程师主要关注的对象。

为什么要画架构图

1、梳理对产品和技术方向的判断

    画图前思考架构图如何设计，帮助梳理“未来产品朝什么方向发展、功能迭代如何分期与落地，和其他产品的依赖关系是什么，技术方案该如何演进”等问题。

2、技术&提供产品&运营的输出

    当架构图被设计出来后，按照架构图的结构和路径，项目的里程碑（RoadMap）就可以被清晰的拆解出来，同时项目成员也可以根据这张架构图产出运营计划、技术架构等强依赖产品方向的方案。

    当技术架构图被设计出来后，技术方案、技术开发进度就可以被清晰的制定，技术选型就会明确的选定。

3、让他人理解你的架构

    能清晰简单呈现思路，明确产品边界和技术边界，指明发展方向，帮助他人更快速更清晰的了解你的结构、功能、技术。

小马技术圈

分享/交流