后端架构师技术图谱(六)-基础架构

大数据

流式计算

Storm

• 官方网站
• 《最详细的Storm入门教程》

Flink

• 《Flink之一 Flink基本原理介绍》

Kafka Stream

• 《Kafka Stream调研：一种轻量级流计算模式》

应用场景

例如：

• 广告相关实时统计；
• 推荐系统用户画像标签实时更新；
• 线上服务健康状况实时监测；
• 实时榜单；
• 实时数据统计。

Hadoop

• 《用通俗易懂的话说下hadoop是什么,能做什么》
• 《史上最详细的Hadoop环境搭建》

HDFS

• 《【Hadoop学习】HDFS基本原理》

MapReduce

• 《用通俗易懂的大白话讲解Map/Reduce原理》
• 《 简单的map-reduce的java例子》

Yarn

• 《初步掌握Yarn的架构及原理》

Spark

• 《Spark(一): 基本架构及原理》

安全

web 安全

XSS

• 《xss攻击原理与解决方法》

CSRF

• 《CSRF原理及防范》

SQL 注入

• 《SQL注入》

Hash Dos

• 《邪恶的JAVA HASH DOS攻击》
  • 利用JsonObjet 上传大Json，JsonObject 底层使用HashMap；不同的数据产生相同的hash值，使得构建Hash速度变慢，耗尽CPU。
• 《一种高级的DoS攻击-Hash碰撞攻击》
• 《关于Hash Collision DoS漏洞：解析与解决方案》

脚本注入

• 《上传文件漏洞原理及防范》

漏洞扫描工具

• 《DVWA》
• W3af
• OpenVAS详解

验证码

• 《验证码原理分析及实现》

• 《详解滑动验证码的实现原理》

  • 滑动验证码是根据人在滑动滑块的响应时间，拖拽速度，时间，位置，轨迹，重试次数等来评估风险。

• 《淘宝滑动验证码研究》

DDoS 防范

• 《学习手册：DDoS的攻击方式及防御手段》
• 《免费DDoS攻击测试工具大合集》

用户隐私信息保护

1. 用户密码非明文保存，加动态slat。
2. 身份证号，手机号如果要显示，用 “*” 替代部分字符。
3. 联系方式在的显示与否由用户自己控制。
4. TODO

• 《个人隐私包括哪些》

• 《在互联网上，隐私的范围包括哪些？》

• 《用户密码保存》

序列化漏洞

• 《Lib之过？Java反序列化漏洞通用利用分析》

加密解密

对称加密

• 《常见对称加密算法》
  • DES、3DES、Blowfish、AES
  • DES 采用 56位秘钥，Blowfish 采用1到448位变长秘钥，AES 128，192和256位长度的秘钥。
  • DES 秘钥太短（只有56位）算法目前已经被 AES 取代，并且 AES 有硬件加速，性能很好。

哈希算法

• 《常用的哈希算法》

  • MD5 和 SHA-1 已经不再安全，已被弃用。
  • 目前 SHA-256 是比较安全的。

• 《基于Hash摘要签名的公网URL签名验证设计方案》

非对称加密

• 《常见非对称加密算法》

  • RSA、DSA、ECDSA(螺旋曲线加密算法)

  • 和 RSA 不同的是 DSA 仅能用于数字签名，不能进行数据加密解密，其安全性和RSA相当，但其性能要比RSA快。

  • 256位的ECC秘钥的安全性等同于3072位的RSA秘钥。

    《区块链的加密技术》

服务器安全

• 《Linux强化论：15步打造一个安全的Linux服务器》

数据安全

数据备份

TODO

网络隔离

内外网分离

TODO

登录跳板机

在内外环境中通过跳板机登录到线上主机。

• 《搭建简易堡垒机》

授权、认证

RBAC

• 《基于组织角色的权限设计》
• 《权限系统与RBAC模型概述》
• 《Spring整合Shiro做权限控制模块详细案例分析》

OAuth2.0

• 《理解OAuth 2.0》

双因素认证（2FA）

2FA - Two-factor authentication，用于加强登录验证

常用做法是 登录密码 + 手机验证码（或者令牌Key，类似于与网银的 USB key）

• 【《双因素认证（2FA）教程》】(http://www.ruanyifeng.com/blog/2017/11/2fa-tutorial.html)

单点登录(SSO)

• 《单点登录原理与简单实现》

• CAS单点登录框架

常用开源框架

开源协议

• 《开源协议的选择》

• 如何选择一个开源软件协议

日志框架

Log4j、Log4j2

• 《log4j 详细讲解》
• 《log4j2 实际使用详解》
• 《Log4j1,Logback以及Log4j2性能测试对比》
  • Log4J 异步日志性能优异。

Logback

• 《最全LogBack 详解、含java案例和配置说明》

ORM

• 《ORM框架使用优缺点》
  • 主要目的是为了提高开发效率。

MyBatis：

• 《mybatis缓存机制详解》

  • 一级缓存是SqlSession级别的缓存，缓存的数据只在SqlSession内有效
  • 二级缓存是mapper级别的缓存，同一个namespace公用这一个缓存，所以对SqlSession是共享的；使用 LRU 机制清理缓存，通过 cacheEnabled 参数开启。

• 《MyBatis学习之代码生成器Generator》

网络框架

TODO

Web 框架

Spring 家族

Spring

• Spring 简明教程

Spring Boot

• 官方网站
• 《Spring Boot基础教程》

Spring Cloud

• Spring Boot 中文索引站
• Spring Cloud 中文文档
• 《Spring Cloud基础教程》

工具框架

• 《Apache Commons 工具类介绍及简单使用》
• 《Google guava 中文教程》

分布式设计

扩展性设计

• 《架构师不可不知的十大可扩展架构》

  • 总结下来，通用的套路就是分布、缓存及异步处理。

• 《可扩展性设计之数据切分》

  • 水平切分+垂直切分
  • 利用中间件进行分片如，MySQL Proxy。
  • 利用分片策略进行切分，如按照ID取模。

• 《说说如何实现可扩展性的大型网站架构》

  • 分布式服务+消息队列。

• 《大型网站技术架构（七）--网站的可扩展性架构》

稳定性 & 高可用

• 《系统设计：关于高可用系统的一些技术方案》

  • 可扩展：水平扩展、垂直扩展。 通过冗余部署，避免单点故障。
  • 隔离：避免单一业务占用全部资源。避免业务之间的相互影响 2. 机房隔离避免单点故障。
  • 解耦：降低维护成本，降低耦合风险。减少依赖，减少相互间的影响。
  • 限流：滑动窗口计数法、漏桶算法、令牌桶算法等算法。遇到突发流量时，保证系统稳定。
  • 降级：紧急情况下释放非核心功能的资源。牺牲非核心业务，保证核心业务的高可用。
  • 熔断：异常情况超出阈值进入熔断状态，快速失败。减少不稳定的外部依赖对核心服务的影响。
  • 自动化测试：通过完善的测试，减少发布引起的故障。
  • 灰度发布：灰度发布是速度与安全性作为妥协，能够有效减少发布故障。

• 《关于高可用的系统》

  • 设计原则：数据不丢(持久化)；服务高可用(服务副本)；绝对的100%高可用很难，目标是做到尽可能多的9，如99.999%（全年累计只有5分钟）。

硬件负载均衡

• 《转！！负载均衡器技术Nginx和F5的优缺点对比》

  • 主要是和F5对比。

• 《软/硬件负载均衡产品 你知多少？》

软件负载均衡

• 《几种负载均衡算法》
  轮寻、权重、负载、最少连接、QoS

• 《DNS负载均衡》

  • 配置简单，更新速度慢。

• 《Nginx负载均衡》

  • 简单轻量、学习成本低；主要适用于web应用。

• 《借助LVS+Keepalived实现负载均衡 》

  • 配置比较负载、只支持到4层，性能较高。

• 《HAProxy用法详解 全网最详细中文文档》

  • 支持到七层（比如HTTP）、功能比较全面，性能也不错。

• 《Haproxy+Keepalived+MySQL实现读均衡负载》

  • 主要是用户读请求的负载均衡。

• 《rabbitmq+haproxy+keepalived实现高可用集群搭建》

限流

• 《谈谈高并发系统的限流》
  • 计数器：通过滑动窗口计数器，控制单位时间内的请求次数，简单粗暴。
  • 漏桶算法：固定容量的漏桶，漏桶满了就丢弃请求，比较常用。
  • 令牌桶算法：固定容量的令牌桶，按照一定速率添加令牌，处理请求前需要拿到令牌，拿不到令牌则丢弃请求，或进入丢队列，可以通过控制添加令牌的速率，来控制整体速度。Guava 中的 RateLimiter 是令牌桶的实现。
  • Nginx 限流：通过 limit_req 等模块限制并发连接数。

应用层容灾

• 《防雪崩利器：熔断器 Hystrix 的原理与使用》

  • 雪崩效应原因：硬件故障、硬件故障、程序Bug、重试加大流量、用户大量请求。
  • 雪崩的对策：限流、改进缓存模式(缓存预加载、同步调用改异步)、自动扩容、降级。
  • Hystrix设计原则：
    • 资源隔离：Hystrix通过将每个依赖服务分配独立的线程池进行资源隔离, 从而避免服务雪崩。
    • 熔断开关：服务的健康状况 = 请求失败数 / 请求总数，通过阈值设定和滑动窗口控制开关。
    • 命令模式：通过继承 HystrixCommand 来包装服务调用逻辑。

• 《缓存穿透，缓存击穿，缓存雪崩解决方案分析》

• 《缓存击穿、失效以及热点key问题》

  • 主要策略：失效瞬间：单机使用锁；使用分布式锁；不过期；
  • 热点数据：热点数据单独存储；使用本地缓存；分成多个子key；

跨机房容灾

• 《“异地多活”多机房部署经验谈》

  • 通过自研中间件进行数据同步。

• 《异地多活（异地双活）实践经验》

  • 注意延迟问题，多次跨机房调用会将延时放大数倍。
  • 建房间专线很大概率会出现问题，做好运维和程序层面的容错。
  • 不能依赖于程序端数据双写，要有自动同步方案。
  • 数据永不在高延迟和较差网络质量下，考虑同步质量问题。
  • 核心业务和次要业务分而治之，甚至只考虑核心业务。
  • 异地多活监控部署、测试也要跟上。
  • 业务允许的情况下考虑用户分区，尤其是游戏、邮箱业务。
  • 控制跨机房消息体大小，越小越好。
  • 考虑使用docker容器虚拟化技术，提高动态调度能力。

• 容灾技术及建设经验介绍

容灾演练流程

• 《依赖治理、灰度发布、故障演练，阿里电商故障演练系统的设计与实战经验》
  • 常见故障画像
  • 案例：预案有效性、预案有效性、故障复现、架构容灾测试、参数调优、参数调优、故障突袭、联合演练。

平滑启动

• 平滑重启应用思路
  1.端流量（如vip层）、2. flush 数据(如果有)、3, 重启应用

• 《JVM安全退出（如何优雅的关闭java服务）》
  推荐推出方式：System.exit，Kill SIGTERM；不推荐 kill-9；用 Runtime.addShutdownHook 注册钩子。

• 《常见Java应用如何优雅关闭》
  Java、Srping、Dubbo 优雅关闭方式。

数据库扩展

读写分离模式

• 《Mysql主从方案的实现》

• 《搭建MySQL主从复制经典架构》

• 《Haproxy+多台MySQL从服务器(Slave) 实现负载均衡》

• 《DRBD+Heartbeat+Mysql高可用读写分离架构》

  • DRDB 进行磁盘复制，避免单点问题。

• 《MySQL Cluster 方式》

分片模式

• 《分库分表需要考虑的问题及方案》

  • 中间件： 轻量级：sharding-jdbc、TSharding；重量级：Atlas、MyCAT、Vitess等。
  • 问题：事务、Join、迁移、扩容、ID、分页等。
  • 事务补偿：对数据进行对帐检查;基于日志进行比对;定期同标准数据来源进行同步等。
  • 分库策略：数值范围；取模；日期等。
  • 分库数量：通常 MySQL 单库 5千万条、Oracle 单库一亿条需要分库。

• 《MySql分表和表分区详解》

  • 分区：是MySQL内部机制，对客户端透明，数据存储在不同文件中，表面上看是同一个表。
  • 分表：物理上创建不同的表、客户端需要管理分表路由。

服务治理

服务注册与发现

• 《永不失联！如何实现微服务架构中的服务发现？》

  • 客户端服务发现模式：客户端直接查询注册表，同时自己负责负载均衡。Eureka 采用这种方式。
  • 服务器端服务发现模式：客户端通过负载均衡查询服务实例。

• 《SpringCloud服务注册中心比较:Consul vs Zookeeper vs Etcd vs Eureka》

  • CAP支持：Consul（CA）、zookeeper（cp）、etcd（cp） 、euerka（ap）
  • 作者认为目前 Consul 对 Spring cloud 的支持比较好。

• 《基于Zookeeper的服务注册与发现》

  • 优点：API简单、Pinterest，Airbnb 在用、多语言、通过watcher机制来实现配置PUSH，能快速响应配置变化。

服务路由控制

• 《分布式服务框架学习笔记4 服务路由》
  • 原则：透明化路由
  • 负载均衡策略：随机、轮询、服务调用延迟、一致性哈希、粘滞连接
  • 本地路由有限策略：injvm(优先调用jvm内部的服务)，innative(优先使用相同物理机的服务),原则上找距离最近的服务。
  • 配置方式：统一注册表；本地配置；动态下发。

分布式一致

CAP 与 BASE 理论

• 《从分布式一致性谈到CAP理论、BASE理论》
  • 一致性分类：强一致(立即一致)；弱一致(可在单位时间内实现一致，比如秒级)；最终一致(弱一致的一种，一定时间内最终一致)
  • CAP：一致性、可用性、分区容错性(网络故障引起)
  • BASE：Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）
  • BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

分布式锁

• 《分布式锁的几种实现方式》

  • 基于数据库的分布式锁：优点：操作简单、容易理解。缺点：存在单点问题、数据库性能够开销较大、不可重入；
  • 基于缓存的分布式锁：优点：非阻塞、性能好。缺点：操作不好容易造成锁无法释放的情况。
  • Zookeeper 分布式锁：通过有序临时节点实现锁机制，自己对应的节点需要最小，则被认为是获得了锁。优点：集群可以透明解决单点问题，避免锁不被释放问题，同时锁可以重入。缺点：性能不如缓存方式，吞吐量会随着zk集群规模变大而下降。

• 《基于Zookeeper的分布式锁》

  • 清楚的原理描述 + Java 代码示例。

• 《jedisLock—redis分布式锁实现》

  • 基于 setnx(set if ont exists)，有则返回false，否则返回true。并支持过期时间。

• 《Memcached 和 Redis 分布式锁方案》

  • 利用 memcached 的 add（有别于set）操作，当key存在时，返回false。

分布式一致性算法

PAXOS

• 《分布式系列文章——Paxos算法原理与推导》
• 《Paxos-->Fast Paxos-->Zookeeper分析》
• 《【分布式】Zookeeper与Paxos》

Zab

• 《Zab：Zookeeper 中的分布式一致性协议介绍》

Raft

• 《Raft 为什么是更易理解的分布式一致性算法》
  • 三种角色：Leader（领袖）、Follower（群众）、Candidate（候选人）
  • 通过随机等待的方式发出投票，得票多的获胜。

Gossip

• 《Gossip算法》

两阶段提交、多阶段提交

• 《关于分布式事务、两阶段提交协议、三阶提交协议》

幂等

• 《分布式系统---幂等性设计》
  • 幂等特性的作用：该资源具备幂等性，请求方无需担心重复调用会产生错误。
  • 常见保证幂等的手段：MVCC（类似于乐观锁）、去重表(唯一索引)、悲观锁、一次性token、序列号方式。

分布式一致方案

• 《分布式系统事务一致性解决方案》
• 《保证分布式系统数据一致性的6种方案》

分布式 Leader 节点选举

• 《利用zookeeper实现分布式leader节点选举》

TCC(Try/Confirm/Cancel) 柔性事务

• 《传统事务与柔性事务》
  • 基于BASE理论：基本可用、柔性状态、最终一致。
  • 解决方案：记录日志+补偿（正向补充或者回滚）、消息重试(要求程序要幂等)；“无锁设计”、采用乐观锁机制。

分布式文件系统

• 说说分布式文件存储系统-基本架构 ？
• 《各种分布式文件系统的比较》 ？
  • HDFS：大批量数据读写，用于高吞吐量的场景，不适合小文件。
  • FastDFS：轻量级、适合小文件。

唯一ID 生成

全局唯一ID

• 《高并发分布式系统中生成全局唯一Id汇总》

  • Twitter 方案（Snowflake 算法）：41位时间戳+10位机器标识（比如IP，服务器名称等）+12位序列号(本地计数器)
  • Flicker 方案：MySQL自增ID + "REPLACE INTO XXX:SELECT LAST_INSERT_ID();"
  • UUID：缺点，无序，字符串过长，占用空间，影响检索性能。
  • MongoDB 方案：利用 ObjectId。缺点：不能自增。

• 《TDDL 在分布式下的SEQUENCE原理》

  • 在数据库中创建 sequence 表，用于记录，当前已被占用的id最大值。
  • 每台客户端主机取一个id区间（比如 1000~2000）缓存在本地，并更新 sequence 表中的id最大值记录。
  • 客户端主机之间取不同的id区间，用完再取，使用乐观锁机制控制并发。

一致性Hash算法

• 《一致性哈希算法》

设计思想 & 开发模式

DDD(Domain-driven Design - 领域驱动设计)

• 《浅谈我对DDD领域驱动设计的理解》

  • 概念：DDD 主要对传统软件开发流程(分析-设计-编码)中各阶段的割裂问题而提出，避免由于一开始分析不明或在软件开发过程中的信息流转不一致而造成软件无法交付（和需求方设想不一致）的问题。DDD 强调一切以领域（Domain）为中心，强调领域专家（Domain Expert）的作用，强调先定义好领域模型之后在进行开发，并且领域模型可以指导开发（所谓的驱动）。
  • 过程：理解领域、拆分领域、细化领域，模型的准确性取决于模型的理解深度。
  • 设计：DDD 中提出了建模工具，比如聚合、实体、值对象、工厂、仓储、领域服务、领域事件来帮助领域建模。

• 《领域驱动设计的基础知识总结》

  • 领域（Doamin）本质上就是问题域，比如一个电商系统，一个论坛系统等。
  • 界限上下文（Bounded Context）：阐述子域之间的关系，可以简单理解成一个子系统或组件模块。
  • 领域模型（Domain Model）：DDD的核心是建立（用通用描述语言、工具—领域通用语言）正确的领域模型；反应业务需求的本质，包括实体和过程；其贯穿软件分析、设计、开发 的整个过程；常用表达领域模型的方式：图、代码或文字；
  • 领域通用语言：领域专家、开发设计人员都能立即的语言或工具。
  • 经典分层架构：用户界面/展示层、应用层、领域层、基础设施层，是四层架构模式。
  • 使用的模式：
    • 关联尽量少，尽量单项，尽量降低整体复杂度。
    • 实体（Entity）：领域中的唯一标示，一个实体的属性尽量少，少则清晰。
    • 值对象（Value Object）：没有唯一标识，且属性值不可变，小二简单的对象，比如Date。
    • 领域服务（Domain Service）： 协调多个领域对象，只有方法没有状态(不存数据)；可以分为应用层服务，领域层服务、基础层服务。
    • 聚合及聚合根（Aggregate，Aggregate Root）：聚合定义了一组具有内聚关系的相关对象的集合；聚合根是对聚合引用的唯一元素；当修改一个聚合时，必须在事务级别；大部分领域模型中，有70%的聚合通常只有一个实体，30%只有2~3个实体；如果一个聚合只有一个实体，那么这个实体就是聚合根；如果有多个实体，那么我们可以思考聚合内哪个对象有独立存在的意义并且可以和外部直接进行交互；
    • 工厂（Factory）：类似于设计模式中的工厂模式。
    • 仓储（Repository）：持久化到DB，管理对象，且只对聚合设计仓储。

• 《领域驱动设计(DDD)实现之路》

  • 聚合：比如一辆汽车（Car）包含了引擎（Engine）、车轮（Wheel）和油箱（Tank）等组件，缺一不可。

• 《领域驱动设计系列（2）浅析VO、DTO、DO、PO的概念、区别和用处》

命令查询职责分离(CQRS)

CQRS — Command Query Responsibility Seperation

• 《领域驱动设计系列 (六)：CQRS》

  • 核心思想：读写分离（查询和更新在不同的方法中），不同的流程只是不同的设计方式，CQ代码分离，分布式环境中会有明显体现（有冗余数据的情况下），目的是为了高性能。

• 《DDD CQRS架构和传统架构的优缺点比较》

  • 最终一致的设计理念；依赖于高可用消息中间件。

• 《CQRS架构简介》

  • 一个实现 CQRS 的抽象案例。

• 《深度长文：我对CQRS/EventSourcing架构的思考》

  • CQRS 模式分析 + 12306 抢票案例

贫血，充血模型

• 《贫血，充血模型的解释以及一些经验》
  • 失血模型：老子和儿子分别定义，相互不知道，二者实体定义中完全没有业务逻辑，通过外部Service进行关联。
  • 贫血模型：老子知道儿子，儿子也知道老子；部分业务逻辑放到实体中；优点：各层单项依赖，结构清楚，易于维护；缺点：不符合OO思想，相比于充血模式，Service层较为厚重；
  • 充血模型：和贫血模型类似，区别在于如何划分业务逻辑。优点：Service层比较薄，只充当Facade的角色，不和DAO打交道、复合OO思想；缺点：非单项依赖，DO和DAO之间双向依赖、和Service层的逻辑划分容易造成混乱。
  • 肿胀模式：是一种极端情况，取消Service层、全部业务逻辑放在DO中；优点：符合OO思想、简化了分层；缺点：暴露信息过多、很多非DO逻辑也会强行并入DO。这种模式应该避免。
  • 作者主张使用贫血模式。

Actor 模式

TODO

响应式编程

Reactor

TODO

RxJava

TODO

Vert.x

TODO

DODAF2.0

• 《DODAF2.0方法论》
• 《DODAF2.0之能力视角如何落地》

Serverless

TODO

Service Mesh

TODO

• 《什么是Service Mesh？》

项目管理

架构评审

• 《架构设计之如何评审架构设计说明书》
• 《人人都是架构师：非功能性需求》

重构

• 《架构之重构的12条军规》

代码规范

TODO

代码 Review

制度还是制度!
另外，每个公司需要根据自己的需求和目标制定自己的 check list

• 《为什么你做不好 Code Review？》

  • 代码 review 做的好，在于制度建设。

• 《从零开始Code Review》

• 《Code Review Checklist》

• 《Java Code Review Checklist》

• 《如何用 gitlab 做 code review》

RUP

• 《运用RUP 4+1视图方法进行软件架构设计》

看板管理

• 《说说看板在项目中的应用》

SCRUM

SCRUM - 争球

• 3个角色:Product Owner(PO) 产品负责人;Scrum Master（SM），推动Scrum执行;Team 开发团队。

• 3个工件：Product Backlog 产品TODOLIST，含优先级;Sprint Backlog 功能开发 TODO LIST；燃尽图；

• 五个价值观：专注、勇气、公开、承诺、尊重。

• 《敏捷项目管理流程-Scrum框架最全总结！》

• 《敏捷其实很简单3---敏捷方法之scrum》

敏捷开发

TODO