Skip to content

stevenli91748/System-Design

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

800 Commits
APIGateWay
APIGateWay
 
 
CDN
CDN
 
 
Cache
Cache
 
 
DNS
DNS
 
 
High availability architecture
High availability architecture
 
 
High concurrency architecture
High concurrency architecture
 
 
High performance architecture
High performance architecture
 
 
Highly scalable architecture
Highly scalable architecture
 
 
Interview
Interview
 
 
Load Balance
Load Balance
 
 
Reverse Proxy
Reverse Proxy
 
 
Session
Session
 
 
单体架构基础
单体架构基础
 
 
后端业务层架构
后端业务层架构
 
 
后端数据存储层设计
后端数据存储层设计
 
 
后端数据訪问层设计
后端数据訪问层设计
 
 
后端显示层架构
后端显示层架构
 
 
后端服务层架构
后端服务层架构
 
 
系统设计系列讲解
系统设计系列讲解
 
 
高安全性架构
高安全性架构
 
 
高櫎展性架构
高櫎展性架构
 
 
Documention
Documention
 
 
README.md
README.md
 
 
凤凰架构---构建可靠的大型分布式系统 周志明.md
凤凰架构---构建可靠的大型分布式系统 周志明.md
 
 
软件架构风格的演进.md
软件架构风格的演进.md
 
 

Repository files navigation

以mall项目为基础，微服务采用领域驱动设计架构(DDD)，其中权限系统可结合mybird的“Spring Cloud 微服务权限系统搭建教程（看云）” , 再结合周志明的“凤凰架构---构建可靠的大型分布式系统 ”从以SpringCloud技术栈为基础设施的微服务架构升级到Kubernetes 为基础设施的微服务架构，然后再升级到以 Istio 为基础设施的服务网格架构，最终发展为以AWS Lambda 为基础的无服务架构

P8 工程师学习路径

系统设计面试

服务器软件大盘点

搜索技术

大后台技术栈包括 4 个层面的内容

image

服务端开发涉及的技术栈汇总出的一张技术架构图

interview-1-01

基于云的创业公司后台技术架构方案

image

在线书籍

高可用架构在线书籍

高性能架构在线书籍

高并发架构在线书籍

设计实例

系统设计视频

系统设计面试速成大纲

（架构师必看）

目录

云原生架构的三架马车

IT老齐架构600讲
Service Mesh微服务---应用的通信网络层 Kubernetes---云原生的操作系统 Serverless---让应用不用关注机器和实例
阿里架构师从0到1---good
从软件的历史看架构的未来 大规模业务技术架构设计与战术（架构师必看）
技术架构涵盖内容和演变过程总结 互联网架构师之路
Grokking the System Design Interview---educative 收费 网上最好的系统设计面试题 反复看5次
System Design in Practice + System Design Theories
从零搭建后台技术栈，让你提升一个层次 架构设计：企业总体架构要如何做？小白也能快速领悟的设计思想
系统设计入门
凤凰架构---构建可靠的大型分布式系统 周志明 周志明的软件架构课 为什么这么设计---程序设计决策
MikeChen的互联网架构
如何设计能扩展到1亿用户的系统 架构设计系列 移动端工程架构与后端工程架构的思想摩擦之旅
项目上线的开发流程 softwear archietcure good
架构建模 - 云时代的架构实践---软件系统分析与设计指南
系统分析与设计实验项目---多个项目 系统设计面试题精选 领域驱动设计架构DDD落地案例
面试官教你破解系统设计题---非常有体系的系统设计破解 怎样努力才能才为一个优秀的架构师？ 架构设计学习资源汇总 优秀架构师必须掌握的架构思维
很多软件公司的softwear engineer blog地址---有非常重要的参考价值
儒猿学院---中华石杉架构课 亿级流量架构系列专栏总结【石杉的架构笔记】 石杉的架构笔记
架构必看：12306抢票亿级流量架构演进（图解+秒懂+史上最全）---疯狂创客圈 阿里毕玄：我在系统设计上犯过的14个错
九章算法官方频道 爱思系统设计---硅谷多家顶尖大厂近十年工作经验资深 Tech Lead X Code---系统设计 和 算法
学习系统设计的网站 系统设计入门 来Offer---LaiOffer System design interview for IT companies IT 公司系统设计面试
System Design for Tech Interviews 学习笔记 系统设计面试指南 系统设计面试 101
【解构系统设计面试】什么是系统设计？以及如何设计一个新鲜事系统？
程序员必知的几种软件架构模式 如何设计一个优秀的分布式系统？重要因素、工具、策略都在这里
耦合到底意味着什么呢 服务端高并发分布式架构 14 次演进 早期架构设计问题
架构师杨波: 优秀架构师是如何学习开源项目的？ 应用架构之道：分离业务逻辑和技术细节
一文教会你如何写复杂业务代码 java web开发中的各种层
架构制图：工具与方法论 如何画出一张合格的技术架构图？ 整不明白架构图都画啥
高并发都要学哪些技术 系统间通信技术
如何设计与实现短URL服务？ 异地多活的架构设计

软件测试

IT设备科普

大后台技术栈包括 4 个层面的内容目录

  • 0. 流程和规范
    • 制定开发的规范---代码及代码分支管理规范，关键性代码仅少数人有权限
    • 制定发布流程规范---从发布系统落地
    • 制定运维规范---收拢数据库操作权限
    • 制定数据库操作规范---收拢数据库操作权限
    • 制定告警处理流程--- 做到告警有人看有人处理
    • 制定汇报机制---晨会/周报
  • 1 接入层
  • 2 逻辑层
  • 3 存储层
    • 存储服务
    • 数据服务
  • 4 基础设施层

    • 开发部分

      • 代码管理/Bug管理/问题管理
        • phabricator--- facebook的内部工具,集成了代码托管， Code Review，任务管理，文档管理，问题跟踪等功能，强烈推荐较敏捷的团队使用
        • GIT
        • GITLAB
        • Gerrit---Gerrit 做 Code review, Gerrit 比 GitLab 提供了更好的代码检查界面与主线管理体验，更适合在对代码质量有高要求的文化下使用

    • 持续集成部分

      • Jenkins
      • TeamCity---收费
      • GitLab CI
      • Travis

    • 项目管理部分

    • 问题定位部分

    • 组件层

      • RPC框架
        • 跨语言调用---适合多语言调用场景。但这类框架没有服务发现相关机制，实际使用时需要代理层进行请求转发和负载均衡策略控制
          • Thrift
          • gRPC
          • Hessian
          • Hprose
        • 服务治理---功能丰富,提供高性能的远程调用、服务发现及服务治理能力，适用于大型服务的服务解耦及服务治理
          • Dubbo---阿里巴巴公司开源的一个 Java 高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring 框架无缝集成
          • DubboX---由当当在基于 Dubbo 框架扩展的一个 RPC 框架，支持 REST 风格的远程调用、Kryo/FST 序列化，增加了一些新的feature
          • Motan---Motan 是新浪微博开源的一个 Java 框架
      • 消息队列
        • kafka
      • 配置系统---随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、降级开关，灰度开关，参数的配置、服务器的地址、数据库配置等等，除此之外，对后台程序配置的要求也越来越高：配置修改后实时生效，灰度发布，分环境、分用户，分集群管理配置，完善的权限、审核机制等等，在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求，业界有如下两种方案
        • 基于 zk 和 etcd，支持界面和 api ，用数据库来保存版本历史，预案，走审核流程，最后下发到 zk 或 etcd 这种有推送能力的存储里（服务注册本身也是用 zk 或 etcd，选型就一块了）。客户端都直接和 zk 或 etcd 打交道。至于灰度发布，各家不同，有一种实现是同时发布一个需要灰度的 IP 列表，客户端监听到配置节点变化时，对比一下自己是否属于该列表。PHP 这种无状态的语言和其他 zk/etcd 不支持的语言，只好自己在客户端的机器上起一个 Agent 来监听变化，再写到配置文件或共享内存，如 360 的 Qconf。 基于运维自动化的配置文件的推送，审核流程，配置数据管理和方案一类似，下发时生成配置文件，基于运维自动化工具如 Puppet，Ansible 推送到每个客户端，而应用则定时重新读取这个外部的配置文件，灰度发布在下发配置时指定IP列表
        • 创业公司前期不需要这种复杂，直接上 zk，弄一个界面管理 zk 的内容，记录一下所有人的操作日志，程序直连 zk，或者或者用 Qconf 等基于 zk 优化后的方案
      • 日志系统
      • 名字服务
        • 业界常用的服务注册表
          • etcd---一个高可用、分布式、一致性、key-value 方式的存储，被用在分享配置和服务发现中
          • Cosul---一个发现和配置服务的工具，为客户端注册和发现服务提供了API，Consul还可以通过执行健康检查决定服务的可用性
          • Apache ZooKeeper---是一个广泛使用、高性能的针对分布式应用的协调服务
        • 客户端发现模式----框架中常用的服务发现是客户端发现模式
        • 服务端发现模式--- 指客户端通过一个负载均衡器向服务发送请求，负载均衡器查询服务注册表并把请求路由到一台可用的服务实例上。现在常用的负载均衡器都是此类模式，常用于微服务中
      • 数据平台
        • 关系数据库---SQL
          • 传统关系数据
            • Oracle
            • MySQL
            • Maria
            • DB2
            • PostgreSQL
          • NewSQL
            • CockroachDB
            • TiDB---之前在创业公司时在大数据分析时已经开始应用 TiDB，当时应用的主要原因是 MySQL 要使用分库分表，逻辑开发比较复杂，扩展性不够
        • 非关系数据库---NoSQL
          • 键值型---适用于内容缓存，适合混合工作负载并发高扩展要求大的数据集，其优点是简单，查询速度快，缺点是缺少结构化数据，
            • Redis
            • Memcache
            • BerkeleyDB
            • Voldemort
          • 列式---以列簇式存储，将同一列数据存在一起，常见于分布式的文件系统
            • Hbase
            • Cassandra
          • 文档---数据存储方案非常适用承载大量不相关且结构差别很大的复杂信息
            • MongoDB
            • CouchDB
          • 图形---形数据库擅长处理任何涉及关系的状况。社交网络，推荐系统等。专注于构建关系图谱，需要对整个图做计算才能得出结果，不容易做分布式的集群方案
            • Neo4J
            • InfoGrid
          • 对象数据库
          • XML数据库

    • 运维层

      • 发布系统/部署系统

      image
      从上图中可以看出，从开发人员写下代码到服务最终用户是一个漫长过程，整体可以分成三个阶段：从代码（Code）到成品库（Artifact）这个阶段主要对开发人员的代码做持续构建并把构建产生的制品集中管 理，是为部署系统准备输入内容的阶段。从制品到可运行服务 这个阶段主要完成制品部署到指定环境，是部署系统的最基本工作内容。从开发环境到最终生产环境 这个阶段主要完成一次变更在不同环境的迁移， 是部署系统上线最终服务的核心能力。发布系统集成了制品管理，发布流程，权限控制，线上环境版本变更，灰度发布，线上服务回滚等几方面的内容，是开发人员工作结晶最终呈现的重要通道。开源的项目中没 有完全满足的项目，如果只是 Web 类项目，Walle、Piplin 都是可用的，但是功能不太满足，创业初期可以集成 Jenkins + Gitlab + Walle（可以考虑两天时间完善一下），以上方案基本包括制品管理，发布 流程，权限控制，线上环境版本变更，灰度发布（需要自己实现），线上服务回滚等功能。

      • 监控系统
        • 业界成熟的方案
          • 创业公司选择 Prometheus + Grafana 的方案，再加上统一的服务框架（如 gRPC），可以满足大部分中小团队的监控需求
        • 操作系统层的监控
          • 机器负载监控指标
          • IO监控指标
          • 网络流量监控指标
          • CPU监控指标
          • 内存监控指标
        • 服务质量和业务质量的监控
          • 服务的可用性监控指标
          • 成功率监控指标
          • 失败率监控指标
          • 容量监控指标
          • QPS监控指标
      • 设备管理
        • Puppet
        • Ansible---一般创业公司选择 Ansible 能解决大部问题，其简单，不需要安装额外的客户端，可以从命令行来运行，不需要使用配置文件
        • Saltstack
      • 跳板机---跳板机面对的是需求是要有一种能满足角色管理与授权审批、信息资源访问控制、操作记录和审计、系统变更和维护控制要求，并生成一些统计报表配合管理规范来不断提升IT内控的合规性，能对运维人员操作行为的进行控制和审计，对误操作、违规操作导致的操作事故，快速定位原因和责任人。其功能模块一般包括：帐户管理、认证管理、授权管理、审计管理等等。开源项目中，Jumpserver 能够实现跳板机常见 需求，如授权、用户管理、服务器基本信息记录等，同时又可批量执行脚本等功能；其中录像回放、命令搜索、实时监控等特点，又能帮助运维人员回溯操作历史，方便查找操作痕迹，便于管理其他人员对服务 器的操作控制

System-Design

软件架构风格的演进

1. 需求

**在项目的前期，我们需要思考的是：容量规划，架构设计，数据库设计，缓存设计，框架选型，数据迁移方案，性能压测，监控报警，领域模型，回滚方案，高并发，分库分表 **

1.1 软件需求规划

1.2 软件需求开发

1.3 邻域建模

1.4 确定关键需求

2. 设计

设计模式 vs 架构设计

  • 设计模式：
  • 架构模式--架构模式将在设计的早期就被选择并确定下来，它会在很大程度上影响系统的质量特性，例如 性能 安全性，可微护性，可展性, 常见的架构模式有：
    • 1 针对应用程序建模的架构模式
      • 1.1 分层架构(Layered pattern）---区分层次的目的即为了“高内聚，低耦合”的思想
      • 1.2 主从模式（Master-slave pattern）
      • 1.3 管道 - 过滤器架构（Pipe-filter pattern）
      • 1.4 客户端 - 服务器架构（Client-server pattern）
      • 1.5 模型 - 视图 - 控制器架构（Model-view-controller pattern）
      • 1.6 事件驱动架构(Event-bus pattern）
      • 1.7 微服务架构
      • 1.8 领域驱动设计架构DDD
      • 1.9 代理模式（Broker pattern）
      • 1.10 点对点模式（Peer-to-peer pattern）
      • 1.11 黑板模式（Blackboard pattern）
      • 1.12 解释器模式（Interpreter pattern）
      • 1.13 基于云的架构(Cloud-Based Ar)
    • 2 针对表现层（Presentation Layer）的架构模式
      • 2.1 MVC
      • 2.2 MVP
      • 2.3 MVVM
    • 3 针对业务逻辑层Business Layer）的架构模式
    • 4 针对服务层（Service Layer）的架构模式
    • 5 针对持久化层（Persistent Layer）的架构模式
    • 6 针对数据访问层（Data Access Layer/DAO）的架构模式
      • 6.1 关系数据库访问层 ORM 架构模式
    • 7 针对消息服务层相关的架构模式
      • 7.1 消息过滤---典型产品 web 框架
      • 7.2 数据黑板---典型产品 Redis
      • 7.3 消息路由---6 种基本模式， 典型产品 AMQP 产品系列，例如 RabbitMQ

2.1 概念架构设计

2.2 细化架构设计

架构

采用RESTful API 技术


采用微服务技术 + RESTful API 技术

Imgur

2.2.0. 前端架构

  • 动静分离--静态资源独立部署
  • 图片服务

微服务网关实战

2.2.1 后端显示层架构

  • 显示层的两个主要组件
    • 用户界面
    • 显示层逻辑
  • MVC模式的原理
  • MVP模式的原理
  • MVVM模式的原理
  • PM模式的原理

2.2.2. 后端业务层架构---前端 web 层和服务层必须是无状态的，以便方便地添加或删除主机，从而实现横向可扩展性

  • 开发框架
  • Stateless---无状态
  • Async non-blocking---异步非阻塞
  • 用户层技术
    • 用户管理
      • SSO---单点登录
        • cookie
        • token
        • CAS
      • OAuth2.0---授登录
    • 消息推送
      • 短信
      • 邮件
      • 站内信
      • App 推送
    • 图片云
    • 存储云
  • 业务层技术
    • 搜索引擎
    • 推荐系统
  • 页面渲染--API Gateway
    • API Gateway
    • [Writing API]
    • [Reading API]
    • [Searching API]
  • 负载均衡
  • Session管理
  • 动态页面静态化
  • 业务拆分
  • 虚拟化服务器

2.2.3. 后端服务层架构---前端 web 层和服务层必须是无状态的，以便方便地添加或删除主机，从而实现横向可扩展性

  • 配置中心
  • 服务中心
    • 服务名字系统
    • 服务总线系统
  • 分布式消息
    • 消息中间件也存在一些问题
      • 消息重复问题
      • 消息丢失问题
      • 消息积压问题
      • 幂等性问题
        • 幂等性解决方案
          • 全局唯一ID
          • 去重表
          • 状态机
    • 消息队列设计
    • 消息队列种类
      • RocketMQ
      • Kafka
      • ActiveMQ
    • 任务队列
    • 背压机制
  • 分布式缓存
    • 缓存系统
      • [Client caching]
      • [HTTP Caching]
      • [CDN caching]
      • [Web server caching ]
      • [Database caching]
      • [Application caching]
      • [Caching at database query level]
      • [Caching at object level]
      • [When to update the cache]
        • [Cache aside]
        • [Write through]
        • [Write behind]
        • [Refresh ahead]
  • 分布式session
  • 分布式事务
    • 分布式事务方案---分布式事务对资源的消耗是巨大的，影响系统的吞吐量性能，一般是采用“ 最终一置性” ，采用“异步调用，消息中间件”的方案替代 但消息中间件也存在一些问题：消息重复，消息丢失，消息积压，幂等性等问题
  • 分布式服务

2.2.4. 后端数据訪问层设计

  • 数据訪问层的设计策略
    • 倉储模式
    • 数据訪问对象模式
  • ORM对象关系映射

2.2.5. 后端数据存储层设计

2.2.6 开发层(代码)架构

  • 代码架构结构分层：三层结构，DDD，MVC，MVVM，MVP
  • 开发框架
    • JAVA
      • 主流的java web框架
        • 以servlet为标准的框架
          • SSM
          • Spring
          • SpringMVC
          • SpringBoot
          • SpringCloud
        • 无servlet的框架
          • Netty
          • Playframework
          • Actframework
      • PC客户端应用开发
        • javaFX
      • Android应用开发
        • MVP
      • 服务端程序开发
        • RPC
        • MQ
      • 大数据技术开发
        • HBase
        • Accumulo
        • ElasticSearchas
    • 非Java
      • Node.js
  • WEB服务器
    • Tomcat
    • Nginx
    • JBoss
    • Resin
  • 容器

2.2.7 网络层架构

2.2.8 后台架构

  • 运维平台架构

    • 配置
    • 部署
    • 监控
    • 应急

  • 测试平台架构

    • 单元测试
    • 集成测试
    • 接口测试
    • 性能测试

  • 数据平台架构

    • 数据管理
    • 数据分析
    • 数据应用
      • 数据采集与监控架构
        • 浏览器数据采集
        • 服务器业务数据采集
        • 服务器性能数据采集
        • 系统监控
        • 系统报警

  • 管理平台架构

    • 权限管理
      • 身份认证
      • 权限控制

3. 开发步骤---项目整体的运转情况你一般是了解不到的，你应该自己抽空全新做一个自己的项目，例如一个BBS网站、一个有后台的app等。网站或app本身不重要，重要是你要自己开发、自己搞定上线系统、搞定监控系统、搞定发布系统、搞定测试系统等等，就是像一个正式公司的正式产品一样对待这个自己的项目。

4. 部署

5. 服务器

6. 运维

7. 调优

参考书籍

  • 凤凰架构：构建可靠的大型分布式系统.pdf

  • 从零开始学架构：照着做，你也能成为架构师.pdf

  • 从零开始学架构--系列文集.pdf

  • 人人都是架构师 分布式系统架构落地与瓶颈突破.pdf

  • 大型网站技术核心原理与案例分析.pdf

  • 大型网站技术架构演进与性能优化.pdf

  • 软件架构设计：大型网站技术架构与业务架构融合之道.pdf

  • 架构解密.从分布式到微服务.pdf

  • 亿级流量网站架构核心技术+跟开涛学搭建高可用高并发系统.pdf

  • 架构宝典架构.pdf

  • 聊聊架构.pdf

  • 架构真经-互联网技术架构的设计原则.pdf

  • 大型网站架构系列：20本技术书籍推荐

架构视频

有用的参考

数据訪问DAO层

大型网站架构

亿级流量研究处理

亿级流量系统架构

项目经验

项目实战

along

负载均衡层设计方案

About

No description, website, or topics provided.

Resources

Readme
Activity

Stars

143 stars

Watchers

2 watching

Forks

34 forks
Report repository

Releases

No releases published

Packages

No packages published