架构知识整理
架构知识整理
古城痴人 发表于2年前
架构知识整理
  • 发表于 2年前
  • 阅读 139
  • 收藏 14
  • 点赞 0
  • 评论 0

【腾讯云】如何购买服务器最划算?>>>   

摘要: 可以认为是读书笔记,对架构知识做了一个大纲性的整理,免得忘了。

架构概念

一套系统的软件架构就是这个系统所需的结构体的集合,包括:软件元素软件元素之间的关系,以及二者的属性

从视角不同一般分为:

  • 逻辑架构

关注于各个组件之间的关系,如:用户界面、数据库、外部系统接口

如流行的N层架构:表现层,业务逻辑层,数据层

  • 物理架构

关注于如何将软件元素放到物理设备上,如:代理服务器、Web服务器,缓存服务器、数据库服务器、NoSQL服务器、队列服务器、搜索服务器。

  • 系统架构

性能、可扩展性、伸缩性、可用性、安全性

有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。

在平衡性能、扩展性、伸缩性、可用性、安全性这5个系统架构要素下,实现系统功能需求。

架构模式

为了应对高并发访问、海量数据处理、高可靠运行等一系列问题,大型互联网公司在实战提了许多解决方案,以实现网站的高性能、高可用、易伸缩、可扩展、安全等各种技术架构目标,这些解决方案可以被重复使用,从而被抽炼成为大型网站的架构模式

分层

应用层 - 服务层 - 数据层

应用层:视图层 业务逻辑层

服务层:数据接口层 逻辑处理层

分层是逻辑上的,物理布署上根据规模决定

从一开始就要分层,因为分层对网站日后向分布式方向发展至关重要

分割

也就是纵切,把不同功能的服务分割开,包装成高内聚低偶合的模块单元,一方面有助于软件的开发和维护,一方面,便于不同模块的分布式布署。 分割粒度根据网站规模来决定,如:用户,搜索,反作弊,消息

分布式

将不同的模块布署到不同的服务器上,服务器越多,CPU,内存,存储空间资源就越多 分布式遇到的问题:

  • 性能:通过网络
  • 可用性:服务器多,宕机
  • 一致性:多台机器数据保持同步,分布式事务
  • 可维护性:机器多,网络依赖复杂

分布式分类:

  • 分布式应用和服务 将分层和分割后的模块布署到不同的服务器上。
  • 分布式静态资源 将JS、CSS、图片独立分布式布署
  • 分布式数据和存储 将产生和处理的海量数据存放到多台机器上面,MySQL,NoSQL
  • 分布式计算 后台业务,如:搜索引擎的索引构建,数据仓库的计算,Hadoop、Mapreduce
  • 分布式配置、分布式锁、分布式文件系统。。。。

集群

** 将多台服务器布署相同的应用,这一堆服务器叫集群。** 使用集群的目的:

  • 高可用
  • 高性能

缓存

将数据放到离计算最近的位置,可以提高访问速度,缓存后端的计算压力

本机缓存由远而近是:一级缓存,二级缓存、三级缓存、内存

** 缓存种类:**

  • CDN
  • 反向代理
  • 本地缓存
  • 分布式缓存

** 使用缓存的前提:**

  • 数据访问热点不均衡,部分数据会被频繁访问,需要使用缓存:HTML的最新20条动态
  • 数据不会很快过期,否则会产生脏数据

** 数据库的设计都是按照有缓存的负载前提下设计的。**

异步

主要是为了解耦,使用队列

类和类之间解偶:接口

模块与模块之间解偶:队列

异步的好处:

  • 提高可用性

  • 增高响应速度

  • 消除并发访问高峰

** 问题:可能会对用户体验、业务流程造成影响 **

冗余

高可用的手段:冗余

应用服务:集群

数据:定期备份、主从结构对数据实时热备、灾备数据中心

自动化

开发:

  • 自动化代码管理

  • 自动化测试

  • 自动化代码审查

  • 自动化布署

  • 自动化安全检查

运维:

  • 自动化监控

  • 自动化报警

  • 自动化失效转移

  • 自动化失效恢复

  • 自动化降级

  • 自动化分配资源

安全

程序实现安全:XSS、SQL注入、编码转换

  • 通过密码、手机检验码进行身份认证;

  • 登录交易对通信数据加密

  • 验证码防止机器人程序对网站攻击

  • 敏感信息过滤:反作弊

架构指标

性能

响应时间

** 执行一个操作需要的时间 **

打开一个网站  几秒

数据查查询一次 10毫秒

机械硬盘一次寻址定位 4毫秒

机械硬盘顺序读1M数据  2毫秒

SSD顺序读1M数据  0.3毫秒

从Redis读一个数据  0.5毫秒

从内存读1M数据  10多微秒

Java程序本地方法调用  几微秒

** CPU操作时间 **

从CPU到	大约需要的CPU周期	大约需要的时间(单位ns)

寄存器	1 cycle	

L1 Cache	~3-4 cycles	~0.5-1 ns

L2 Cache	~10-20 cycles	~3-7 ns

L3 Cache	~40-45 cycles	~15 ns

跨槽传输		~20 ns

内存	~120-240 cycles	~60-120ns

网络传输2K数据   1微秒

** 并发数 **

同时处理请求的数目

** 吞吐量 **

单位时间内系统处理的请求数量,如请求数/秒,页面数每秒,访问人数每天,

一些高大上的指标:

  • TPS:每秒处理事务数

  • HPS:每秒HTTP请求数

  • QPS:每秒的查询数

** 性能计数器 **

运维人员关注的指标,服务器或操作系统的性能指标,如:系统负载(top命令),对象与线程数、内存使用情况、CPU使用情况,磁盘IO,网络IO。这些指标超出阈值后,系统都可能会出问题。

优化:

** 前端优化 **

  • 减少http请求/使用浏览器缓存/压缩/CSS放上面,JS放下面/减少Cookie传统

  • CDN加速/反向代理

  • 缓存优化

  • 异步队列

  • 集群

** 代码优化 **

  • 多线程/内存/

  • 存储优化

  • SSD/分布式文件系统

扩展性

对现有系统影响最小的情况下,系统功能可以持续扩展和提升的能力。

高扩展性的关键是:高内聚,低耦合 -> 模块拆分

  • 分布式消息队列

  • 分布式服务

** 大型网站遇到的问题:**

  • 编译、布署困难:代码多,编译时间长,布署机器多

  • 代码分支管理困难:复用代码的修改经常会造成冲突

  • 数据库连接耗尽:

  • 新增业务困难:在一个乱如麻的系统中增加新业务,维护旧功能异常痛苦,一脚全是雷,大家干的热火朝天,就是问题多多。

** 解决方法:拆、拆、拆 (重要的事情要说3遍) **

  • 拆成低耦合的模块,独立布署。

  • 纵拆:将大应用拆为多个小应用独立布署

  • 横拆:将复用的业务拆分出来,独立布署,对外提供稳定的接口。

服务提供者启动后在服务注册中心注册,服务消费者想使用某项服务时,先从服务注册中心获取服务提供者列表,找到服务的接口,然后根据负载均衡策略将服务请求发送到对应的服务器上。

** 可扩展的数据结构 **

NOSQL:CouchBase、MongoDB、HBase

** 利用开放平台建设网站生态圈 **

OpenAPI

伸缩性

不需要改变软件的软硬件设计,只需要布署服务器数量就可以扩大或缩小服务处理能力。

根据功能进行物理分离实现伸缩:横向分离:不同的业务模块分离布署、纵向分离:业务流程分离布署

单一功能通过集群来实现伸缩:一头牛拉不动时,不找更强壮的牛,而是找两头牛

** 应用服务器集群的伸缩性设计 **

  • Http重定向:302

  • DNS域名解析:二级域名

  • 反向代理负载:Nginx

  • IP负载均衡

  • 数据链路层负载均衡:LVS

** 分布式缓存集群的伸缩性设计 **

  • 一致性Hash算法

** 数据库伸缩性设计 **

  • 主从架构

  • 读写分离

** NoSQL **

  • HBase的的HRegion的分裂

可用性

可用性就是不出故障。

不可用时间=故障修复时间点-故障发现时间点

** 可用性指标=(1-不可用时间/总时间)*100% **

2个9基本可用,88小时

3个9是较高可用,小于9小时

4个9是高可用,53分钟

5个9是极高可用,5分钟

** 可用性 **

** 业务拆分 **

  • 无状态应用:负载均衡、Session管理

  • 基础服务高可用:分级管理、超时设置、异步调用、服务降级、幂等性设计

  • 数据高可用:数据备份、失效转移

安全性

XSS(跨站点脚本攻击):消毒

注入攻击:请求参数消毒,参数绑定

CSRF(跨站点请求伪造):表单Token、验证码、Referer检查

加密:

单向散列加密:Md5 SHA   使用彩虹表

对称加密:交换密钥是难题

非对称加密:公钥加密,私钥解密
标签: 架构 高可用 集群
共有 人打赏支持
粉丝 15
博文 16
码字总数 19276
×
古城痴人
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: