架构理论思维导图模板_ProcessOn思维导图、流程图

架构是什么

概念

系统

子系统

模块

组件

框架

架构

不同的角度

业务逻辑架构

物理硬件架构

开发规范

架构的历史背景

软件事故

软件语言发展

系统业务复杂

架构的目的

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

识别系统复杂度到底是什么

针对性解决问题

复杂度来源

高性能

单机

考虑技术

多线程

多进程

线程间通信

多线程并发

例子

Nginx可以使用多进程或多线程

redis使用单进程

jboss采用多线程

memcache采用多线程

思路

具体场景具体分析

集群

任务分配

概念

每个节点上都能处理完成业务任务

不同任务分配到不同机器处理

实现

加任务分配中心

nginx

HAProxy

嵌入程序中的算法

...

任务分配中心与业务服务器的交互

建立连接

检测连接

中断连接

超时处理

任务分配算法

轮询算法

按权重

按负载

按服务器

处理完业务要不要返回

效率

按80%算

如果不够再加

加业务服务器

效率递减

1变2 2变10 10变100

性能瓶颈

加任务分配中心

master

通信

选举

其他问题...

任务分解

业务逻辑拆分

简单系统更容易做到高性能

更容易进行针对性优化

不容易耦合，对其他业务造成影响

可以针对单个业务进行扩展

风险小

为单个业务加机器可以解决大多数问题

不可过度拆分

调用次数随服务数量指数型增加性能降低

影响系统性能的事业务逻辑本身

一个业务怎么拆分都有性能上限拆分业务职能逼近上限不能突破上限

高可用

各种问题

通过冗余实现高可用

增加机器

冗余处理单元

计算高可用

增加一个任务分配器

性能

成本

可维护性

可用性

任务分配器和业务服务器连接

建立连接

交互

中断

检测

重连

任务分配器的分配算法

主备

冷备

温备

热备

主主

备备

n主n备

zookeeper

memcache

存储高可用

网络延迟随地理位置改变而变大

数据+逻辑=业务

原因

正常的网络延迟

其他异常情况

真正难点

不在于如何备份数据

在于如何减少或规避数据不一致对业务造成的影响

cap定理

一致性

可用性 

分区容错性

根据业务三选二

状态决策

独裁式

决策者

存在一个独立的决策主体

负责收集信息然后进行决策

上报者

所有冗余的个体

将状态信息发送给决策者

如果决策者出现问题就无法实现状态决策

协商式

两个独立个体通过交流通信们根据规则进行决策

主备决策

民主式

选举产生master

两个大脑

过半选举

可用性降低

不可能完全没问题

可扩展性

正确如此变化

系统需要不断的修改和演进

唯一不变的事变化

预测意味着不是每次都是对的如果预测错误架构设计白做，工作量白费

复杂性

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

不能完全不考虑可扩展性

所有预测都有可能出错

把握预测程度，提升准确预测结果

只凭经验，凭对业务的了解程度

完美封装变化

方案和实施是两回事

变化封装在变化层，不变的部分封装在稳定层

剥离变化层和稳定层的后果

变化层和稳定层不明确

需要在变化层和稳定层直接设立接口

稳定层越稳定越好

变化层需要找出多个实现的共同点

提炼出一个抽象层，一个实现层

面向对象的设计思路

设计模式

加了多个类

可读性差

以后只能按设计好的模式开发

灵活的设计本身就是复杂的事

低成本

节约成本

通过架构，减少机器

和高性能，高可用冲突

是项目架构的附加条件

创新

引入新技术

并发问题

nosql

redis

memcache

全文搜索引擎

sphinx

elasticsearch

海量数据存储计算

hadoop

没有就造新技术

facebook

HipHop PHP

新浪

SSDCache 二级缓存

kafka

ruby

go

安全

功能性安全

本质是系统漏洞

架构性安全

靠防火墙

网络分区

访问控制策略

运营商

云服务商

规模

量变引起质变

功能越来越多

复杂度指数增长

数据越来越多

单表数据量大

加索引慢

修改表结构慢

查询慢

备份慢

拆分表

以什么拆分

如何查询

...

系统复杂

业务逻辑多

迭代周期长

不熟悉发展史

不熟悉功能

架构设计三原则

问题

不确定性

编程知道确定的结果

架构需要选择权衡

没有行业规范

合适原则

合适优于行业领先

没那么多人想干那么多活

没有积累没有采坑想一步登天<br>

量变引起质变架构是为业务服务的，没有卓越的业务场景，想灵光一闪成为天才

简单原则

复杂代表问题

结构的复杂性

组件数量越来越多

组件之间的关系越来越复杂

某个组件的改动会关联其他组件

定位问题难，解决问题可能会关其他组件，牵一发动全身

逻辑的复杂性

单个组件承担太多功能

功能组件采用复杂的算法

其他复杂的东西越复杂功能越强

因为设计好了不会变

程序越复杂越有问题

程序随时间变化而变化最终不可修改

演化原则

演化优越一步到位

建筑架构描述建筑的各个结构

一旦完成架构从施工开始就不能在变

程序架构描述程序的各个模块

随着业务发展而发展

根本问题

软件架构会随着业务需求不断发展

平台技术

职责

配置

机器管理

ip地址管理

虚拟机管理

部署

发布

打包

回滚

监控

收集后台运行相关数据并进行监控

应急

下线

停止程序

切换ip

设计要素

标准化

规范流程

制定标准

是运维平台的基础

中间件来规范

平台化

标准版固化到平台上，无需运维人员死记硬背标准

平台操作简单方便，人工复杂易出错

平台可复用

自动化

人工运维执行大量的重复操作

平台重复操作固化，自动完成

可视化

提示查询数据效率

测试平台

用例管理

通过脚本重复执行测试用例

资源管理

测试用例要放到具体环境才能运行

使用docker，虚拟机等充分利用资源

任务管理

将测试用例分配到具体的资源上去

数据管理

展示当前用例执行情况

对比代码发展趋势

数据挖掘需求分析

数据平台

数据管理

数据采集

从业务系统中收集数据

数据存储

存储后用与数据分析

数据访问

提供各种协议的用与读写的数据

hive

sql

key-value

数据安全

数据平台多个业务共享

加密保护敏感信息

数据分析

数据统计

从原始数据中统计出总览数据

数据挖掘

根据数据分析出隐藏的规律

机器学习

统计学

数据应用

根据大数据做一些用价值的业务

管理平台

权限管理

身份认证

统一认证登录

权限控制

登录人员的权限