电商网站卷烟订货流程,北京国企网站建设,WordPress功能文件,一个网站源码值多少钱文章目录 一. 架构定义与架构的作用1. 系统与子系统2. 模块与组件3. 框架与架构4. 重新定义架构#xff1a;4R 架构 二、架构设计的真正目的-别掉入架构设计的误区1. 是为了解决软件复杂度2. 简单的复杂度分析案例 三. 案例思考 本文关键字 架构定义 架构与系统的关系从业务逻… 文章目录 一. 架构定义与架构的作用1. 系统与子系统2. 模块与组件3. 框架与架构4. 重新定义架构4R 架构 二、架构设计的真正目的-别掉入架构设计的误区1. 是为了解决软件复杂度2. 简单的复杂度分析案例 三. 案例思考 本文关键字 架构定义 架构与系统的关系从业务逻辑的角度将系统拆成模块从物理角度讲系统拆成组件架构与框架的区别 架构设计的目的与案例分析 一. 架构定义与架构的作用
要想准确地理解架构的定义关键就在于把三组容易混淆的概念梳理清楚系统与子系统、模块与组件、框架与架构。
1. 系统与子系统 一个系统的架构只包括顶层这一个层级的架构而不包括下属子系统层级的架构。比如微信架构就是指微信系统这个层级的架构。当然微信的子系统比如支付系统也有它自己的架构同样只包括顶层。 2. 模块与组件 如果你是业务系统的架构师首先需要思考怎么从业务逻辑的角度把系统拆分成一个个模块角色其次需要思考怎么从物理部署的角度把系统拆分成组件角色例如选择 MySQL 作为存储系统。 但是对于 MySQL 内部的体系架构Parser、Optimizer、CachesBuffers 和 Storage Engines 等你其实是可以不用关注的也不需要在你的业务系统架构中展现这些内容。 3. 框架与架构
框架是一整套开发规范架构是某一套开发规范下的具体落地方案包括各个模块之间的组合关系以及它们协同起来完成功能的运作规则。 4. 重新定义架构4R 架构
重新定义为软件架构指软件系统的顶层Rank结构它定义了系统由哪些角色Role组成角色之间的关系Relation和运作规则Rule。 第一个 RRank。 它是指软件架构是分层的对应“系统”和“子系统”的分层关系。通常情况下我们只需要关注某一层的架构最多展示相邻两层的架构而不需要把每一层的架构全部糅杂在一起。无论是架构设计还是画架构图都应该采取“自顶向下逐步细化”的方式。以微信为例Rank 的含义如下所示 第二个 RRole。 它是指软件系统包含哪些角色每个角色都会负责系统的一部分功能。架构设计最重要的工作之一就是将系统拆分为多个角色。最常见的微服务拆分其实就是将整体复杂的业务系统按照业务领域的方式拆分为多个微服务每个微服务就是系统的一个角色。 第三个 RRelation。 它是指软件系统的角色之间的关系对应到架构图中其实就是连接线角色之间的关系不能乱连任何关系最后都需要代码来实现包括 连接方式HTTP、TCP、UDP 和串口等数据协议JSON、XML 和二进制等具体的接口等。 第四个 RRule。 它是指软件系统角色之间如何协作来完成系统功能。我们在前面解读什么是“系统”的时候提到过系统能力不是个体能力之和而是产生了新的能力。那么这个新能力具体如何完成的呢具体哪些角色参与了这个新能力呢这就是 Rule 所要表达的内容。在架构设计的时候核心的业务场景都需要设计 Rule。 二、架构设计的真正目的-别掉入架构设计的误区
1. 是为了解决软件复杂度
架构设计的主要目的是为了解决软件系统复杂度带来的问题。 如果明确了“架构设计是为了解决软件复杂度”原则后下面的问题就很好回答。 “这么多需求从哪里开始下手进行架构设计呢”——通过熟悉和理解需求识别系统复杂性所在的地方然后针对这些复杂点进行架构设计。 “架构设计要考虑高性能、高可用、高扩展……这么多高 XX全部设计完成估计要 1 个月但老大只给了 1 周时间”——架构设计并不是要面面俱到不需要每个架构都具备高性能、高可用、高扩展等特点而是要识别出复杂点然后有针对性地解决问题。 “业界 A 公司的架构是 XB 公司的方案是 Y两个差别比较大该参考哪一个呢”——理解每个架构方案背后所需要解决的复杂点然后才能对比自己的业务复杂点参考复杂点相似的方案。 其次遵循这条准则能够让“老鸟”架构师有的放矢而不是贪大求全。
如下误区 “我们的系统一定要做到每秒 TPS 10 万”。“淘宝的架构是这么做的我们也要这么做”。“Docker 现在很流行我们的架构应该将 Docker 应用进来”。 实际上 “我们的系统一定要做到每秒 TPS 10 万”——如果系统的复杂度不是在性能这部分TPS 做到 10 万并没有什么用。 “Docker 现在很流行我们的架构应该将 Docker 应用进来”——Docker 不是万能的只是为了解决资源重用和动态分配而设计的如果我们的系统复杂度根本不是在这方面引入 Docker 没有什么意义。 2. 简单的复杂度分析案例
假设我们需要设计一个大学的学生管理系统其基本功能包括登录、注册、成绩管理、课程管理等。当我们对这样一个系统进行架构设计的时候首先应识别其复杂度到底体现在哪里。 性能一个学校的学生大约 1 ~ 2 万人学生管理系统的访问频率并不高平均每天单个学生的访问次数平均不到 1 次因此性能这部分并不复杂存储用 MySQL 完全能够胜任缓存都可以不用Web 服务器用 Nginx 绰绰有余。可扩展性学生管理系统的功能比较稳定可扩展的空间并不大因此可扩展性也不复杂高可用学生管理系统即使宕机 2 小时对学生管理工作影响并不大因此可以不做负载均衡更不用考虑异地多活这类复杂的方案了。但是如果学生的数据全部丢失修复是非常麻烦的只能靠人工逐条修复这个很难接受因此需要考虑存储高可靠这里就有点复杂了。我们需要考虑多种异常情况机器故障、机房故障针对机器故障我们需要设计 MySQL 同机房主备方案针对机房故障我们需要设计 MySQL 跨机房同步方案。安全性学生管理系统存储的信息有一定的隐私性例如学生的家庭情况但并不是和金融相关的也不包含强隐私例如玉照、情感的信息因此安全性方面只要做 3 个事情就基本满足要求了Nginx 提供 ACL 控制、用户账号密码管理、数据库访问权限控制。成本由于系统很简单基本上几台服务器就能够搞定对于一所大学来说完全不是问题可以无需太多关注。 通过上面的分析可以看到这个方案的主要复杂性体现在存储可靠性上需要保证异常的时候不要丢失所有数据即可丢失几个或者几十个学生的信息问题不大对应的架构如下 三. 案例思考
找到核心的复杂点
不要为了架构而架构 识别架构复杂程度与具体化 参考李运华-《从零开始学架构》
