《从 0 开始学架构》学习归整(一)复杂度问题的来源 低成本、安全、规模篇

内容纲要

低成本

在设计高可用高性能的机构时,基本上都是采用增加机器的做法,这跟低成本是正好相反的,因此,在设计系统时,低成本不是首要目标,是高性能、高可用的约束(在高性能、高可用架构方案无法满足成本条件时,需要重新设计或者报告老板)。

低成本的复杂度

  • 引入新技术(学习成本)
  • 如果无法找到已有的能降低成本的新技术,只能自己创造,创造新技术的成本极高(人才、时间等)

知名“创新”项目 ↓

  • NoSQL(Memcached、Redis 等)
    • 解决关系型数据库无法应对高并发访问带来的压力
  • Kafka
    • Linkedin 为了处理每天 5 千亿的事件

安全

安全关系到整套系统的运行,数据的安全性、完整性,业务是否能够正常展开,甚至公司能否抵御危害安全的事件发生,并在安全事件中存活下来。

安全的复杂度

由于技术缺陷、历史遗留等诸多问题,安全漏洞层出不穷(黑客大佬们日以继夜、孜孜不倦的发掘新漏洞)。

安全分类

功能安全

功能安全其实就是防“小偷”

功能安全关系的是局部的安全,基本只与编码相关,现在很多通用框架里都带了基础安全防护功能(XSS 攻击、SQL 注入等),但只能预防已知安全漏洞,对未知的安全隐患无法预知,所以只能在攻防大战中逐步完善。

架构安全

架构安全需要关注的是系统整体的安全,需要照顾到整套系统中的各个环节。

架构安全需要关注的内容

网络安全

ε=(´ο`*))) 没梳理清楚,留坑待补

数据安全
  • 数据完整性
    • 使用事务机制保证数据完整性
    • 使用数据质量管理工具对数据进行校验
    • 在监测到数据完整性遭到破坏时想办法恢复
  • 数据保密性
    • 系统身份、鉴别信息,敏感业务数据在传输、存储、处理过程中使用专业的加密技术、安全的传输技术等
  • 数据备份和恢复
    • 使用异地多备方案
    • 在资源消耗和数据安全之间权衡备份时间间隔
    • 在系统出现故障时,自动进行业务切换和恢复
应用安全
  • 身份鉴别
  • 访问控制
  • 安全审计
  • 剩余信息保护
  • 通信完整性
  • 通信保密性
  • 抗抵赖
  • 软件容错
  • 资源控制
  • 代码安全

规模

规模的复杂度

规模的复杂度主要是量变引起质变

功能越来越多

如果子系统(功能)间存在互相依赖关系,复杂度将指数级上升。

数据越来越多

数据多将导致:索引困难,修改耗时,备份耗时等问题。

参考资料

安全架构总体方案

Tags:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注