记录－交流－Web开发知识分享
https://github.com/johnlui/PPHC
pdf 下载链接在网站右上角。
本书的目标是在作者有限的认知范围内，讨论一下高并发问题背后隐藏的一个哲学原理——找出单点，进行拆分。
我们将从动静分离讲起，一步步深入 Apache、Nginx、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或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。…
作者：京东科技 皮亮
我们经常提到复杂系统，那么到底什么是复杂系统。我们看下维基的定义：复杂系统（英语：complex system），又称复合系统，是指由许多可能相互作用的组成成分所组成的系统。强调了两点：
两点的规模和复杂性直接决定了系统的复杂程度。比如就拿我们的电商系统举例，分成很多部分，商品、库存、采购、订单、物流、财务，这个只是大的分类，还有针对 C 端的营销、会员、购买、售后等体系，针对 B 端的商家入驻、管理等体系。各个部分、体系之间有着千丝万缕的联系，可谓之复杂系统了。当然了，远远不止这些，随着业务复杂性的不断提升，整个系统的复杂性也会愈来愈复杂。
生活中我们经常谈及 “架构”，那么到底什么是 “架构”，Robert C.Martin《架构整洁之道》中的定义：软件架构是指设计软件的人为软件赋予的形状，这个形状是指系统如何被划分为组件 (Components)，各个组件如何排列（Arrangement），组件之间如何沟通（Communication，通讯），维基百科的定义：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计，IEEE 的定义：架构 = 组成单元的结构 组成单元的关系 原则和指南，总体来看会包括几个内容：
这样说来，我们人类社会本身就是一个社会架构，各种职责、分工、圈层，就我们的软件系统来说，DDD 是架构，MVC 也是架构，大数据设计也有大数据的架构。所以架构无处不在，好的架构能够对特定的问题，特定的领域起到规范和指导作用。
我们知道，架构这个词是源于建筑行业的，英文原词是：Architecture，维基百科上的解释是规划、设计和建造建筑物的过程及产物。那我们就用建筑行业来理解一下。建房子对大家而言再熟悉不过了，那我们盖个小平层、盖个两层小高层、盖个 5 层小高层、搞个 10 层、盖个几百层的摩天大楼的过程、因素、风险是完全不同的。盖摩天大楼需要付出的成本更高，过程中的不确定性更多，挑战和风险也更大，例如如何选地、选择什么样的结构，如何承重，采光如何控制，优化、如何取暖，如何上水、排水，如何通风，如何避震等等。这些东西我们考虑的越多，房子未来的质量，可控性也会越好。
所以架构本质上就是一种指导型的约束，以约定整体和部分、部分和部分之间的关系，以使整体更加稳定，更加可靠。
对这个古老问题的新看法：您应该从头开始重写您的应用程序，还是“任何软件公司都可能犯的最严重的战略错误”？事实证明，处理成熟的代码库有两种以上的选择。
大约二十年前，Joel Spolsky 在他具有里程碑意义的文章“你永远不应该做的事情”中斥责 Netscape 重写了他们的代码库。
他的结论是，一个功能正常的应用程序永远、永远都不应该从头开始重写。他的论点围绕两点展开：
对于许多人来说，乔尔的结论成为了一种信仰。我知道这对我当时的想法影响很大。
在接下来的几年里，我读到一些反对意见，认为在某些情况下，从头开始重写很有意义。例如：
当然，正确的答案是，这在很大程度上取决于具体情况。是的，有时逐步重构遗留代码更有意义。是的，有时候把它全部扔掉并重新开始是有意义的。
但这些并不是唯一的选择。让我们快速浏览一下六个故事，看看我们可以吸取哪些教训。
（奖励：每个故事的 ASCII 艺术摘要！）
网景... 4.0 5.0 ☠ 6.0 来源：网络
一、TCP
流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度
流量控制，就是让发送方的发送速率不要太快，要让接收方来得及接收
利用滑动窗口机制可以很方便地在tcp连接上实现对发送方的流量控制
TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小
重传计时器
TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文
即使接收窗口为0，接收方也会接收：零窗口探测报文段、确认报文段、携带紧急数据的报文段
大家好，我是飞哥！最近我简单研究了一下低延迟网络架构，今天和大家分享分享。
谈到优秀的低延时网络架构，大家首先可能想到的是各家互联网大厂，比如腾讯阿里字节，总会觉得大厂做的肯定最好。但其实在在一般的互联网应用中，用户虽然也讨厌卡顿，但整体上来对延迟其实并不算太敏感，只要按钮点下后一秒之内能响应，用户就基本感觉不出来。甚至是两三秒才响应用户也都还能接受。
所以在今天的互联网公司中，虽然也关注服务访问延迟，但其实优化并没有往特别极致了去做。…
工作 20 多年了，这 20 来年看到了很多公司系统架构，也看到了很多问题，在跟这些公司进行交流和讨论的时候，包括进行实施和方案比较的时候，都有很多各种方案的比较和妥协，因为相关的经历越来越多，所以，逐渐形成了自己的逻辑和方法论。今天，想写下这篇文章，把我的这些个人的经验和想法总结下来，希望能够让更多的人可以参考和借鉴，并能够做出更好的架构来。另外，我的这些思维方式和原则都针对于现有市面上众多不合理的架构和方案，所以，也算是一种“纠正”……（注意，这篇文章所说的这些架构上的原则，一般适用于相对比较复杂的业务，如果只是一些简单和访问量不大的应用，那么你可能会得出相反的结论）…
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 等
我们暂时不讨论高性能计算中的其他常用术语，比如容错、可靠性、高可用性等。
让我们平静一下，旅程即将开始！
大学有一门课程《软件工程》，研究如何组织和管理软件项目。
说实话，这门课不适合本科生，因为学生可能体会不到，课程到底要解决什么问题。只有亲身参与过大项目的开发，经历过大团队，才能感受为什么软件工程很重要，又很难做对。…
近期评论