AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

后端架构师技术图谱

2018-05-07 6916
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
RDS MySQL Serverless 基础系列，0.5-2RCU 50GB
推荐场景：
学生管理系统数据库设计 搭建个人博客
云数据库 Tair（兼容Redis），内存型 2GB
推荐场景：
通过缓存加速数据库访问
Redis 开源版，标准版 2GB
推荐场景：
搭建游戏排行榜
简介： 数据结构队列集合链表、数组字典、关联数组栈树二叉树完全二叉树平衡二叉树二叉查找树（BST）红黑树B-，B+，B*树LSM 树BitSet常用算法排序、查找算法选择排序冒泡排序插入排序快速...

（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）
核心原理是利用一个“部分匹配表”，跳过已经匹配过的元素。

深度优先、广度优先

贪心算法

回溯算法

剪枝算法

动态规划

朴素贝叶斯

推荐算法

最小生成树算法

最短路径算法

并发

多线程

线程安全

一致性、事务

事务 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 支持更加全面。

缓存

本地缓存

客户端缓存

服务端缓存

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. 用户密码非明文保存，加动态slat。
  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

TODO

Service Mesh

TODO

项目管理

架构评审

重构

代码规范

TODO

代码 Review

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

RUP

看板管理

SCRUM

SCRUM - 争球

  • 3个角色:Product Owner(PO) 产品负责人;Scrum Master（SM），推动Scrum执行;Team 开发团队。
  • 3个工件：Product Backlog 产品TODOLIST，含优先级;Sprint Backlog 功能开发 TODO LIST；燃尽图；
  • 五个价值观：专注、勇气、公开、承诺、尊重。

敏捷开发

TODO

极限编程（XP）

XP - eXtreme Programming

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

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

    • 4大价值：

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

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

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

结对编程

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

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、大数据方面系列中文文档。

国外：

在线课堂

会议、活动

活动发布平台:

常用APP

找工作

工具

代码托管

文件服务

  • 七牛
  • 又拍云

综合云服务商

VPS

文章标签：
云消息队列 Kafka 版
API 网关
应用实时监控服务
CDN
DDoS防护
云解析DNS
检索分析服务 Elasticsearch版
云数据库HBase版
密钥管理服务
云数据库 Tair（兼容 Redis）
云数据库 MongoDB 版
微服务引擎
云数据库 RDS MySQL 版
云原生大数据计算服务 MaxCompute
云消息队列 MQ
性能测试
实时计算 Flink版
负载均衡
日志服务
Java
测试技术
Spring
算法
数据库
大数据
关键词：
架构技术
后端架构
后端技术
后端架构技术
后端架构师
jackcooper2015
目录
相关文章
肥猪肥猪-17824
|
16天前
|
Kubernetes Cloud Native 微服务
探索云原生技术：容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念，特别是容器化和微服务架构如何相辅相成，共同构建现代软件系统。我们将通过实际代码示例，探讨如何在云平台上部署和管理微服务，以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导，帮助他们在云原生时代中更好地设计、部署和维护应用。
肥猪肥猪-17824
48 5
无糖可乐嘟嘟
|
17天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程，分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性，然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构，指出微服务化转型的必要性和实施策略。最后，讨论了微服务架构实施过程中可能遇到的问题及解决方案。
无糖可乐嘟嘟
45 2
Deephub
|
10天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统：从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型，实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性，为机器学习工程师和研究人员提供了系统化的技术方案。
Deephub
130 77
使用PaliGemma2构建多模态目标检测系统：从架构设计到性能优化的技术实践指南
游客nmbcre4jd7shs
|
16天前
|
运维 Cloud Native 持续交付
云原生技术深度探索：重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析，揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化，为数字化转型提供强有力的技术支撑。不同于传统综述，本摘要直接聚焦于云原生技术的价值本质，旨在为读者构建一个宏观且具体的技术蓝图。 ####
游客nmbcre4jd7shs
43 7
aliyun0641063962-48771
|
22天前
|
弹性计算 持续交付 API
构建高效后端服务：微服务架构的深度解析与实践
在当今快速发展的软件行业中，构建高效、可扩展且易于维护的后端服务是每个技术团队的追求。本文将深入探讨微服务架构的核心概念、设计原则及其在实际项目中的应用，通过具体案例分析，展示如何利用微服务架构解决传统单体应用面临的挑战，提升系统的灵活性和响应速度。我们将从微服务的拆分策略、通信机制、服务发现、配置管理、以及持续集成/持续部署（CI/CD）等方面进行全面剖析，旨在为读者提供一套实用的微服务实施指南。
aliyun0641063962-48771
49 13
游客5fdji2pvmf8888
|
21天前
|
缓存 负载均衡 算法
深入理解后端服务的负载均衡技术
在现代网络服务架构中，高效的负载均衡策略对于保证应用性能和可靠性至关重要。本文将深入探讨后端服务中的负载均衡技术，包括其重要性、常见算法以及如何实现高效均衡。通过分析不同的负载均衡方法，我们旨在为开发者提供实用的指导，帮助他们优化自己的系统架构。
游客5fdji2pvmf8888
40 10
游客7v53mftipku2u
|
18天前
|
运维 监控 Java
后端开发中的微服务架构实践与挑战####
在数字化转型加速的今天，微服务架构凭借其高度的灵活性、可扩展性和可维护性，成为众多企业后端系统构建的首选方案。本文深入探讨了微服务架构的核心概念、实施步骤、关键技术考量以及面临的主要挑战，旨在为开发者提供一份实用的实践指南。通过案例分析，揭示微服务在实际项目中的应用效果，并针对常见问题提出解决策略，帮助读者更好地理解和应对微服务架构带来的复杂性与机遇。 ####
游客7v53mftipku2u
28 4
xibeijing
|
17天前
|
消息中间件 运维 安全
后端开发中的微服务架构实践与挑战####
在数字化转型的浪潮中，微服务架构凭借其高度的灵活性和可扩展性，成为众多企业重构后端系统的首选方案。本文将深入探讨微服务的核心概念、设计原则、关键技术选型及在实际项目实施过程中面临的挑战与解决方案，旨在为开发者提供一套实用的微服务架构落地指南。我们将从理论框架出发，逐步深入至技术细节，最终通过案例分析，揭示如何在复杂业务场景下有效应用微服务，提升系统的整体性能与稳定性。 ####
xibeijing
31 1
liuliunaina
|
18天前
|
消息中间件 运维 API
后端开发中的微服务架构实践####
本文深入探讨了微服务架构在后端开发中的应用，从其定义、优势到实际案例分析，全面解析了如何有效实施微服务以提升系统的可维护性、扩展性和灵活性。不同于传统摘要的概述性质，本摘要旨在激发读者对微服务架构深度探索的兴趣，通过提出问题而非直接给出答案的方式，引导读者深入
liuliunaina
37 1
游客kwe6k52lwpmug
|
19天前
|
负载均衡 监控 API
后端开发中的微服务架构实践与挑战
本文深入探讨了微服务架构在后端开发中的应用，分析了其优势和面临的挑战，并通过案例分析提出了相应的解决策略。微服务架构以其高度的可扩展性和灵活性，成为现代软件开发的重要趋势。然而，它同时也带来了服务间通信、数据一致性等问题。通过实际案例的剖析，本文旨在为开发者提供有效的微服务实施指导，以优化系统性能和用户体验。
游客kwe6k52lwpmug
24 2

热门文章

最新文章

  • 1
    最新发布！阿里云卓越架构框架重磅升级
  • 2
    日交易笔百万级，Ping++的大数据平台架构
  • 3
    《离线和实时大数据开发实战》（二）大数据平台架构 & 技术概览1
  • 4
    阿里云运维架构实践秘籍
  • 5
    基于 MySQL + Tablestore 分层存储架构的大规模订单系统实践-SQL 查询和分析
  • 6
    歪理邪说解析架构设计师上午考试试题之十一（分析2010下半年系统架构设计师上午试题51-56题）
  • 7
    【转】Linux 概念架构的理解
  • 8
    微服务架构的挑战与解决方案：最佳实践指南
  • 9
    详解 Serverless 架构的 6 大应用场景
  • 10
    App 组件化/模块化之路——构建开发架构思路
  • 1
    《跨界合作：前端与后端如何优化协作效率》
    82
  • 2
    【后端面经】【缓存】33｜缓存模式：缓存模式能不能解决缓存一致性问题？-03 Refresh Ahead + SingleFlight + 删除缓存 + 延迟双删
    139
  • 3
    【Uniapp 专栏】Uniapp 与后端接口对接的实战要点
    685
  • 4
    构建高效微服务架构：后端开发的新范式
    56
  • 5
    【后端面经】【缓存】33｜缓存模式：缓存模式能不能解决缓存一致性问题？-02 Write Through + Write Back
    96
  • 6
    nbcio-boot基于jeecg的flowable支持部门经理的单个或多实例支持（后端部分）
    102
  • 7
    ruoyi-nbcio-plus后端里mapstruct-plus和lombok的使用
    129
  • 8
    ruoyi-nbcio-plus后端升级遇到的编译错误问题
    98
  • 9
    vue的 blob文件下载文件时，后端自定义异常，并返回json错误提示信息，前端捕获信息并展示给用户
    262
  • 10
    新的centos7.9安装docker版本的jenkins2.436.1最新版本-后端项目发布（四）
    135

    • 相关课程

    更多
  • Serverless 函数计算架构
  • 架构的演进
  • MySQL企业常见架构与调优经验分享
  • 企业Web常用架构LAMP-LNMP实战
  • 企业级互联网分布式系统应用架构学习
  • 高校精品课-上海交通大学 -企业级应用体系架构

    • 相关电子书

    更多
  • ApacheCon阿里云AI原生应用架构开放日，2024
  • 十分钟上线-使用函数计算构建支付宝小程序服务
  • 机器学习在互联网后端技术中的应用

    • 相关实验场景

    更多
  • 以电商场景为例搭建AI语义搜索应用
  • 每个IT人都想学的“Web应用上云经典架构”实战
  • MySQL引擎及架构优化
  • 倚天大数据电商数据分析快速实践
  • 基于数据湖架构的网站访问行为分析
  • 使用SLB+2ECS+NAS，部署电商web网站的高可用架构
    • 下一篇
    DataWorks