架构

《高并发的哲学原理》开源图书

https://github.com/johnlui/PPHC

 

阅读地址:https://pphc.lvwenhan.com

pdf 下载链接在网站右上角。

写作目标

本书的目标是在作者有限的认知范围内,讨论一下高并发问题背后隐藏的一个哲学原理——找出单点,进行拆分。

内容梗概

我们将从动静分离讲起,一步步深入 ApacheNginx、epoll、虚拟机、k8s、异步非阻塞、协程、应用网关、L4/L7 负载均衡器、路由器(网关)、交换机、LVS、软件定义网络(SDN)、Keepalived、DPDK、ECMP、全冗余架构、用户态网卡、集中式存储、分布式存储、PCIe 5.0、全村的希望 CXL、InnoDB 三级索引、内存缓存、KV 数据库、列存储、内存数据库、Shared-Nothing、计算存储分离、Paxos、微服务架构、削峰、基于地理位置拆分、高可用等等等等。并最终基于地球和人类社会的基本属性,设计出可以服务地球全体人类的高并发架构。

全书共有 12 章,83 篇文章,总计 167547 字。

是微服务架构不香还是云不香

本文转载自 酷 壳 – CoolShell,作者:陈皓
原文地址:https://coolshell.cn/articles/22422.html

这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务,成本降低90%》,副标题:“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”,有人把这篇文章在五一期间转到了reddit 和 hacker news 上,在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”,还是Amazon干的,这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》,继续抨击微服务架构,于是,瞬间引爆技术圈,登上技术圈热搜。…

浅谈复杂业务系统的架构设计 | 京东云技术团队

作者:京东科技 皮亮

1. 什么是复杂系统

image.png
我们经常提到复杂系统,那么到底什么是复杂系统。我们看下维基的定义:复杂系统(英语:complex system),又称复合系统,是指由许多可能相互作用的组成成分所组成的系统。强调了两点:

  1. 由点组成
  2. 点之间有各种关联

image.png

两点的规模和复杂性直接决定了系统的复杂程度。比如就拿我们的电商系统举例,分成很多部分,商品、库存、采购、订单、物流、财务,这个只是大的分类,还有针对 C 端的营销、会员、购买、售后等体系,针对 B 端的商家入驻、管理等体系。各个部分、体系之间有着千丝万缕的联系,可谓之复杂系统了。当然了,远远不止这些,随着业务复杂性的不断提升,整个系统的复杂性也会愈来愈复杂。

2. 什么是架构

image.png

生活中我们经常谈及 “架构”,那么到底什么是 “架构”,Robert C.Martin《架构整洁之道》中的定义:软件架构是指设计软件的人为软件赋予的形状,这个形状是指系统如何被划分为组件 (Components),各个组件如何排列(Arrangement),组件之间如何沟通(Communication,通讯),维基百科的定义:有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计,IEEE 的定义:架构 = 组成单元的结构 组成单元的关系 原则和指南,总体来看会包括几个内容:

  1. 整体:强调部分的组成,强调合力
  2. 规则:强调部分之间有关联关系,有规则,有约束
  3. 通信:强调部分之间有往来,有交互

这样说来,我们人类社会本身就是一个社会架构,各种职责、分工、圈层,就我们的软件系统来说,DDD 是架构,MVC 也是架构,大数据设计也有大数据的架构。所以架构无处不在,好的架构能够对特定的问题,特定的领域起到规范和指导作用。

3. 架构的本质

image.png

我们知道,架构这个词是源于建筑行业的,英文原词是:Architecture,维基百科上的解释是规划、设计和建造建筑物的过程及产物。那我们就用建筑行业来理解一下。建房子对大家而言再熟悉不过了,那我们盖个小平层、盖个两层小高层、盖个 5 层小高层、搞个 10 层、盖个几百层的摩天大楼的过程、因素、风险是完全不同的。盖摩天大楼需要付出的成本更高,过程中的不确定性更多,挑战和风险也更大,例如如何选地、选择什么样的结构,如何承重,采光如何控制,优化、如何取暖,如何上水、排水,如何通风,如何避震等等。这些东西我们考虑的越多,房子未来的质量,可控性也会越好。

所以架构本质上就是一种指导型的约束,以约定整体和部分、部分和部分之间的关系,以使整体更加稳定,更加可靠。

image.png

4.

重写、重构还是重新发明?6 个软件重写故事的经验教训

重写、重构还是重新发明?

6 个软件重写故事的经验教训

对这个古老问题的新看法:您应该从头开始重写您的应用程序,还是“任何软件公司都可能犯的最严重的战略错误”?事实证明,处理成熟的代码库有两种以上的选择。

大约二十年前,Joel Spolsky 在他具有里程碑意义的文章“你永远不应该做的事情”中斥责 Netscape 重写了他们的代码库。

他的结论是,一个功能正常的应用程序永远、永远都不应该从头开始重写。他的论点围绕两点展开:

  • 应用程序代码库中看起来很粗糙的部分通常嵌入了关于极端情况和奇怪错误的来之不易的知识。
  • 重写是一项漫长的工作,它使您无法改进现有产品,而在此期间竞争对您有利。

对于许多人来说,乔尔的结论成为了一种信仰。我知道这对我当时的想法影响很大。

在接下来的几年里,我读到一些反对意见,认为在某些情况下,从头开始重写很有意义。例如:

  • 有时,遗留代码库确实一团糟,无法修复,以至于即使是简单的更改也需要对代码的其他部分进行级联更改。
  • 最初的技术选择可能会阻止您进行必要的改进。
  • 或者,原始技术可能已经过时,导致很难(或昂贵)招募到优秀的开发人员。

当然,正确的答案是,这在很大程度上取决于具体情况。是的,有时逐步重构遗留代码更有意义。是的,有时候把它全部扔掉并重新开始是有意义的。

但这些并不是唯一的选择。让我们快速浏览一下六个故事,看看我们可以吸取哪些教训。

(奖励:每个故事的 ASCII 艺术摘要!)

1.网景

网景...  4.0  5.0 ☠ 6.0  

图解 TCP、UDP,流量控制,拥塞控制,一次看懂

来源:网络

图片

一、TCP

  • TCP首部
  • 流量控制
  • 拥塞控制
  • 三次握手,四次挥手
  • tcp 怎样保证数据正确性?

流量控制是为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度

1、TCP首部

图片

源端口号
目标端口号
32位序列号
32位确认号
首部长度(单位为4字节,默认为5,即20字节)
保留位(6位)
6个控制位(SYN、ACK、FIN、PUSH、URG、RST) 
SYN:同步序号位,TCP建立连接时要将这个值设为1
ACK:为1表示确认号 
FIN:发送端完成位,提出断开连接的一方把FIN置为1表示要断开连接 
PUSH:急迫位,缓存区将满,立刻传输速度 
RST:重置位,连接断了重新连接 
URG:紧急信号
16位窗口大小:接收窗口大小,流量控制使用,如果窗口大小为0,可以发送窗口探测
16位校验和:校验和用来做差错控制,TCP校验和的计算包括TCP首部、数据和其它填充字节。在发送TCP数据段时,由发送端计算校验和,当到达目的地时又进行一次检验和计算。如果两次校验和一致,说明数据是正确的,否则将认为数据被破坏,接收端将丢弃该数据
16位紧急指针:仅在URG控制位为 1 时有效。表示紧急数据的末尾在 TCP 数据部分中的位置。通常在暂时中断通信时使用(比如输入 Ctrl C)

2、流量控制

图片

流量控制,就是让发送方的发送速率不要太快,要让接收方来得及接收

利用滑动窗口机制可以很方便地在tcp连接上实现对发送方的流量控制

TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小

重传计时器

TCP发送方收到接收方的零窗口通知后,应启动持续计时器。持续计时器超时后,向接收方发送零窗口探测报文

即使接收窗口为0,接收方也会接收:零窗口探测报文段、确认报文段、携带紧急数据的报文段

TCP发送方的发送窗口大小

    

盘点低延时网络架构中使用的那些黑科技!

大家好,我是飞哥!最近我简单研究了一下低延迟网络架构,今天和大家分享分享。

谈到优秀的低延时网络架构,大家首先可能想到的是各家互联网大厂,比如腾讯阿里字节,总会觉得大厂做的肯定最好。但其实在在一般的互联网应用中,用户虽然也讨厌卡顿,但整体上来对延迟其实并不算太敏感,只要按钮点下后一秒之内能响应,用户就基本感觉不出来。甚至是两三秒才响应用户也都还能接受。

所以在今天的互联网公司中,虽然也关注服务访问延迟,但其实优化并没有往特别极致了去做。…

            

我做系统架构的一些原则

工作 20 多年了,这 20 来年看到了很多公司系统架构,也看到了很多问题,在跟这些公司进行交流和讨论的时候,包括进行实施和方案比较的时候,都有很多各种方案的比较和妥协,因为相关的经历越来越多,所以,逐渐形成了自己的逻辑和方法论。今天,想写下这篇文章,把我的这些个人的经验和想法总结下来,希望能够让更多的人可以参考和借鉴,并能够做出更好的架构来。另外,我的这些思维方式和原则都针对于现有市面上众多不合理的架构和方案,所以,也算是一种“纠正”……(注意,这篇文章所说的这些架构上的原则,一般适用于相对比较复杂的业务,如果只是一些简单和访问量不大的应用,那么你可能会得出相反的结论)…

从 0 到 1 亿用户的架构设计

图片

Kirill Sh@Unsplash

高可用架构设计最核心的就是两点:解耦和冗余。解耦包括业务状态分离(无状态架构设计)、分库分表等。冗余包括缓存、CDN、主从备份、主主备份、GeoDNS 等。一个好的架构设计需要在产品迭代的不同阶段选择合适的技术,从而既能在合理的成本条件下有效保障当前的业务需求,又能考虑到业务下一步发展的可能性。原文链接:[How to design a system to scale to your first 100 million users](https://levelup.gitconnected.com/how-to-design-a-system-to-scale-to-your-first-100-million-users-4450a2f9703d)

对于软件架构师来说,设计一个支持数亿用户的系统是一个巨大的挑战(不过在读了这篇文章后,也许就没那么难了)

以下是本文涉及的一些主题:

  • 从最简单的开始:单体架构

  • 可伸缩性的艺术:水平扩展(scaling out),纵向扩展(scaling up)

  • 关系型数据库的可扩展性:主从备份、主主备份、联合、分片、去规范化和 SQL 调优

  • 数据库选型:NoSQL 还是 SQL?

  • 高级概念:缓存、CDN、GeoDNS 等

我们暂时不讨论高性能计算中的其他常用术语,比如容错、可靠性、高可用性等。

让我们平静一下,旅程即将开始!

从 0