【架构学习（一）】架构设计目的及复杂度来源

---

前言

作为后端开发应该对整体系统架构有一定了解。所以需要学习有关软件系统架构知识。我采用读书的方式去了解整体软件系统架构，所读书名《从零开始学架构》。
学习目标：
1.架构设计目的及复杂度来源
2.架构设计流程
3.高性能架构
4.CAP理论和FMEA方法
5.高可用架构
6.可扩展架构
7.微服务架构最佳实践
8.物联网架构技术

写此博客的目的：
1.完成学习目标
2.对书中内容进行总结，得到自己的阅读心得
3.方便其他入门小伙伴快速得到干货
4.方便自己回顾架构知识

下期连接：【架构学习（二）】架构设计流程

---

架构设计的目的

架构：软件架构指软件系统的顶层结构
架构设计的目的：架构设计是为了解决软件复杂度
1）架构设计是和开发效率，需求紧密相连（投入时间和人力）不是说所有项目都需要架构。
2）不要为了架构而架构（高性能、高可用、可扩展）先跑起来更重要。
3）架构应该针对性解决问题，对系统最复杂的地方（通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计）进行架构设计。
4）在评估一个系统复杂度是否需要架构时，需要从如下几个方面去考虑：
1} 性能（pqs - > 存储 mysql，缓存redis，网关）
2} 可拓展性（功能稳定性是否总变动）
3} 高可用（宕机，负载均衡，数据（mysql跨机房同步））
4} 安全性（隐私，密码，脱敏）
5} 成本（服务器，时间，人力）

---

架构设计复杂度来源

一、复杂度来源：高性能

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

单机复杂度：
需要考虑如多进程、多线程、进程间通信、多线程并发等技术点。（举一个最简单的例子：Nginx 可以用多进程也可以用多线程，Redis采用的是单进程，Memcache采用的是多线程，这些系统都实现了高性能，但内部实现差异却很大。）

集群的复杂度：

1. 任务分配：任务分配的意思是指每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上执行。
   1）所以需要任务分配器，如负载均衡软件（Nginx）。
   2）集群架构模型变为1任务分配器–N服务器
   3）任务分配器需要综合考虑分配算法、性能、成本、可维护性、可用性等各方面的因素。
   4）当性能要求再次提升，任务分配器出现性能瓶颈时，集群架构模型变为 N对N
   

2. 任务分解
   1）够把原来大一统但复杂的业务系统，拆分成小而简单但需要多个系统配合的业务系统。
   为何通过任务分解就能够提升性能呢？
   1）简单的系统更加容易做到高性能
   2）可以针对单个任务进行扩展（可以是代码优化，也可以简单粗暴地加机器）
   

3）大系统不是拆的越细越好，因为系统之间是网络通讯，网络通讯次数多回降低性能

---

二、复杂度来源：高可用

高可用：统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元。（机器一直可用所以需要有机器备份）

计算高可用
高可用量化指标 可用率99.99% 相应时间xxxms
1）几个主服务，几个备份服务（ZooKeeper 采用的就是 1 主多备，而 Memcached 采用的就是全主 0 备）
存储高可用
1）“数据 + 逻辑 =业务”同步备份数据时候应考虑规避数据不一致对业务造成的影响（比如了物理上的传输速度限制，传输线路本身也存在可用性问题）
2）CAP 定理 ： 一致性、可用性、分区容错性
高可用状态决策（集群策略）

1）独裁式
独裁式决策指的是存在一个独立的决策主体，我们姑且称它为“决策者”，负责收集信息然后进行决策；所有冗余的个体，我们姑且称它为“上报者”，都将状态信息发送给决策者

2）协商式
协商式决策指的是两个独立的个体通过交流信息，然后根据规则进行决策，最常用的协商式决策就是主备决策。

3）民主式
民主式决策指的是多个独立的个体通过投票的方式来进行状态决策。例如，ZooKeeper集群在选举leader时就是采用这种方式。

民主式决策还有一个固有的缺陷：脑裂。（民主式决策的系统一般都采用“投票节点数必须超过系统总节点数一半”规则来处理。这个方法也不是万能的，如果节点宕机超过半数集群直接不可用，就更谈不上高性能了）

---

三、复杂度来源：可扩展性

面向对象思想的提出，就是为了解决可扩展性带来的问题；后来的设计模式，更是将可扩展性做到了极致。
预测变化的复杂性在于：
1）不能每个设计点都考虑可扩展性。
2）不能完全不考虑可扩展性。
3）所有的预测都存在出错的可能性。

应对变化
可将服务架构分为两个独立的层，变化层和稳定层，而变化层和稳定层的顺序是根据需求来的（多种存储方式那稳定层在上，多种接入方式稳定层在下）
1）系统需要拆分出变化层和稳定层
2）需要设计变化层和稳定层之间的接口（第二种方式提炼出一个“抽象层”和一个“实现层”。抽象层是稳定的，实现层可以根据具体业务需要定制开发，当加入新的功能时，只需要增加新的实现，无须修改抽象层。这种方案典型的实践就是设计模式和规则引擎。）

---

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

低成本
本质上是与高性能和高可用冲突的，所以低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束。
低成本给架构设计带来的主要复杂度体现在，往往只有“创新”才能达到低成本目标。（NoSQL（Memcache、Redis等）的出现是为了解决关系型数据库无法应对高并发访问带来的访问压力。全文搜索引擎（Sphinx、Elasticsearch、Solr）的出现是为了解决关系型数据库 like 搜索的低效的问题。Hadoop的出现是为了解决传统文件系统无法应对海量数据存储和计算的问题。）
安全
从技术的角度来讲，安全可以分为两类：一类是功能上的安全，一类是架构上的安全。
1）功能安全 从实现的角度来看，功能安全更多地是和具体的编码相关，与架构关系不大。

2）架构安全
，互联网系统的架构安全目前并没有太好的设计手段来实现。银行是通过防火墙来进行架构安全，保证防火墙内流量的安全
规模
规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。常见的规模带来的复杂度有

1. 功能越来越多，导致系统复杂度指数级上升系统的复杂度 = 功能数量 + 功能之间的连接数量
2. 数据越来越多，系统复杂度发生质变（如mysql单表数据太大，ddl，dml都会存在问题，需要进行拆表，拆表就需要）

---

总结

软件架构设计目的是为了应对软件日益复杂的问题，具体的复杂有，随着使用人数增多，要保证软件相应处理能力，这就是高性能。随着使用人数增多，要保证软件不间断提供服务以及重要信息储存，这个就是高可用。随着用户和供应商需求不断，保证系统快速迭代开发，这个就是可拓展性。软件开发还要考虑成本问题，安全问题。

---

我的目标

希望在年底学习一下内容：
java学习内容：
1.tomcat源码
2.dubbo源码
3.zookeeper源码
4.netty源码
go学习内容：
1.gin框架学习
2.简单go项目
3.go基础知识进阶（gmp，gc，channel，map，slice源码等）
中间件学习内容：
1.kafka使用及源码
框架学习内容：
1.从零开始学架构
算法学习内容：
1.复习leetcode中top 100

我平时喜欢没事还打游戏，因为有宝宝所以希望在平时时间能尽量完成上述学习内容（希望能戒掉游戏哈哈哈）。
也希望有和我一样的一起学习的小伙伴共同学习进步，我建一个qq后端交流群：279868576，希望小伙伴们加入共同督促进步。