devbox
IT小白
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

架构师权威指南-后端架构师技术图谱_后端架构师职业调研

作者：IT小白 | 2024-05-12 03:50:15

赞

踩

后端架构师职业调研

原文链接： https://github.com/xingshaocheng/architect-awesome

数据结构

（Toc generated by simple-php-github-toc ）

数据结构

队列

集合

链表、数组

字典、关联数组

栈

树

二叉树

每个节点最多有两个叶子节点。

完全二叉树

  • 《完全二叉树》
    • 叶节点只能出现在最下层和次下层，并且最下面一层的结点都集中在该层最左边的若干位置的二叉树。

平衡二叉树

左右两个子树的高度差的绝对值不超过1，并且左右两个子树都是一棵平衡二叉树。

二叉查找树（BST）

二叉查找树（Binary Search Tree），也称有序二叉树（ordered binary tree）,排序二叉树（sorted binary tree）。

红黑树

B-，B+，B*树

MySQL是基于B+树聚集索引组织表

LSM 树

LSM（Log-Structured Merge-Trees）和 B+ 树相比，是牺牲了部分读的性能来换取写的性能(通过批量写入)，实现读写之间的。Hbase、LevelDB、Tair（Long DB）、nessDB 采用 LSM 树的结构。LSM可以快速建立索引。

  • 《LSM树 VS B+树》

    • B+ 树读性能好，但由于需要有序结构，当key比较分散时，磁盘寻道频繁，造成写性能。
    • LSM 是将一个大树拆分成N棵小树，先写到内存（无寻道问题，性能高），在内存中构建一颗有序小树（有序树），随着小树越来越大，内存的小树会flush到磁盘上。当读时，由于不知道数据在哪棵小树上，因此必须遍历（二分查找）所有的小树，但在每颗小树内部数据是有序的。

  • 《LSM树（Log-Structured Merge Tree）存储引擎》

    • 极端的说，基于LSM树实现的HBase的写性能比MySQL高了一个数量级，读性能低了一个数量级。
    • 优化方式：Bloom filter 替代二分查找；compact 小数位大树，提高查询性能。
    • Hbase 中，内存中达到一定阈值后，整体flush到磁盘上、形成一个文件（B+数），HDFS不支持update操作，所以Hbase做整体flush而不是merge update。flush到磁盘上的小树，定期会合并成一个大树。

BitSet

经常用于大规模数据的排重检查。

常用算法

排序、查找算法

选择排序

冒泡排序

插入排序

快速排序

归并排序

希尔排序

TODO

堆排序

计数排序

桶排序

基数排序

按照个位、十位、百位、...依次来排。

二分查找

Java 中的排序工具

布隆过滤器

常用于大数据的排重，比如email，url 等。核心原理：将每条数据通过计算产生一个指纹（一个字节或多个字节，但一定比原始数据要少很多），其中每一位都是通过随机计算获得，在将指纹映射到一个大的按位存储的空间中。注意：会有一定的错误率。优点：空间和时间效率都很高。缺点：随着存入的元素数量增加，误算率随之增加。

字符串比较

KMP 算法

KMP：Knuth-Morris-Pratt算法（简称KMP）核心原理是利用一个“部分匹配表”，跳过已经匹配过的元素。

深度优先、广度优先

贪心算法

回溯算法

剪枝算法

动态规划

朴素贝叶斯

推荐算法

最小生成树算法

最短路径算法

并发

Java 并发

多线程

线程安全

一致性、事务

事务 ACID 特性

事务的隔离级别

  • 未提交读：一个事务可以读取另一个未提交的数据，容易出现脏读的情况。

  • 读提交：一个事务等另外一个事务提交之后才可以读取数据，但会出现不可重复读的情况（多次读取的数据不一致），读取过程中出现UPDATE操作，会多。（大多数数据库默认级别是RC，比如SQL Server，Oracle），读取的时候不可以修改。

  • 可重复读： 同一个事务里确保每次读取的时候，获得的是同样的数据，但不保障原始数据被其他事务更新（幻读），Mysql InnoDB 就是这个级别。

  • 序列化：所有事物串行处理（牺牲了效率）

  • 《理解事务的4种隔离级别》

  • 数据库事务的四大特性及事务隔离级别

  • 《MySQL的InnoDB的幻读问题 》

    • 幻读的例子非常清楚。
    • 通过 SELECT ... FOR UPDATE 解决。

  • 《一篇文章带你读懂MySQL和InnoDB》

    • 图解脏读、不可重复读、幻读问题。

MVCC

锁

Java中的锁和同步类

公平锁 & 非公平锁

公平锁的作用就是严格按照线程启动的顺序来执行的，不允许其他线程插队执行的；而非公平锁是允许插队的。

悲观锁

悲观锁如果使用不当（锁的条数过多），会引起服务大面积等待。推荐优先使用乐观锁+重试。

乐观锁 & CAS

ABA 问题

由于高并发，在CAS下，更新后可能此A非彼A。通过版本号可以解决，类似于上文Mysql 中提到的的乐观锁。

CopyOnWrite容器

可以对CopyOnWrite容器进行并发的读，而不需要加锁。CopyOnWrite并发容器用于读多写少的并发场景。比如白名单，黑名单，商品类目的访问和更新场景，不适合需要数据强一致性的场景。

RingBuffer

可重入锁 & 不可重入锁

  • 《可重入锁和不可重入锁》

    • 通过简单代码举例说明可重入锁和不可重入锁。
    • 可重入锁指同一个线程可以再次获得之前已经获得的锁。
    • 可重入锁可以用户避免死锁。
    • Java中的可重入锁：synchronized 和 java.util.concurrent.locks.ReentrantLock

  • 《ReenTrantLock可重入锁（和synchronized的区别）总结》

    • synchronized 使用方便，编译器来加锁，是非公平锁。
    • ReenTrantLock 使用灵活，锁的公平性可以定制。
    • 相同加锁场景下，推荐使用 synchronized。

互斥锁 & 共享锁

互斥锁：同时只能有一个线程获得锁。比如，ReentrantLock 是互斥锁，ReadWriteLock 中的写锁是互斥锁。共享锁：可以有多个线程同时或的锁。比如，Semaphore、CountDownLatch 是共享锁，ReadWriteLock 中的读锁是共享锁。

死锁

操作系统

计算机原理

CPU

多级缓存

典型的 CPU 有三级缓存，距离核心越近，速度越快，空间越小。L1 一般 32k，L2 一般 256k，L3 一般12M。内存速度需要200个 CPU 周期，CPU 缓存需要1个CPU周期。

进程

TODO

线程

协程

  • 《终结python协程----从yield到actor模型的实现》
    • 线程的调度是由操作系统负责，协程调度是程序自行负责
    • 与线程相比，协程减少了无谓的操作系统切换.
    • 实际上当遇到IO操作时做切换才更有意义，（因为IO操作不用占用CPU），如果没遇到IO操作，按照时间片切换.

Linux

设计模式

设计模式的六大原则

  • 《设计模式的六大原则》
    • 开闭原则：对扩展开放,对修改关闭，多使用抽象类和接口。
    • 里氏替换原则：基类可以被子类替换，使用抽象类继承,不使用具体类继承。
    • 依赖倒转原则：要依赖于抽象,不要依赖于具体，针对接口编程,不针对实现编程。
    • 接口隔离原则：使用多个隔离的接口,比使用单个接口好，建立最小的接口。
    • 迪米特法则：一个软件实体应当尽可能少地与其他实体发生相互作用，通过中间类建立联系。
    • 合成复用原则：尽量使用合成/聚合,而不是使用继承。

23种常见设计模式

应用场景

  • 《细数JDK里的设计模式》

    • 结构型模式：

      • 适配器：用来把一个接口转化成另一个接口，如 java.util.Arrays#asList()。
      • 桥接模式：这个模式将抽象和抽象操作的实现进行了解耦，这样使得抽象和实现可以独立地变化，如JDBC；
      • 组合模式：使得客户端看来单个对象和对象的组合是同等的。换句话说，某个类型的方法同时也接受自身类型作为参数，如 Map.putAll，List.addAll、Set.addAll。
      • 装饰者模式：动态的给一个对象附加额外的功能，这也是子类的一种替代方式，如 java.util.Collections#checkedList|Map|Set|SortedSet|SortedMap。
      • 享元模式：使用缓存来加速大量小对象的访问时间，如 valueOf(int)。
      • 代理模式：代理模式是用一个简单的对象来代替一个复杂的或者创建耗时的对象，如 java.lang.reflect.Proxy

    • 创建模式:

      • 抽象工厂模式：抽象工厂模式提供了一个协议来生成一系列的相关或者独立的对象，而不用指定具体对象的类型，如 java.util.Calendar#getInstance()。
      • 建造模式(Builder)：定义了一个新的类来构建另一个类的实例，以简化复杂对象的创建，如：java.lang.StringBuilder#append()。
      • 工厂方法：就是 一个返* 回具体对象的方法，而不是多个，如 java.lang.Object#toString()、java.lang.Class#newInstance()。
      • 原型模式：使得类的实例能够生成自身的拷贝、如：java.lang.Object#clone()。
      • 单例模式：全局只有一个实例，如 java.lang.Runtime#getRuntime()。

    • 行为模式：

      • 责任链模式：通过把请求从一个对象传递到链条中下一个对象的方式，直到请求被处理完毕，以实现对象间的解耦。如 javax.servlet.Filter#doFilter()。
      • 命令模式：将操作封装到对象内，以便存储，传递和返回，如：java.lang.Runnable。
      • 解释器模式：定义了一个语言的语法，然后解析相应语法的语句，如，java.text.Format，java.text.Normalizer。
      • 迭代器模式：提供一个一致的方法来顺序访问集合中的对象，如 java.util.Iterator。
      • 中介者模式：通过使用一个中间对象来进行消息分发以及减少类之间的直接依赖，java.lang.reflect.Method#invoke()。
      • 空对象模式：如 java.util.Collections#emptyList()。
      • 观察者模式：它使得一个对象可以灵活的将消息发送给感兴趣的对象，如 java.util.EventListener。
      • 模板方法模式：让子类可以重写方法的一部分，而不是整个重写，如 java.util.Collections#sort()。

  • 《Spring-涉及到的设计模式汇总》

  • 《Mybatis使用的设计模式》

单例模式

责任链模式

TODO

MVC

IOC

  • 《理解 IOC》
  • 《IOC 的理解与解释》
    • 正向控制：传统通过new的方式。反向控制，通过容器注入对象。
    • 作用：用于模块解耦。
    • DI：Dependency Injection，即依赖注入，只关心资源使用，不关心资源来源。

AOP

UML

微服务思想

康威定律

  • 《微服务架构的理论基础 - 康威定律》

    • 定律一：组织沟通方式会通过系统设计表达出来，就是说架构的布局和组织结构会有相似。
    • 定律二：时间再多一件事情也不可能做的完美，但总有时间做完一件事情。一口气吃不成胖子，先搞定能搞定的。
    • 定律三：线型系统和线型组织架构间有潜在的异质同态特性。种瓜得瓜，做独立自治的子系统减少沟通成本。
    • 定律四：大的系统组织总是比小系统更倾向于分解。合久必分，分而治之。

  • 《微服务架构核⼼20讲》

运维 & 统计 & 技术支持

常规监控

命令行监控工具

APM

APM — Application Performance Management

统计分析

持续集成(CI/CD)

Jenkins

环境分离

开发、测试、生成环境分离。

自动化运维

Ansible

puppet

chef

测试

TDD 理论

  • 《深度解读 - TDD（测试驱动开发）》
    • 基于测试用例编码功能代码，XP（Extreme Programming）的核心实践.
    • 好处：一次关注一个点，降低思维负担；迎接需求变化或改善代码的设计；提前澄清需求；快速反馈；

单元测试

压力测试

全链路压测

A/B 、灰度、蓝绿测试

虚拟化

KVM

Xen

OpenVZ

容器技术

Docker

云技术

OpenStack

DevOps

文档管理

中间件

Web Server

Nginx

OpenResty

Apache Httpd

Tomcat

架构原理
调优方案

Jetty

  • 《Jetty 的工作原理以及与 Tomcat 的比较》
  • 《jetty和tomcat优势比较》
    • 架构比较:Jetty的架构比Tomcat的更为简单。
    • 性能比较：Jetty和Tomcat性能方面差异不大，Jetty默认采用NIO结束在处理I/O请求上更占优势，Tomcat默认采用BIO处理I/O请求，Tomcat适合处理少数非常繁忙的链接，处理静态资源时性能较差。
    • 其他方面：Jetty的应用更加快速，修改简单，对新的Servlet规范的支持较好;Tomcat 对JEE和Servlet 支持更加全面。

缓存

本地缓存

客户端缓存

服务端缓存

Web缓存

Memcached

Redis

  • 《Redis 教程》

  • 《redis底层原理》

    • 使用 ziplist 存储链表，ziplist是一种压缩链表，它的好处是更能节省内存空间，因为它所存储的内容都是在连续的内存区域当中的。
    • 使用 skiplist(跳跃表)来存储有序集合对象、查找上先从高Level查起、时间复杂度和红黑树相当，实现容易，无锁、并发性好。

  • 《Redis持久化方式》

    • RDB方式：定期备份快照，常用于灾难恢复。优点：通过fork出的进程进行备份，不影响主进程、RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。缺点：会丢数据。
    • AOF方式：保存操作日志方式。优点：恢复时数据丢失少，缺点：文件大，回复慢。
    • 也可以两者结合使用。

  • 《分布式缓存--序列3--原子操作与CAS乐观锁》

架构
回收策略

Tair

  • 官方网站
  • 《Tair和Redis的对比》
  • 特点：可以配置备份节点数目，通过异步同步到备份节点
  • 一致性Hash算法。
  • 架构：和Hadoop 的设计思想类似，有Configserver，DataServer，Configserver 通过心跳来检测，Configserver也有主备关系。

几种存储引擎:

  • MDB，完全内存性，可以用来存储Session等数据。
  • Rdb（类似于Redis），轻量化，去除了aof之类的操作，支持Restfull操作
  • LDB（LevelDB存储引擎），持久化存储，LDB 作为rdb的持久化，google实现，比较高效，理论基础是LSM(Log-Structured-Merge Tree)算法，现在内存中修改数据，达到一定量时（和内存汇总的旧数据一同写入磁盘）再写入磁盘，存储更加高效，县比喻Hash算法。
  • Tair采用共享内存来存储数据，如果服务挂掉（非服务器），重启服务之后，数据亦然还在。

消息队列

消息总线

消息总线相当于在消息队列之上做了一层封装，统一入口，统一管控、简化接入成本。

消息的顺序

RabbitMQ

支持事务，推拉模式都是支持、适合需要可靠性消息传输的场景。

RocketMQ

Java实现，推拉模式都是支持，吞吐量逊于Kafka。可以保证消息顺序。

ActiveMQ

纯Java实现，兼容JMS，可以内嵌于Java应用中。

Kafka

高吞吐量、采用拉模式。适合高IO场景，比如日志同步。

Redis 消息推送

生产者、消费者模式完全是客户端行为，list 和 拉模式实现，阻塞等待采用 blpop 指令。

ZeroMQ

TODO

定时调度

单机定时调度

分布式定时调度

RPC

Dubbo

** SPI **TODO

Thrift

gRPC

服务端可以认证加密，在外网环境下，可以保证数据安全。

数据库中间件

Sharding Jdbc

日志系统

日志搜集

配置中心

servlet 3.0 异步特性可用于配置中心的客户端

API 网关

主要职责：请求转发、安全认证、协议转换、容灾。

网络

协议

OSI 七层协议

TCP/IP

HTTP

HTTP2.0

HTTPS

网络模型

  • 《web优化必须了解的原理之I/o的五种模型和web的三种工作模式》

    • 五种I/O模型：阻塞I/O，非阻塞I/O，I/O复用、事件(信号)驱动I/O、异步I/O，前四种I/O属于同步操作，I/O的第一阶段不同、第二阶段相同，最后的一种则属于异步操作。
    • 三种 Web Server 工作方式：Prefork(多进程)、Worker方式(线程方式)、Event方式。

  • 《select、poll、epoll之间的区别总结》

    • select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的。
    • select 有打开文件描述符数量限制，默认1024（2048 for x64），100万并发，就要用1000个进程、切换开销大；poll采用链表结构，没有数量限制。
    • select，poll “醒着”的时候要遍历整个fd集合，而epoll在“醒着”的时候只要判断一下就绪链表是否为空就行了，通过回调机制节省大量CPU时间；select，poll每次调用都要把fd集合从用户态往内核态拷贝一次，而epoll只要一次拷贝。
    • poll会随着并发增加，性能逐渐下降，epoll采用红黑树结构，性能稳定，不会随着连接数增加而降低。

  • 《select，poll，epoll比较 》

    • 在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。

  • 《深入理解Java NIO》

    • NIO 是一种同步非阻塞的 IO 模型。同步是指线程不断轮询 IO 事件是否就绪，非阻塞是指线程在等待 IO 的时候，可以同时做其他任务

  • 《BIO与NIO、AIO的区别》

  • 《两种高效的服务器设计模型：Reactor和Proactor模型》

Epoll

Java NIO

kqueue

连接和短连接

框架

零拷贝（Zero-copy）

序列化(二进制协议)

Hessian

Protobuf

数据库

基础理论

数据库设计的三大范式

  • 《数据库的三大范式以及五大约束》
    • 第一范式：数据表中的每一列（每个字段）必须是不可拆分的最小单元，也就是确保每一列的原子性；
    • 第二范式（2NF）：满足1NF后，要求表中的所有列，都必须依赖于主键，而不能有任何一列与主键没有关系，也就是说一个表只描述一件事情；
    • 第三范式：必须先满足第二范式（2NF），要求：表中的每一列只与主键直接相关而不是间接相关，（表中的每一列只能依赖于主键）；

MySQL

原理

InnoDB

优化

索引

聚集索引, 非聚集索引

MyISAM 是非聚集，InnoDB 是聚集

复合索引
自适应哈希索引(AHI)

explain

NoSQL

MongoDB

  • MongoDB 教程
  • 《Mongodb相对于关系型数据库的优缺点》
    • 优点：弱一致性（最终一致），更能保证用户的访问速度；内置GridFS，支持大容量的存储；Schema-less 数据库，不用预先定义结构；内置Sharding；相比于其他NoSQL，第三方支持丰富；性能优越；
    • 缺点：mongodb不支持事务操作；mongodb占用空间过大；MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方；

Hbase

搜索引擎

搜索引擎原理

Lucene

Elasticsearch

Solr

sphinx

性能

性能优化方法论

容量评估

CDN 网络

连接池

性能调优

大数据

流式计算

Storm

Flink

Kafka Stream

应用场景

例如：

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

Hadoop

HDFS

MapReduce

Yarn

Spark

安全

web 安全

XSS

CSRF

SQL 注入

Hash Dos

脚本注入

漏洞扫描工具

验证码

DDoS 防范

用户隐私信息保护

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

序列化漏洞

加密解密

对称加密

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

哈希算法

非对称加密

服务器安全

数据安全

数据备份

TODO

网络隔离

内外网分离

TODO

登录跳板机

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

授权、认证

RBAC

OAuth2.0

双因素认证（2FA）

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

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

单点登录(SSO)

常用开源框架

开源协议

日志框架

Log4j、Log4j2

Logback

ORM

MyBatis：

网络框架

TODO

Web 框架

Spring 家族

Spring

Spring Boot

Spring Cloud

工具框架

分布式设计

扩展性设计

稳定性 & 高可用

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

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

  • 《关于高可用的系统》

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

硬件负载均衡

软件负载均衡

限流

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

应用层容灾

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

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

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

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

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

跨机房容灾

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

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

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

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

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

容灾演练流程

平滑启动

数据库扩展

读写分离模式

分片模式

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

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

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

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

服务治理

服务注册与发现

服务路由控制

  • 《分布式服务框架学习笔记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
Zab
Raft
Gossip
两阶段提交、多阶段提交

幂等

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

分布式一致方案

分布式 Leader 节点选举

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

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

分布式文件系统

唯一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

贫血，充血模型

  • 《贫血，充血模型的解释以及一些经验》
    • 失血模型：老子和儿子分别定义，相互不知道，二者实体定义中完全没有业务逻辑，通过外部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

Serverless

无需过多关系服务器的服务架构理念。

  • 《什么是Serverless无服务器架构？》

    • Serverless 不代表出去服务器，而是去除对服务器运行状态的关心。
    • Serverless 代表一思维方式的转变，从“构建一套服务在一台服务器上，对对个事件进行响应转变为构建一个为服务器，来响应一个事件”。
    • Serverless 不代表某个具体的框架。

  • 《如何理解Serverless？》

    • 依赖于 Baas （(Mobile) Backend as a Service） 和 Faas （Functions as a service）

Service Mesh

项目管理

架构评审

重构

代码规范

代码 Review

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

RUP

看板管理

SCRUM

SCRUM - 争球

敏捷开发

TODO

极限编程（XP）

XP - eXtreme Programming

  • 《主流敏捷开发方法：极限编程XP》

    • 是一种指导开发人员的方法论。

    • 4大价值：

      • 沟通：鼓励口头沟通，提高效率。
      • 简单：够用就好。
      • 反馈：及时反馈、通知相关人。
      • 勇气：提倡拥抱变化，敢于重构。

    • 5个原则：快速反馈、简单性假设、逐步修改、提倡更改（小步快跑）、优质工作（保证质量的前提下保证小步快跑）。

    • 5个工作：阶段性冲刺；冲刺计划会议；每日站立会议；冲刺后review；回顾会议。

结对编程

边写码，边review。能够增强代码质量、减少bug。

PDCA 循环质量管理

P——PLAN 策划，D——DO 实施，C——CHECK 检查，A——ACT 改进

FMEA管理模式

TODO

通用业务术语

TODO

技术趋势

TODO

政策、法规

TODO

法律

严格遵守刑法253法条

我国刑法第253条之一规定：

  • 国家机关或者金融、电信、交通、教育、医疗等单位的工作人员，违反国家规定，将本单位在履行职责或者提供服务过程中获得的公民个人信息，出售或者非法提供给他人，情节严重的，处3年以下有期徒刑或者拘役，并处或者单处罚金。
  • 窃取或者以其他方法非法获取上述信息，情节严重的，依照前款的规定处罚。
  • 单位犯前两款罪的，对单位判处罚金，并对其直接负责的主管人员和其他直接责任人员，依照各该款的规定处罚。

最高人民法院、最高人民检察院关于执行《中华人民共和国刑法》确定罪名的补充规定（四）规定：触犯刑法第253条之一第1款之规定，构成“出售、非法提供公民个人信息罪”；触犯刑法第253条之一第2款之规定，构成“非法获取公民个人信息罪”

架构师素质

  • 《架构师画像》

    • 业务理解和抽象能力
    • NB的代码能力
    • 全面：1. 在面对业务问题上，架构师脑海里是否会浮现出多种技术方案；2. 在做系统设计时是否考虑到了足够多的方方面面；3. 在做系统设计时是否考虑到了足够多的方方面面；
    • 全局：是否考虑到了对上下游的系统的影响。
    • 权衡：权衡投入产出比；优先级和节奏控制；

  • 《关于架构优化和设计，架构师必须知道的事情》

    • 要去考虑的细节：模块化、轻耦合、无共享架构；减少各个组件之前的依赖、注意服务之间依赖所有造成的链式失败及影响等。
    • 基础设施、配置、测试、开发、运维综合考虑。
    • 考虑人、团队、和组织的影响。

  • 《如何才能真正的提高自己，成为一名出色的架构师？》

  • 《架构师的必备素质和成长途径》

    • 素质：业务理解、技术广度、技术深度、丰富经验、沟通能力、动手能力、美学素养。
    • 成长路径：2年积累知识、4年积累技能和组内影响力、7年积累部门内影响力、7年以上积累跨部门影响力。

  • 《架构设计师—你在哪层楼？》

    • 第一层的架构师看到的只是产品本身
    • 第二层的架构师不仅看到自己的产品，还看到了整体的方案
    • 第三层的架构师看到的是商业价值

团队管理

TODO

招聘

资讯

行业资讯

公众号列表

TODO

博客

团队博客

个人博客

综合门户、社区

国内：

国外：

问答、讨论类社区

行业数据分析

专项网站

其他类

推荐参考书

在线电子书

纸质书

开发方面
架构方面
技术管理方面
基础理论
工具方面

TODO

大数据方面

技术资源

开源资源

手册、文档、教程

国内：

  • W3Cschool

  • Runoob.com

    • HTML 、 CSS、XML、Java、Python、PHP、设计模式等入门手册。

  • Love2.io

    • 很多很多中文在线电子书，是一个全新的开源技术文档分享平台。

  • gitbook.cn

    • 付费电子书。

  • ApacheCN

    • AI、大数据方面系列中文文档。

国外：

  • Quick Code
    • 免费在线技术教程。
  • gitbook.com
    • 有部分中文电子书。
  • Cheatography
    • Cheat Sheets 大全，单页文档网站。
  • Tutorialspoint
    • 知名教程网站，提供Java、Python、JS、SQL、大数据等高质量入门教程。

在线课堂

会议、活动

活动发布平台:

常用APP

找工作

工具

代码托管

文件服务

  • 七牛
  • 又拍云

综合云服务商

VPS

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/IT小白/article/detail/557446
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号