架构学习笔记

这里是一些简单的笔记,主要是为了构建知识体系以及方便查找,以后会分点详细撰文。

前端

  1. HTML/CSS/JavaScript
  2. 框架:Vue、Backbone、jQuery、LESS
  3. 构建工具:Webpack、Gulp、Grunt
  4. 其他:NodeJS

数据交互

HTTP

  1. HTTP 1.0/1.1
    1. 建立在 TCP 协议之上,处于计算机网络中的应用层
    2. 瓶颈及其优化技巧都是基于 TCP 协议本身的特性
    3. 区别在于长连接支持、多路复用、带宽节约与数据压缩等
    4. 连接无法复用、队头阻塞、协议开销大和安全因素等多个缺陷
  2. HTTP/2
    1. 将请求和响应数据分割为更小的帧,并且它们采用二进制编码。
    2. 通过多路复用、二进制流、Header 压缩与 Server Push 等技术,极大地提高了性能
    3. 使用多路复用,一般来说同一域名下只需要使用一个 TCP 连接。在出现丢包的情况下,整个 TCP 都要开始等待重传,也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1.1 来说,可以开启多个 TCP 连接,出现这种情况反到只会影响其中一个连接,剩余的 TCP 连接还可以正常传输数据。
  3. HTTP/3
    1. Google 就自己架起炉灶搞了一个基于 UDP 协议的 QUIC 协议,并且使用在了 HTTP/3 上,HTTP/3 之前名为 HTTP-over-QUIC

数据格式

  1. protobuf123:smaller,faster,simpler
  2. Apache Thrift、Apache Avro
  3. json:{}
  4. xml:<tag><\tag>

接口规范:

  1. 响应报文:code、msg、data
  2. 请求数据:参数
  3. 参数校验:正则表达式

api:RESTful风格

  1. GET获取一个资源;POST添加一个资源;PUT修改一个资源;DELETE删除一个资源
  2. HTTP状态码:200 OK;400 Bad Request;500 Internal Server Error

服务发现

  1. erueka
  2. 在一个微服务应用中,一组运行的服务实例是动态变化的,实例有动态分配的网络地址,因此,为了使得客户端能够向服务发起请求,必须要要有服务发现机制。
  3. 客户端发现:客户端直接 查询服务注册表;服务端发现:客户端通过路由发起请求
  4. zookeper

RPC

rpc轮子

同步异步阻塞

  1. 概念:
    1. 同步:A调用B,此时只有等B有结果了才返回。
    2. 异步: A调用B,B立即返回,无须等待。当B处理完之后会通过通知或者回调函数的方式来告诉A结果。
    3. 阻塞:A调用B,A会被被挂起,一直在等待B的结果,什么事都不能干。
    4. 非阻塞:A调用B,自己用被挂起等待B的结果,可以去干其他的事情。
  2. java
    Java中的IO模型有三种,分别是BIO(同步阻塞IO),NIO(同步非阻塞IO),AIO(异步非阻塞IO)

后端

框架

  1. JAVA:Spring/SpringMVC/SpringBoot/SpringCloud
  2. C++:性能最佳
  3. GO:iris、Revel、beego、buffalo、echo、gin
    1. https://blog.csdn.net/dev_csdn/article/details/78740990
  4. PHP:Laravel、Yii、Symfony、ThinkPHP、Codeigniter
  5. python:Django、Flask、Tornado、Aiohttp
  6. Tomcat:java服务器;apache:html服务器;Nginx:替代apache

数据库

  1. mysql、mariadb
  2. ORM:MyBatis封装jdbc,用xml执行语句,解除sql语句与代码的耦合;hibernate
  3. Redis:key-value数据库,数据库缓存,二级缓存改善用户体验
  4. 散列分库
  5. 读写分离:主数据库提供写操作,从数据库提供读操作,写操作后再同步两个数据库
  6. 关系型数据库满足ACID
  7. 纵向扩展横向扩展,关系型横向扩展:主从复制(读写分离)、集群(多个实例)、分片(分表分库)
  8. 分布式系统满足CAP定理
  9. key-value是nosql的一种,Memcached使用内存,Redis对数据进行了持久化,pika基于rocksdb上面兼容了redis的协议,解决的是用户使用 Redis 的内存大小超过 50G、80G 等等这样的情况

    演进

  10. 单体数据库
  11. 读压力变大后:读写分离,主从同步;主库写从库读,读可水平扩展
  12. 写压力变大后:垂直分库;按照业务拆分,避免或减少跨库访问
  13. 水平分库(sharding):数据量越来越大

消息队列

  1. 耦合两个系统,提高系统吞吐率
  2. 可以根据一定的规则订阅读取请求
  3. kafka解决大量日志的传输问题
  4. 点对点通讯
  5. 异步处理

搜索

  1. Elasticsearch全文搜索

    HTTP Cache

雪崩,熔断,降级

  • 一个服务失败,导致整条链路的服务都失败的情形,我们称之为服务雪崩
  • 服务熔断和服务降级就可以视为解决服务雪崩的手段之一
  • 服务熔断:当下游的服务因为某种原因突然变得不可用或响应过慢,上游服务为了保证自己整体服务的可用性,不再继续调用目标服务,直接返回,快速释放资源。如果目标服务情况好转则恢复调用。
  • 一般使用断路器模式
  • 当下游的服务因为某种原因不可用,上游主动调用本地的一些降级逻辑,避免卡顿,迅速返回给用户!
  • 开关降级、限流降级、熔断降级

构建与环境

构建工具:

  1. make:makefile,linux原始
  2. ant:xml,思路类似make, init/compile/build/test;没办法管理依赖
  3. maven:xml,给每个包都标上坐标,这样,便于在仓库里进行查找
  4. gradle:groovy,构建任务添加log

开发环境:

  1. pro环境:生产环境,面向外部用户的环境,连接上互联网即可访问的正式环境。
  2. pre环境:灰度环境,外部用户可以访问,但是服务器配置相对低,其它和生产一样。
  3. test环境:测试环境,外部用户无法访问,专门给测试人员使用的,版本相对稳定。
  4. dev环境:开发环境,外部用户无法访问,开发人员使用,版本变动很大。

基础架构

指标

  1. RPS(Requests Per Second):系统在单位时间内(每秒)处理请求的数量。
  2. QPS(Query Per Second):是指在一定并发度下,服务器每秒可以处理的最大请求数。
  3. 服务器平均请求处理时间 = 1/QPS(秒)
  4. 平均等待时间 = 1/(QPS/并发度) = 并发度/QPS(秒)。

对策

  1. 百RPS——升级机器配置
  2. 千RPS——各组件拆分并优化
  3. 万RPS——水平扩展
  4. 十万、百万、千万RPS——终极拆分及扩展

大型系统设计

  1. 描述使用场景、约束和假设、
  2. 创造一个高层级的设计
  3. 设计核心组件
  4. 度量设计

优秀架构师应该具备

  1. 格局

    这个系统的定位是什么?它能创造什么核心价值?
    这个系统的背景是什么?-- 为什么以前不做,现在要上?是因为业务发展到了一定规模?还是开发资源现在有多余,没事可干?
    这个系统在整个组织架构中,处于什么位置?跟这个系统关联的其它系统目前什么状况?
    产品经理如何看待这个系统?技术老大如何看?
    这个系统的需求,是处于比较确定、比较清晰状态?还是有很大灰度空间?很多核心点,大家还没想清楚?
    这个系统所用的技术体系,是比较老?还是最新的?
    业界类似的系统,人家是如何做的?

  2. 历史观-技术血脉

    任何一种技术,都不是谁吃饱了没事干凭空想象出来的,它一定是要解决某个特定问题。而这个特定问题,一定有它的历史背景:是因为之前的技术,在解决这个特定问题上,解决的不够好、或者有其它副作用,所以才发明了这个新技术。

  3. 抽象能力

    每个需求的合理性?
    这个系统的领域模型是什么样的?
    这个系统是应该在旧的上面改造?还是应该另起炉灶?
    这个系统可以分成几期,分期实施?
    这个系统要拆分成几个子系统?
    每个子系统又拆分出多少个模块?
    系统的表设计?api接口设计?job的设计?系统之间的消息传输?

  4. 深入思考的能力、技术的深度
  5. 业务架构 vs. 技术架构 vs. 基础架构

    基础架构:这个很容易理解,IDC、云平台、网络、分布式存储、数据库、消息中间件、SOA中间件、缓存、监控系统、大数据计算平台
    技术架构:为了支撑某类业务,强调系统的“高性能“,“高并发“,“高可靠”、强一致性等。
    业务架构:同样是为了支撑某类业务,但和技术架构的侧重点不同。业务架构强调的是对“领域”的深刻理解,这通常和“领域专家“密切相关,这里可能会强调系统的“可扩展性”,“可复用性”,对需求的弹性应对。
    自底往上,基础架构、技术架构、业务架构并不是相互独立的,一般都是“业务驱动技术”,2者在互相促进中,同时往深度、广度上发展。

  6. 组织架构与领导力

    合理的团队,组织架构应该是根据业务的架构来拆分的,业务一直在发展,业务的架构也会一直迭代,组织架构也跟着迭代;

架构集成能力

  1. 任何一个项目初期,尽可能选定较高的技术层级,仅在底层系统不满足某些关键技术指标时,才考虑向下替换;
  2. 应避免系统提供的能力涉及多个层次,即使需要如此,也应尽量分成多个解耦的子系统。

高并发处理

高并发问题原因是因为系统中有单点瓶颈,扩容无法继续满足,到最底层实际主要是数据库的问题,因为数据库能承载的并发是有限的。
可以有以下几种方案:

  1. 系统拆分,不同业务的库分开
  2. 增加缓存,降低访问数据库的比例
  3. 消息队列,削峰填谷
  4. 分库、分表、读写分离,降低单库访问量

服务框架的演进趋势

  • 服务框架正在演变成新的“操作系统”
  • 学习曲线:Exponential Rise(渐进式) → Sigmoid(阶跃式)
  • 风格:配置 → 约定 → DSL → 容器器化
  • 业务代码与框架代码的关系:Is-a → Has-a → Duck-typing
  • 工具链:IDE → 代码⽣生成器 → 编译器

其他

  1. 热闹驱动开发(Hype Driven Development,HDD)
  2. gossip as a service
  3. docker、kubernetes
  4. 技术选型
  5. 微服务架构
  6. 网页浏览的步骤
    1. DNS解析
      1. 浏览器缓存
      2. hosts
      3. 域名解析服务器
      4. 根域服务器
      5. 1-4某步骤得到ip后就返回浏览器
      6. 对获得的ip发起TCP请求,从本机的1024<随机端口<65535到服务器的80端口
    2. 负载均衡:将用户分摊到两个或多个服务器上的方法叫负载均衡,balancer and worker
    3. web服务器
    4. 浏览器渲染
  7. SOA是Service Oriented Architecture的缩写,面向服务架构

如何快速熟悉一个新项目

  1. 源码位置、部署环境:所谓项目,其实就是一堆代码放在了一堆机器上而已
  2. 从页面到数据库
  3. 了解项目间的关系
  4. 整理数据库表,整理Controller层的所有接口
  5. 深入代码层
    1. 通过交互对自身数据库进行增删改查操作
    2. 通过定时任务或服务器脚本对自身数据库进行增删改查操作
    3. 调用或通知其他服务做一些事情

从零开始搭建创业公司后台技术栈

从零开始搭建创业公司后台技术栈

系统设计入门

系统设计入门

性能之殇:从冯·诺依曼瓶颈谈起

性能之殇:从冯·诺依曼瓶颈谈起

  1. 乐观给了我们很多的好处,总结起来就是一句话:以微小的性能损失换来大幅的性能提升
  2. 分布式计算来源于人们日益增长的性能需求与落后的 x86 基础架构之间的矛盾。恰似设计模式是面向对象对现实问题的一种妥协
  3. 信息传递的瓶颈最表层是人类的硬件制造水平决定的,再往底层去是冯·诺依曼架构决定的,再往底层去是图灵机的逻辑模型决定的

高并发的哲学原理

高并发的哲学原理

  1. 运维的核心价值不在于资源的扩充,而在于资源的隔离。
  2. 高并发系统通用设计准则
    1. 负载均衡
    2. 缓存技术
    3. 异步处理
    4. 消息队列
    5. 数据库优化
    6. 水平扩展
    7. 服务隔离
  3. 软件也重新定义了运维,k8s成为新的标准运营环境
  4. 在架构上,微服务系统的需求是不会变的,所以 Spring Cloud 和 Kubernetes 有着几乎一一对应的解决方案
  5. Go 语言在设计上有如下几个优势:
    1. 并发模型:基于 CSP(Communicating Sequential Processes)理论,使用 goroutines 和 channels 达成了高并发任务的高效率调度和处理。
    2. 垃圾回收:并发垃圾回收机制,提高垃圾回收效率,使用写屏障技术减少锁使用,提高程序性能。
    3. 编译优化:编译器在编译阶段进行多种优化操作,减少资源消耗,提高运行速度。
    4. 内存管理:自动内存管理,减轻程序员负担,减少内存泄漏等问题。
    5. 标准库:丰富的标准库提供高度优化的函数和类型,提高开发效率,保证程序性能。
  6. Goroutine 拥有如下这些专门的设计来达成超高性能:
    1. 并发执行:Goroutine 可以在多个 CPU 核心上并发执行,充分利用多核处理器的性能。通过在操作系统层面进行调度,Goroutine 可以在不同的核上运行,从而实现真正的并行计算。
    2. 栈空间:Goroutine 的栈空间非常小,通常只有 2KB 左右。这使得大量的 Goroutine 可以在内存中同时存在,而不会因为栈空间的分配和回收导致性能下降。
    3. 上下文切换开销小:Goroutine 的上下文切换开销非常小,因为它们在同一个操作系统线程中运行。当一个 Goroutine 阻塞时,其他 Goroutine 可以继续执行,而不需要等待阻塞的 Goroutine 完成。这避免了传统线程模型中的忙等待问题,提高了程序的执行效率。
    4. 简单易用:Goroutine 的使用非常简单,只需要在函数调用前加上关键字 go 即可创建一个 Goroutine。这使得开发者可以轻松地编写高并发的代码,而不需要关心复杂的线程同步和互斥问题。
    5. 内置调度器:Go 语言内置了一个调度器(scheduler),负责对 Goroutine 进行调度和管理。调度器使用了一种称为 M:N 调度的技术,将多个 Goroutine 分配到多个操作系统线程上执行。这种调度策略可以在保证程序执行顺序的同时,最大限度地利用多核 CPU 的全部计算资源。
  7. 缓存和队列的架构意义
    1. 缓存的本质是用一致性换取读取性能
    2. 队列的本质将关键操作从同步改为异步
    3. 消息订阅-架构解耦对高并发系统架构的决定性影响
    4. Kafka 分布式消息订阅系统

其它

《架构整洁之道》书中提到:一个软件系统存在的意义,是系统用来赚钱或省钱的那部分代码,那才是整个系统的皇冠明珠。所以,当拿到一个需求的时候,首先考虑的是要解决什么问题,它的问题域是什么,而不是先考虑用哪种技术去实现或解决这个问题,这是本末倒置的处理方法。
在一个应用研发过程中,很多时候设计只有一次,就像电影导演说电影是遗憾的艺术,因为没有办法在去修改,有了问题也只能看着,因为电影已经发行。

spring boot 建表 jpa mybatis
反应式编程https://juejin.im/post/5b3a22a16fb9a024db5ff13e
zookeep + dubbo
@Primary @Component @Service
@Autowire @Resource
@Async
各语言内存模型
spring网络请求工具
lambda in java8

websocket统计同时在线人数
异步请求的切面:动态代理的切面不能被正确地加载在异步请求中
避免使用sublist:https://www.cnblogs.com/whatarewords/p/8086844.html
guava cache; caffine : https://www.cnblogs.com/mawang/p/6756192.html

java 完全教程

wrk安装

redis 是怎么存储查找的:效率,底层数据结构

java类库怎么设计

https://www.cnblogs.com/liqiu/p/3302607.html
java中的ArrayList 、List、LinkedList、Collection关系详解

java教程
https://www.mkyong.com/tutorials/spring-boot-tutorials/

https://inneka.com/programming/java/why-does-jackson-2-not-recognize-the-first-capital-letter-if-the-leading-camel-case-word-is-only-a-single-letter-long/
不能只有一个小写字母开头,序列化的时候会出现问题

解决问题的能力 + 学习能力
https://mp.weixin.qq.com/s/o5kX0rfpWmDardxcfwo4wA

软件技术人员能力模型
https://gist.github.com/mcfog/70411189992cee788f15c21f68bba1ae

Buy Me a Coffee