读（从0开始学架构）（一）

本文包含（什么是架构；设计架构的目的；架构的复杂度来源；架构设计原则；）

内容

1、什么是架构

　　理解架构首先要了解三组概念

　　1、系统和子系统

　　　　系统：

　　　　百科上定义的系统：系统泛指一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作群体。它的意思是”总体“ “整体”或者“联盟”

　　　　　　1）关联：系统是由一群有关联的总体组成，没有关联的个体堆在一起不能成为一个系统。

　　　　　　2）规则：系统内的个体需要按照指定的规则运作，而不是单个个体各自为政。规则定义了系统内各个个体的分工和协作方式。

　　　　　　3）能力：系统能力与个体能力有本质的差别，系统能力不是个体能力之和，而是产生了新的能力。

　　　　子系统：

　　　　　　子系统是由一群有关联的个体所组成的系统，多半是更大系统的一部分。

　　　　　　　按照这个为例：

　　　　　　　　微信本身是一个系统，包含聊天，登录，支付，朋友圈等等

　　　　　　　　朋友圈系统又包含动态，评论，点赞等子系统。

 

　　2、模块和组件

　　　　百科对于模块的定义是：

　　　　　　软件模块（Module）是一套一致而互相有紧密关连的软件组织。它分别包含了程序和数据结构两部分。现代软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需的元素。模块是可能分开被编写的单位。

　　　　这使它们可再用和允许人员同时协作、编写及研究不同的模块。软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易被用于组装应用程序中。

　　　　模块和组件都是系统组成的重要部分，只是从不同的角度拆分系统而已。

　　　　从业务逻辑的角度拆分系统后得到的就是模块，从物理角度拆分后，得到的就是组件，划分模块的主要目的师职责分离；划分组件的主要目的师单元复用

　　3、框架和架构

　　　　框架：通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。

　　　　框架的规范就是比如;mvc是一种常见的开发规范。

　　　　系统架构是指软件系统的基础结构，创造这些基础结构的准则和对这些结构的描述。

　　　　从关系的角度说框架关注的是规范，架构关注的是结构。

　　　　比如学生管理系统来说我们使用.net Framework 的 mvc 框架构开发 所以演变成 mvc架构。

　　框架 是一套开发规范，架构是某一套开发规范下的具体落地方案，包含各个模块之间的组合关系以及它们协同起来完成功能的运作规则。

　　根据这本说上说的软件架构是指软件系统的顶层结构，它定义了系统由哪些角色组成，角色之间的关系和运作规则。

　　总结：架构师顶层设计，框架是面向编程或配置的半成品；组件时从技术维度上的复用；模块时从业务维度上职责的划分，系统时相互协同可运行的实体。

2、架构设计的目的

　　架构设计的目前时为了解决系统软件复杂度带来的问题。

　　架构设计并不是面面俱到，而是有针对性的解决问题。

　　如何了解系统软件的复杂度

　　例如：设计一个学生管理系统基础功能包含登录注册成绩管理，课程管理等。

　　性能：一个学校的学生约1-2w人，学生管理系统访问频率不高，每天访问频率2w次，数据库 mysql完全胜任，web服务器用nginx没有任何问题。

　　可扩展性：功能稳定，扩展空间不大，扩展性不复杂。

　　高可用：系统宕机2小时对学生管理影响不大，但是会被吐槽，可以作负载均衡，异地多活方案不需要考虑，需要考虑机器故障，机房故障；针对机器故障，可以使用主备方案。机房故障使用跨机房同步方案。

　　安全性：用户账号控制，数据访问权限控制，Nginx 提供 ACL 控制。

　　可以从这些方面着手分析系统的复杂度。

3、架构的复杂度来源

高性能：

1 ：WHAT 对高性能的理解? 性能是软件的一个重要质量属性。衡量软件性能包括了响应时间、TPS、服务器资源利用率等客观指标，也可以是用户的主观感受（从程序员、业务用户、终端用户/客户不同的视角，可能会得出不同的结论）。

在说性能的时候，有一个概念与之紧密相关—伸缩性，这是两个有区别的概念。性能更多的是衡量软件系统处理一个请求或执行一个任务需要耗费的时间长短；而伸缩性则更加关注软件系统在不影响用户体验的前提下，能够随着请求数量或执行任务数量的增加（减少）而相应地拥有相适应的处理能力。

但是，什么是“高”性能？这可能是一个动态概念，与当前的技术发展状况与业务所处的阶段紧密相关。比如，现在在行业/企业内部认为的高性能，站在5年后来看，未必是高性能。因此，站在架构师、设计师的角度，高性能需要和业务所处的阶段来衡量。高到什么程度才能与当前或可预见的未来业务增长相匹配。一味去追求绝对意义上的高，没有太大的实际意义。因为，伴随性能越来越高，相应的方法和系统复杂度也是越来越高，而这可能会与当前团队的人力、技术、资源等不相匹配。但是什么才合适的高性能了？这可能需要从国、内外的同行业规模相当、比自己强的竞争者、终端用户使用反馈中获取答案并不断迭代发展。 软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度；另一方面是多台计算机集群为了高性能带来的复杂度。

2： WHY 为什么需要高性能？

追求良好的用户体验； 满足业务增长的需要。

3： HOW 如何做好高性能？

可以从垂直与水平两个维度来考虑。

垂直维度主要是针对单台计算机，通过升级软、硬件能力实现性能提升；

水平维度则主要针对集群系统，利用合理的任务分配与任务分解实现性能的提升。

垂直维度可包括以下措施： 增大内存减少I/O操作 更换为固态硬盘（SSD）提升I/O访问速度 使用RAID增加I/O吞吐能力 置换服务器获得更多的处理器或分配更多的虚拟核 升级网络接口或增加网络接口

水平维度可包括以下措施： 功能分解：基于功能将系统分解为更小的子系统 多实例副本：同一组件重复部署到多台不同的服务器 数据分割：在每台机器上都只部署一部分数据 垂直维度方案比较适合业务阶段早期和成本可接受的阶段，该方案是提升性能最简单直接的方式，但是受成本与硬件能力天花板的限制。

水平维度方案所带来的好处要在业务发展的后期才能体现出来。起初，该方案会花费更多的硬件成本，另外一方面对技术团队也提出了更高的要求；但是，没有垂直方案的天花板问题。一旦达到一定的业务阶段，水平维度是技术发展的必由之路。因此，作为技术部门，需要提前布局 ，未雨绸缪，不要被业务抛的太远。

 

高可用：

需求驱动技术；

而高可用与高性能，是架构设计中两个非常重要的决策因素。因此，面对不同业务系统的不同需求，对高可用与高性能也会有不同的决策结论，其实现的复杂度也各不相同。

支付宝业务，对于可用性和性能就会有很高的要求，在可用性方面希望能提供7＊24不间断服务，在高性能方面则希望能实时收付款；

而对于一个学生管理系统，在可用性与性能方面就不一定要有多高的要求，比如晚上可关机，几秒内能查询到信息也可接受。

为此，高可用性与高性能的复杂度讨论需要结合业务需求。

1： WHAT - 什么是可用性？

定义可用性，可以先定义什么是不可用。

需要经历若干环节，网站的页面才能呈现在最终的用户面前；而其中的任何一个环节出现了故障，都可能会导致网站的页面不可访问，也就是出现了网站不可用的情况。iOS版本QQ出现大面积闪退就是一个系统不可用的典型案例。

我们可以利用百分比来对网站可用性进行度量：

网站不可用时间=完成故障修复的时间点 - 故障发现的时间点

网站年度可用时间=年度总时间 - 网站不可用时间

网站年度可用性=(网站年度可用时间/年度总时间) x 100%

举例：一些知名大型网站的可用性可达到99.99%（俗称4个9），我们可以算一下一年下来留给处理故障的时间有多少？

年度总时间=365*24*60=525600分钟

网站不可用时间=525600*(1-99.99%)=52.56分钟

也就是，如果网站要达到4个9的可用性，一年下来网站不可用时间最多53分钟（也就是不足1个小时）。

可见，高可用性就是技术实力的象征，高可用性就是竞争力。

2 ：WHY - 为什么会出现不可用？

硬件故障。

网站多运行在普通的商用服务器，而这些服务器本身就不具备高可用性，再加之网站系统背后有数量众多服务器，那么一定时间内服务器宕机是大概率事件，直接导致部署在该服务器上的服务受影响。

软件BUG或网站更新升级发布。BUG不能消灭，只能减少；上线后的系统在运行过程中，难免会出现故障，而这些故障同样直接导致某些网站服务不可用；此外，网站更新升级发布也会引起相对较频繁的服务器宕机。 不可抗拒力。如地震、水灾、战争等。

3 ：HOW - 如何做到高可用

核心思想：网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上；数据存储在多台服务器上互相备份。

通过上述技术手段，当任何一台服务器宕机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失。

从架构角度看可用性：当前网站系统多采用经典的分层模型，从上到下为：应用层、服务层与数据层。

应用层主要实现业务逻辑处理；

服务层提供可复用的服务；

数据层负责数据读写；

在部署架构上常采用应用和数据分离部署，应用会部署到不同服务器上，这些服务器被称为应用层的服务器；

这些可复用的服务也会各自部署在不同服务器上，称为服务层的服务器；

而各类数据库系统、文件柜等数据则部署在数据层的服务器。

硬件故障方面引起不可用的技术解决措施：

(1)应用服务器。

可通过负载均衡设备将多个应用服务器构建为集群对外提供服务（前提是这些服务需要设计为无状态，即应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行业务逻辑的操作响应），当均衡设备通过心跳检测手段检测到应用服务器不可用时，则将其从集群中移除，并将请求切换到其他可用的应用服务上。

(2)服务层服务器。

这些服务器被应用层通过分布式服务框架（如Dubbo）访问，分布式服务框架可在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心跳检测，当发现有服务器不可用时，立即通知客户端程序修改服务列表，同时移除响应的服务器。

(3)数据服务器。

需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份；当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。 软件方面引起不可用的技术解决措施：通过软件开发过程进行质量保证。通过预发布验证、严格测试、灰度发布等手段，尽量减少上线服务的故障。

可扩展性：

1 ：What：什么是架构的可扩展性？

业务需求、运行环境方面的变化都会导致软件系统发生变化，而这种软件系统对上述变化的适应能力就是可扩展性。

可扩展性可以理解为是一种从功能需求方面考虑的软件属性，属性就会存在好坏之分。

按照可扩展性的定义，一个具备良好可扩展性的架构设计应当符合开闭原则：对扩展开放，对修改关闭。衡量一个软件系统具备良好可扩展性主要表现但不限于：（1）软件自身内部方面。在软件系统实现新增的业务功能时，对现有系统功能影响较少，即不需要对现有功能作任何改动或者很少改动。（2）软件外部方面。软件系统本身与其他存在协同关系的外部系统之间存在松耦合关系，软件系统的变化对其他软件系统无影响，其他软件系统和功能不需要进行改动。反之，则是一个可扩展性不好的软件系统。

2 ：Why：为什么要求架构具备良好的可扩展性？

伴随业务的发展、创新，运行环境的变化，对技术也就提出了更多、更高的要求。能够快速响应上述变化，并最大程度降低对现有系统的影响，是设计可扩展性好的架构的主要目的。

3： How：如何设计可扩展性好的架构？

面向对象思想、设计模式都是为了解决可扩展性的而出现的方法与技术。

设计具备良好可扩展性的系统，有两个思考角度：

（1）从业务维度。对业务深入理解，对可预计的业务变化进行预测。

　　在业务维度。对业务深入理解，对业务的发展方向进行预判，也就是不能完全不考虑可扩展性；但是，变化无处不在，在业务看得远一点的同时，需要注意:警惕过度设计；不能每个设计点都考虑可扩展性；所有的预测都存在不正确的可能性。

（2）从技术维度。利用扩展性好的技术，实现对变化的封装。

　　在技术维度。预测变化是一回事，采取什么方案来应对变化，又是另外一个复杂的事情。即使预测很准确，如果方案不合适，则系统扩展一样很麻烦。第一种应对变化的常见方案是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。第二种常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”。

4：在实际工作场景中的解决方案

在实际软件系统架构设计中，常通过以下技术手段实现良好的可扩展性:

（1）使用分布式服务(框架)构建可复用的业务平台。

　　利用分布式服务框架(如Dubbo)可以将业务逻辑实现和可复用组件服务分离开，通过接口降低子系统或模块间的耦合性。新增功能时，可以通过调用可复用的组件实现自身的业务逻辑，而对现有系统没有任何影响。可复用组件升级变更的时候，可以提供多版本服务对应用实现透明升级，对现有应用不会造成影响。

（2）使用分布式消息队列降低业务模块间的耦合性。

　　基于生产者-消费者编程模式，利用分布式消息队列(如RabbitMQ)将用户请求、业务请求作为消息发布者将事件构造成消息发布到消息队列，消息的订阅者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息生产和消息处理分离开来，可以透明地增加新的消息生产者任务或者新的消息消费者任务.

低成本、安全、规模

低成本

What：低成本是架构设计中需要考虑一个约束条件，但不会是首要目标。低成本本质上是与高性能和高可用冲突的，当无法设计出满足成本要求的方案，就只能协调并调整成本目标。

How：一般通过“创新”达到低成本的目标。

（1）引入新技术。主要复杂度在于需要去熟悉新技术，并且将新技术与已有技术结合；一般中小型公司基本采用该方式达到目标。

（2）开创一个全新技术领域。主要复杂度在于需要去创造全新的理念和技术，并且与旧技术相比，需要有质的飞跃，复杂度更高；一般大公司拥有更多的资源、技术实力会采用该方式来达到低成本的目标。

安全

What：安全是一个庞大而又复杂的技术领域，一旦出问题，对业务和企业形象影响非常大。从技术的角度来讲，包括

（1）功能安全-“防小偷”，减少系统潜在的缺陷，阻止黑客破坏行为；

（2）架构安全—“防强盗”，保护系统不受恶意访问和攻击，保护系统的重要数据不被窃取。由于是蓄意破坏系统，因此对影响也大得多。架构设计时需要特别关注架构安全。

How：

（1）功能安全。是一个逐步完善的过程，而且往往都是在问题出现后才能有针对性的提出解决方案，与编码实现有关。

（2）架构安全。传统企业主要通过防火墙实现不同区域的访问控制，功能强大、性能一般，但是成本更高。互联网企业更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力，较少自己来设计和实现。

规模

What：规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。随着业务的发展，规模带来的常见复杂度有

（1）业务功能越来越多，调用逻辑越来越复杂；

（2）数据容量、类型、关联关系越来越多。

How：规模问题需要与高性能、高可用、高扩展、高伸缩性统一考虑。常采用“分而治之，各个击破”的方法策略。

是否还有其他复杂度原因？

- 可伸缩性

当前大型互联网网站需要面对大量用户高并发访问、存储更多数据、处理更高频次的用户交互。网站系统一般通过多种分布式技术将多台服务器组成集群对外提供服务。伸缩性一般是系统可以根据需求和成本调整自身处理能力的一种能力。伸缩性常意味着系统可以通过低成本并能够快速改变自身的处理能力以满足更多用户访问、处理更多数据而不会对用户体验造成任何影响。

伸缩性度量指标包括

（1）处理更高并发；

（2）处理更多数据；

（3）处理更高频次的用户交互。

其复杂度体现在

（1）伸——增强系统在上述三个方面的处理能力；

（2）缩——缩减系统处理能力；

（3）上述伸缩过程还必须相对低成本和快速。

架构的复杂度这一部分 摘抄优秀评论，毕竟在下才疏学浅。

4、架构设计三原则

合适：

每个公司技术团队人数，技术团队人员能力参差不齐，项目预算，业务需求不同。所以说腾讯，淘宝的架构并不适合自己项目的系统架构。

所以说合适至关重要。

简单：

架构设计其实就是一个数学题,我们要把公式给一步步的拆解把难点给优化成最简单的公式，这个公式就是解决这个难点的问题，当软件系统复杂后就会有另外的人换一个思路解决问题，它将重新变得简单。

演化：

大到人类社会，小到细胞结构，似乎都遵循着这一普世原则，软件架构也不例外。业务在发展，技术在创新，外部环境在变化，这一切都是为了告诫我们不要贪大求全，盲目设计，应该分析当前系统的特点，明确系统业务面临的问题呢，设计合理的架构，快速的满足业务需求，在运行中不断完善系统架构。