架构初步学习

架构

什么是架构？这个不太好说

经常性遇到微信架构，淘宝架构

而且经常性和系统，子系统，模块，组件，框架混在一起。

架构设计的目的

架构设计的主要目的是为了解决软件系统复杂度带来的问题
软件系统复杂度带来的问题------高性能

软件系统复杂是由于现实中人们的需求在不断发展带来的，比如以前手机只是满足打电话，后来有了短信，视频，游戏，电影等等，接踵而来就是对性能的致命追求

软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了提高性能带来的复杂度，多台计算机集群为了高性能带来的复杂度

单机复杂度：

单机内部复杂度最关键的地方就操作系统，计算机性能的发展本质是由硬件发展驱动的，将硬件性能发挥出来的关键就是操作系统，所以操作系统本身其实也是跟随硬件发展而发展的，操作系统的软件系统运行环境，操作系统的复杂度直接决定了软件系统的复杂度（如何鸿蒙系统，安卓系统）

最开始的时候计算机是没有操作系统的，只有输入，计算和输出功能，用户输入一个指令，计算机完成，大部分计算机都在等待用户输入指令，处理效率很低效，因为人的速度远远比不上计算机的运算速度

（那为什么不让计算机自己去输入这些数据和相关指令呢？这就产生批处理（这个名字和它本身的理解毛线关系）就是先把要执行的指令预先写下来，形成指令清单，这个指令清单就是常说的任务）批处理程序大大提升了处理性能但有一个很明显的缺点就是计算机一次只能执行一个任务，如i/o在操作的过程中，cpu其实是空闲的，空闲时间可以进行其他计算，这就导致进程,每个任务都有自己独立的内存空间，进程间互不关系，为了达到多线程并行运行目的采用了分时方式，虽然从操作系统和cpu的角度上看还是串行的但是处理快，用户角度就是并行的

为了解决进程之间通行的各种方式设计出管道，消息队列，信息量，共享存储

多进程让多任务能够并行处理任务，但本身还有缺点，单进程内部只能串行处理，而实际上进行内部的子任务并不要求是严格时间执行，比如像饭菜管理，总不能因为个人点菜过长导致其他人不耽误，这就引出了线程,为了保证数据的正确性发明了互斥锁，进程变成操作系统分配资源的最小单位

要从实际上实现多任务并行有三种解决方案：smp对称多处理器结构，mpp海量并行处理结构，numa非一致存储访问结构

要完成一个高性能的软件系统，需要考虑多进程，多线程，多进程通信，多线程并发等技术点，做架构设计时，需要结合业务进行分析，判断，选择，组合，这个过程同样复杂

集群的复杂度

业务发展速度远超硬件发展速度，单机已经无法支撑了，必须采用机器集群的方式来达到高性能

任务分配

从以前的用户访问业务服务器变成用户访问任务分配器到各个业务服务器，这个分配器可能是硬件网络设备，也可能是负载均衡软件，实际上性能一般按照8折计算，随着业务提升任务分配器会从1台变成多台，任务分配器和业务处理器呈现网络的结构就是多对多，实际上任务涵盖范围很广，可以指完整的业务处理，随着业务越来越复杂，这种仅仅增加服务器来达到提升性能已经办不到了，这时候就需要任务分解,就是将不同的任务进行分类然后分给不同的服务器，这个就是分工的原理啊，但也不是拆分的越细越好，因为系统间调用次数呈指数级别上升。

复杂度来源之一：高可用

这个定义的关键在于“无中断”，但恰好难在’无中断’上面，因为无论是单个硬件还是单个软件，都不可能做到无中断，还有比如火灾，地震之类的

解决方案五花八门万变不离其宗就是冗余

高性能增加机器目的在于扩展处理性能;高可用增加机器目的在于“冗余”处理单元

用简单通俗点说明冗余就是多的意思

计算高可用

无论在哪台计算机上进行计算，同样的算法和输入数据，产生的结果都是一样的

存储高可用

将数据从一台机器搬到另一台机器，需要经过路线进行传输，高可用的系统要做到**“数据+逻辑=业务”**

意味着整个系统在某个时间上数据肯定是不一致的，业务表现也就是不一致，存储高可用的难点不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响。

分布式领域有一个著名的cap定理，从理论上论证了存储高可用的复杂度，也就是说存储高可用不能同时满足**“一致性，可用性，分区容错性”**，最多满足其中两个

高可用状态决策

无论是计算高可用还是存储高可用，其基础都是**“状态决策”**，即系统需要判断当前的状态是正常还是异常，如果出现异常就要采取行动来保证高可用，通过冗余来实现高可用系统，状态决策本质上就不可能做到完全正确

独裁式

独裁式决策指的是存在一个独立决策主体，我们姑且称它为“决策者”，冗余个体为上报者，都将状态信息发送给决策者，当状态决策者出现失误就会导致异常情况发生
协商式

协商式决策指的是两个独立的个体通过交流信息然后根据规则进行决策，最常见的协商方式就是主备决策，一旦两者连接的中断而不是出现故障，备用机也就会变成主机，但这个是不被允许的
民主式

民主式决策指的是多个独立的个体通过投票的方式来进行状态决策，集群容易造成脑裂，就是集群的连接中断导致出现两个主机

可扩展性

由于软件系统固有的多变性，新的需求总在不断提出来，可扩展性显得尤其重要，在软件开发领域，面向对象思想的提出，就是为了解决可扩展性带来的问题；后来的设计模式更是将可扩展性做到了极致，得益于设计模式的巨大影响力

设计具备良好可扩展性的系统，有两个基本条件：正确预测变化，完美封装变化

预测变化

软件系统与硬件或者建筑相比，有一个很大差异：软件系统在发布后还可以不断地修改和演进，这就意味着不断有新的，需求需求实现，预测变化的复杂性在于：

不能每个设计点都考虑可扩展性

不能完全不考虑可扩展性

所有预测都存在出错的可能性

应对变化

不管是多么高明的架构师，也总会赶不上变化，客户的需求。。。千奇百怪，除了预测变化，接着就是采取什么方案来应对变化。

第一种是应对变化的将变化封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”

（项目的业务最好是按照性质然后进行分类，分模块，对应后端最好就进行分目录按照模块来进行分）

系统需要拆分出稳定层，变化层（基于通常就会产生出框架，基于业务性就会产生出各种模块，模块和组件最好达成一致就是封装成一起，这样不仅能减少耦合还能够更方便）

稳定层指向变化层就像是jdbc指向各种数据库，相对于变化的部分，人更喜欢接触的稳定的部分

第二种常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”，抽象层是稳定的，实现层可以根据具体业务需求定制开发，引出来的就是设计模式

复杂度来源：低成本，安全，规模

低成本

当设计“高性能，高可用”的架构通常手段手段都是增加更多服务器来满足；而降低成本正好与此相反，通过减少服务器才能达成降低成本的目标，本质上与高性能，高可用冲突，降低成本不是首要满足的目标，通常是附加的，在现实世界中都会基于成本，在此基础上提出高性能，高可用，如果预设定成本实在无法满足就得提了，要么就是创新。

Hadoop 的出现是为了解决传统文件系统无法应对海量数据存储和计算的问题
全文搜索引擎（Sphinx、Elasticsearch、Solr）的出现是为了解决关系型数据库 like 搜
索的低效的问题
NoSQL（Memcache、Redis 等）的出现是为了解决关系型数据库无法应对高并发访问
带来的访问压力

但硬件受到约束时，就要软件程序上去创新或者是引进新技术

安全

安全本身是一个庞大而又复杂的技术领域

功能安全

常见的xss攻击，csrf攻击，sql注入，window漏洞，密码破解等，本质上是因为系统现有漏洞，都是利用系统或者家中不完善的地方潜入，功能安全其实就是所谓的防小偷
架构安全

架构安全就是防强盗，传统的架构安全要依靠防火墙，防火墙最基本就是隔离网络，通过将网络划分成不同区域

防火墙在传统的行业如银行，企业应用领域应用较多，但互联网领域，防火墙应用场景并不多，例如ddos攻击会消耗掉宽带资源，对于用户而言就是完全访问不到

规模

很多企业级的系统，没有性能，扩展性，这样系统就会好复杂（如果设计人员有提前想好扩展性，高性能这些的话），这样导致后来很混乱，不敢改，说白点就是不知道功能，看不懂，不敢改，这样是最麻烦的

规模带来的复杂度的主要原因就是“量变引发质变”
功能越多导致复杂度越大，呈现出指数级别上升，如同三个功能模块之间的连接也就是3条，而八个功能模块之间的连接就是多了30 例如：mysql单表存储最好是在500万行左右