元数据
元数据
[!abstract] 阿里云运维架构实践秘籍
阿里云运维架构实践秘籍|200 - 书名： 阿里云运维架构实践秘籍
- 作者： 驻云科技 乔锐杰
- 简介： 本书内容主要分为四大篇：云端基础篇、云端选项篇、云端安全篇、云端架构篇。总共十八个章节，所以我更喜欢把本书的内容称为云端实践秘籍：“降云十八掌”。本书内容主要为历时八年、累积云端五千余家一线互联网企业实践干货及经验，包含云端二十余款热门产品实践、五十余项常见开源热门技术实践，以及云端热门技术：云端监控、云端DevOps/云端容器、云端智能运维等的佳实践。内容风格上，以案例、场景、实践经验为主。杜绝一些无关痛痒的软件安装、参数配置等充篇幅的内容。减少理论，偏向干货。为您在风起“云”涌的时代，提供过关斩将的“尚方宝剑”。
- 出版时间： 2022-12-23 00:00:00
- ISBN： 9787111649694
- 分类： 计算机-编程设计
- 出版社： 机械工业出版社
- PC地址：https://weread.qq.com/web/reader/e9e322a071d3804fe9e9cff
高亮划线
3.5 “世界上最好”的语言
📌 Tomcat是一个轻量级中间件，一般单台Tomcat的极限并发能力在1000左右。所以单台Tomcat适合部署在中低配的服务器配置中，比如4核8GB是部署单台Tomcat的完美服务器配置；而在8核16GB等中高配的服务器配置中，运行单台Tomcat往往会造成服务器的性能浪费；对于中高配的服务器，要想把服务器性能都利用起来，不让服务器的配置浪费，一般要在中高配服务器中跑多个Tomcat。 ^30638159-126-1306-1500
- 💭 tomcat 极限1000并发，4核8g，刚刚好。8核16g，性能过剩，可以部署其他服务来压榨内存和CPU。 - ⏱ 2025-04-14 19:52:37
📌 云服务器ECS的网络类型分为经典网络和VPC专有网络两种。
⏱ 2025-04-17 08:12:52 ^30638159-132-546-575
📌 经典网络采用三层 （网络层，即IP层） 隔离，所有的经典网络类型实例都建立在一个共用的基础网络上。VPC采用二层隔离 （数据链路层） ，相对经典网络而言，VPC具有更高的安全性和灵活性。 ^30638159-132-633-726
- 💭 一、数据链路层隔离的核心技术
基于隧道的二层扩展
通过VPN 隧道技术（如 IPSec、GRE）在公有网络中创建逻辑隔离的私有网络通道，确保不同 VPC 的流量在隧道内传输，避免直接暴露于公网。
隧道两端通过虚拟隧道接口（VTI）关联，实现跨地域或跨网络的二层通信。
分布式交换机与 MAC 地址管理
VPC 内的交换机采用分布式架构，支持MAC 地址学习和帧转发，仅允许同一 VPC 内的节点通过 MAC 地址直接通信。
通过硬件交换机实现高速帧传输，结合控制器动态下发转发表，确保流量路径灵活可控。
二、SDN 控制器的核心作用
策略驱动的网络配置
控制器（如阿里云的 VPC 控制器）通过OpenFlow或NetConf协议与交换机、网关交互，动态下发路由表、安全组规则等配置。
支持用户自定义IP 段划分、子网掩码和路由策略，实现灵活的网络拓扑调整。
多链路冗余与容灾
控制器集群多机房互备，通过BGP 协议实现跨区域路由同步，确保链路故障时自动切换至备份路径。
三、硬件与软件的协同架构
自研交换机与网关
阿里云基于硬件网关和自研交换机构建 VPC 数据通路，支持硬件级流量调度和低延迟传输。
网关负责公网流量与私有网络之间的转换，通过NAT技术实现安全隔离。
分离的配置与数据通路
配置通路：控制器通过 API 或管理界面接收用户策略，生成配置指令下发至设备。
数据通路：交换机和网关直接处理帧转发，与控制逻辑解耦，提升传输效率。 - ⏱ 2025-04-17 08:13:36
📌 在云端对ECS实现入网请求的功能，可以通过以下4种方法实现。 ^30638159-133-417-447
- 💭 云端访问ecs，可以通过以下方式：slb，公网ip，弹性eip，dnat - ⏱ 2025-04-18 06:42:28
📌 负载均衡类，一般都是多台机器同时对外提供服务，尤其是在Web应用中尤为常见。
⏱ 2025-04-18 06:45:43 ^30638159-133-948-986
📌 在很多场景中，给服务器开公网带宽只是为了让服务器能够远程SSH连接而已。我见到过这样的场景，一个客户有二三十台服务器，为每台服务器开个公网IP，目的就是方便远程，但这样使用的合理性、安全规范性有很大隐患。 ^30638159-133-1696-1798
- 💭 我也想这么干 - ⏱ 2025-04-18 06:46:14
📌 远程登录流程架构图 ^30638159-133-2159-2168
- 💭 这样就不需要每台ecs服务器绑定公网 - ⏱ 2025-04-18 06:35:05
📌 给ECS绑定公网存在很大安全隐患，这等同于给黑客开了一道能触达ECS的门，方便通过端口扫描、漏洞嗅探实现入侵。 ^30638159-133-2286-2341
- 💭 有安全隐患 - ⏱ 2025-04-18 06:34:06
📌 比如让ECS绑定公网，外网就不能直接访问） 。 ^30638159-133-2435-2458
- 💭 都绑定公网了，还不让外网访问？ - ⏱ 2025-04-18 06:32:51
📌 直接绑定公网一般适用于在服务器上部署了FTP等功能，由于服务协议的关系等，没办法直接通过SLB负载均衡的方式把服务暴露给公网。
⏱ 2025-04-18 06:33:50 ^30638159-133-2458-2521
📌 ECS实现出网请求的功能，可以通过以下3种方法实现。 ^30638159-134-421-447
- 💭 出网请求方式：公网ip，弹性eip，snat - ⏱ 2025-04-18 06:46:42
📌 SNAT：通过路由将公网请求的流量映射到NAT网关，或者一台具有公网访问能力的ECS上，再由这台ECS将公网请求流量转发出去。
⏱ 2025-04-20 07:00:56 ^30638159-134-621-684
📌 阿里云流量带宽峰值、流量带宽费用针对的是出口流量峰值及出口流量带宽费用。 ^30638159-134-1186-1222
- 💭 出口流量 - ⏱ 2025-04-20 07:05:54
📌 Nginx相比Apache，高性能、高并发、系统资源占用少。Nginx核心特点是轻量级!Nginx官网表示，Nginx保持10000个没有活动的连接，而这些连接只占用2.5MB内存。而在3万并发连接下，开启10个Nginx线程消耗的内存不到200MB
⏱ 2025-04-20 21:35:56 ^30638159-137-446-571
📌 我们做了十万在线用户的压测，发现Apache的极限抗并发能力为3000～5000。后面如果有更多的请求，Apache将会严重超时，服务器负载也较高。
⏱ 2025-04-22 06:57:53 ^30638159-138-1292-1366
📌 上述架构中，3台MySQL主主同步架构也不建议运用在生产环境中，因为主主同步架构在高并发场景下，在不同主机上同时对某条数据进行写操作，很可能导致数据不一致性的问题。 ^30638159-138-1422-1504
- 💭 mysql主主同步架构很多坑 - ⏱ 2025-04-22 06:58:38
📌 Web缓存服务方面，Nginx可通过自身的proxy_cache模块实现类Squid等专业缓存软件的功能。在静态缓存这块，一般采用Squid、Varnish、Nginx，当前CDN产品的实现，底层其实就是采用这3个开源缓存技术。
⏱ 2025-04-22 07:00:16 ^30638159-139-415-529
📌 而Nginx源代码采用C语言开发，这将使我们的二次开发变得非常复杂。为了方便开发人员，OpenResty整合了Nginx和Lua的框架，它帮我们实现用Lua的规范开发实现各种业务，并且厘清各个模块的编译顺序。 ^30638159-140-668-772
- 💭 OpenResty 整合了nginx和lua - ⏱ 2025-04-24 06:27:30
📌 Nginx+Lua主要实现七层复杂逻辑控制，主要针对七层HTTP头、IP访问判断、SQL注入判断等。
⏱ 2025-04-24 06:28:52 ^30638159-140-888-938
📌 OpenResty是云端开源WAF的最佳实践。
⏱ 2025-04-27 19:02:38 ^30638159-140-994-1017
📌 在开源的软件负载均衡中，应用最为广泛的为LVS、Nginx、HAProxy，甚至阿里云的SLB也是基于LVS及Nginx的 ^30638159-142-419-480
- 💭 四大热门负载均衡 - ⏱ 2025-04-24 07:02:08
📌 云端实践中不支持在ECS中部署使用LVS。
⏱ 2025-04-27 19:13:58 ^30638159-142-533-554
📌 不支持Keeplived的部署
⏱ 2025-04-27 19:14:03 ^30638159-142-635-650
📌 工作在网络二层/三层/四层之上仅作分发之用，对CPU和内存消耗极低，抗负载能力极强
⏱ 2025-04-24 07:11:18 ^30638159-142-1309-1350
📌 应用范围比较广，因为LVS工作在二层/三层/四层最底层，所以它几乎可以对所有应用做负载均衡，包括HTTP、数据库、在线聊天室等，并且LVS的3种工作模式、10种调度算法使其在负载均衡端有更灵活的策略选择。
⏱ 2025-04-24 07:11:59 ^30638159-142-1528-1630
📌 云端ECS不支持LVS的部署
⏱ 2025-04-24 07:12:19 ^30638159-142-1707-1721
📌 LVS不支持七层的虚拟主机、Rewrite正则表达式处理、动静分离等功能
⏱ 2025-04-24 07:12:31 ^30638159-142-1811-1847
📌 LVS适合应用在中大型应用中，不适合中小型应用，特别是中小型网站的应用
⏱ 2025-04-24 07:13:00 ^30638159-142-1920-1955
📌 特点是占用内存少、并发能力强，加上丰富的插件功能模块，当前是云端Web类应用中首选的一款软件。以下是它的具体特性。 ^30638159-142-2389-2446
- 💭 nginx 特点 - ⏱ 2025-04-24 07:14:24
📌 1) 可以做七层HTTP的负载均衡，可以针对HTTP应用做一些分流的策略
⏱ 2025-04-24 07:16:51 ^30638159-142-2475-2511
📌 2) Nginx之前的版本只支持七层HTTP的负载均衡功能。从1.9.0版本开始，Nginx支持对四层TCP的负载均衡功能。
⏱ 2025-04-24 07:16:46 ^30638159-142-2679-2741
📌 3) Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，同时也是功能强大的Web应用服务器。
⏱ 2025-04-24 07:16:40 ^30638159-142-2863-2911
📌 4) Nginx现在作为Web反向加速静态缓存越来越成熟，Nginx也可作为静态网页和图片服务器。
⏱ 2025-04-24 07:17:15 ^30638159-142-2991-3040
📌 对后端服务器的健康检查，只支持通过端口来监测，不支持通过URL来监测。这就会导致，在七层的健康监测中，很多情况下端口是正常的，但应用URL访问异常，Nginx却不能识别，反而主动剔除这个有问题的服务器，最终导致客户端继续访问有异常的服务器。
⏱ 2025-04-27 19:18:09 ^30638159-142-3341-3461
📌 阿里云SLB (Server Load Balancer) 当前提供四层 （TCP协议和UDP协议） 和七层 （HTTP和HTTPS协议） 的负载均衡服务，SLB的架构如图4-4所示
⏱ 2025-04-28 06:57:23 ^30638159-142-5333-5424
📌 四层采用开源软件LVS (Linux Virtual Server) +Keepalived的方式实现负载均衡，并根据云计算需求对其进行了个性化定制。
⏱ 2025-04-28 06:57:17 ^30638159-142-5454-5529
📌 七层采用Tengine实现负载均衡。Tengine是由淘宝网发起的Web服务器项目，在Nginx的基础上，针对有大访问量的网站需求添加了很多高级功能和特性。
⏱ 2025-04-28 06:57:40 ^30638159-142-5558-5636
📌 OSI七层模型主要作为一个通用模型来做理论分析，它是一个理论模型。而TCP/IP通信协议模型 （四层） 是互联网的实际通信协议，两者一般做映射对比及分析，如表4-1所示。
⏱ 2025-04-28 07:04:26 ^30638159-143-838-923
📌 [插图]
⏱ 2025-04-28 07:08:10 ^30638159-143-1165-1166
📌 而常见的负载均衡有很多，有出名的硬件负载均衡，如F5、Netscaler；还有常见开源的负载均衡，比如LVS、HAProxy、Nginx，甚至Apache也能做负载均衡 （不推荐） 。我们常说的七层负载均衡、四层负载均衡，也是基于OSI七层模型的。基于OSI七层模型的底层原理，我们把常见的负载均衡具体划分为以下几个类型：二层、三层、四层、七层。最后再加上一个除OSI七层模型以外的DNS （如表4-2所示） ，通过DNS做负载均衡的场景也是非常常见的。
⏱ 2025-04-28 07:08:23 ^30638159-143-1197-1424
📌 [插图]
⏱ 2025-04-28 07:08:01 ^30638159-143-1658-1659
📌 [插图]
⏱ 2025-04-28 07:09:47 ^30638159-143-2447-2448
📌 [插图]
⏱ 2025-04-28 07:09:59 ^30638159-143-2630-2631
📌 IPVS：是LVS集群系统的核心部分，是基于Linux Netfilter框架实现的一个内核模块，主要工作于内核空间的INPUT链上。
⏱ 2025-04-28 07:14:37 ^30638159-143-2662-2729
📌 LVS原理架构

⏱ 2025-04-28 07:23:15 ^30638159-143-3868-4058
📌 [插图]
⏱ 2025-04-28 07:25:00 ^30638159-143-4762-4763
📌 [插图]
⏱ 2025-04-28 07:25:22 ^30638159-143-5067-5068
📌 [插图]
⏱ 2025-04-28 07:25:25 ^30638159-143-5252-5253
📌 综上所述，因为七层中能获取应用层HTTP的请求内容，所以七层负载均衡有如下常见应用场景：
• 七层作用在HTTP应用层，所以七层的负载均衡只能跟Tomcat、PHP等Web服务做负载均衡。
• 可以根据请求的域名来做转发。比如请求者访问A域名，转发到后端A服务器；请求访问B域名，转发到后端B服务器。这个功能，在七层叫虚拟主机功能，是七层应用中最为热门的应用实践。
⏱ 2025-05-06 21:03:50 ^30638159-143-14070-14304
📌 再举个七层负载均衡实践的例子，要访问我们驻云内部的某个系统，要求客户端必须使用Chrome浏览器，可参考以下核心配置：
⏱ 2025-05-06 19:46:15 ^30638159-143-15105-15201
📌 实现的核心配置就是获取七层头信息里面的数据来做对比判断，如果符合，执行对应的操作即可。这个是四层/二层负载均衡无法实现的功能。
⏱ 2025-05-06 19:46:02 ^30638159-143-15550-15613
📌 LVS能够做到“一次连接”的本质原因是LVS工作在内核空间。LVS 3种模式都是工作在内核空间，数据包的处理也仅在内核空间，这也是LVS轻量高效、高性能的最为本质的原因，如图4-13所示。
⏱ 2025-05-06 19:50:58 ^30638159-143-16095-16189
📌 而相比于LVS，Nginx/HAProxy四层工作在用户空间，对数据包的处理是在用户空间完成的，数据包的流转及处理过程增多，这也是Nginx/HAProxy的性能和达不到LVS这个量级的本质原因，如图4-15所示。
⏱ 2025-05-06 19:51:46 ^30638159-143-17233-17340
📌 所以在后端服务器中，HTTP头的remote_addr虽然代表客户端的IP，但实际值是负载均衡的IP。为了避免这个情况，七层负载均衡通常会增加一个叫作x_forwarded_for的头信息，把连接它的客户端IP （上网机器IP） 加到这个头信息里，这样就能保障后端服务器可以获取到客户端真实的IP。
⏱ 2025-05-06 19:52:21 ^30638159-143-18238-18387
📌 设置DNS的负载均衡，落到不同源IP （也可以是负载均衡的VIP地址） 的请求流量往往分布得很不均匀。有可能是某个后端地址的请求量很大，而另一个后端地址的请求量却很小。
⏱ 2025-05-06 19:56:42 ^30638159-143-20095-20179
📌 由于客户端往往有DNS相应缓存，如若DNS解析的某个源IP服务异常，一般它不会主动剔除这个有异常的源IP解析。这可能会导致部分客户的解析访问还是这个有异常的服务地址。虽然现在DNS有智能解析的高级功能，能主动监测后端服务的可用性
⏱ 2025-05-06 19:55:53 ^30638159-143-20211-20325
📌 DNS的负载均衡，一般在超大规模的应用中，特别是跨地域的分布式应用中运用得非常广泛，常规的中小型、中大型应用，不是特别推荐尝试DNS的负载均衡。
⏱ 2025-05-06 19:55:22 ^30638159-143-20474-20546
📌 不同负载均衡的类型的功能特性汇总如表4-6所示。
⏱ 2025-05-06 19:59:18 ^30638159-143-20631-20655
📌 [插图]
⏱ 2025-05-06 19:59:03 ^30638159-143-21082-21083
📌 之所以把Nginx/HAProxy七层/四层也称为反向代理，是因为Nginx/HAProxy的七层/四层应用有如下特性。
- 在转发客户端请求的过程中建立了“两次连接”。在接受了客户端请求后会将请求重新封装，以类似“代理”的角色重新将其转发给后端。
- 与后端服务器能进行跨VLAN传输，甚至可以基于Internet进行传输
⏱ 2025-05-06 20:06:36 ^30638159-144-734-954
📌 之所以把LVS称为负载均衡而不是反向代理，是因为LVS的以下特性：
• 在转发客户端请求的过程中，只建立了“一次连接”，对客户端请求数据包只做纯转发。
• 与后端服务器只能在一个VLAN中，不能跨VLAN。
由以上两点可以看到，LVS单纯只做分流转发，只具备负载均衡的功能。
⏱ 2025-05-06 20:06:16 ^30638159-144-2160-2377
📌 通过实践应用汇总的常用Web中间件及软件负载均衡的抗并发能力级别如表4-7所示。
表4-7 负载均衡的性能对比

⏱ 2025-05-06 20:34:34 ^30638159-145-771-1048
📌 而IIS、Apache、Tomcat服务器都是Web服务器，底层基于Select网络模型，擅长进行逻辑处理，适合处理Web类请求应用，不适合高并发场景，基本上极限并发能力在千这个量级别。而Nginx/HAProxy底层基于Epoll网络模型，擅长进行网络流量转发及I/O处理，所以适合高并发场景
⏱ 2025-05-06 23:27:34 ^30638159-145-1652-1799
📌 因为四层在性能方面更加强悍，在应用入口采用四层负载均衡进行分流是标准且成熟的企业级架构。
⏱ 2025-05-06 23:30:52 ^30638159-146-1198-1271
📌 还是建议前端采用四层负载均衡，证书放在后端ECS中的Nginx进行配置
⏱ 2025-05-06 23:30:38 ^30638159-146-1341-1376
📌 随着KVM的推出，当前阿里云基于KVM自主研发的飞天系统已经支持两万台物理机进行集群。在磁盘I/O上，推出高效云盘、SSD云盘，彻底解决了之前云盘I/O低的问题，并且成为当前云盘默认的主流标配产品。
⏱ 2025-05-07 10:50:10 ^30638159-148-1833-1932
📌 [插图]
⏱ 2025-05-07 23:29:31 ^30638159-148-2216-2217
📌 共享块存储产品本身并不提供集群文件系统，需要自行安装集群文件系统来管理共享块存储。如果只是将共享块存储挂载到多台ECS实例，依旧使用常规文件系统来管理时，会造成磁盘空间分配冲突和数据文件不一致两个问题
⏱ 2025-05-07 23:30:55 ^30638159-149-665-765
📌 共享文件存储是基于网络+文件系统级别的共享。而共享块存储是基于网络+块存储级别的共享，类似磁盘ISCSI技术
⏱ 2025-05-08 20:47:49 ^30638159-150-711-765
📌 强一致性：即任何对文件的修改成功返回后，后续的访问会立即看到该修改的最终结果。这是和共享块存储最大的不同，共享块存储需要通过集群文件系统保障数据读写的强一致性。
⏱ 2025-05-08 20:47:48 ^30638159-150-816-896
📌 与块存储和文件存储管理数据的方式不同，对象存储是以对象的形式管理数据的。对象和文件最大的不同就是在文件的基础之上增加了元数据。一般情况下，对象分为3个部分：数据、元数据以及对象ID
⏱ 2025-05-09 09:35:51 ^30638159-151-410-500
📌 。而CDN没办法对块存储和文件存储中的数据直接做静态加速，需要结合HTTP服务才能间接对其中的数据进行加速访问。
⏱ 2025-05-09 09:58:13 ^30638159-151-1726-1782
4.5 云端缓存的两大选型秘籍
📌 那么在什么时间点需要考虑缓存介入来提升性能呢？这里建议参考一下“I/O 5分钟法则”，我觉得其在缓存领域也非常适用：“即如果一条记录频繁被访问，就应该考虑放到缓存里。否则的话，客户端就按需要直接去访问数据源，而这个临界点就是5分钟。”
⏱ 2025-05-09 10:05:44 ^30638159-152-716-834
📌 静态缓存的实现技术主要有Squid、Varnish、Nginx。Squid是一个代理缓存服务器，它支持FTP、Gopher、HTTPS和HTTP协议
⏱ 2025-05-09 10:09:06 ^30638159-153-567-641
📌 Squid、Varnish、Nginx缓存功能特性对比[插图]
⏱ 2025-05-09 10:09:32 ^30638159-153-890-951
📌 互联网高速公路的最后一公里”正是对CDN的形象描述。
⏱ 2025-05-09 10:11:16 ^30638159-153-1634-1660
📌 这层二级缓存可以起到加速后端Web服务器响应及降低NFS （或本地存储） 文件服务器磁盘I/O压力的作
⏱ 2025-05-09 10:14:02 ^30638159-153-2565-2616
📌 CAP定理 (CAP theorem) ，在2000年由Eric Brewer教授提出，又被称作布鲁尔定理(Brewer’s theorem) 。它指出对于一个分布式系统来说，其不可能同时满足以下3点。• Consistency （一致性） ：所有节点在同一时间具有相同的数据。• Availability （可用性） ：保证每个请求不管成功或者失败都得到响应。• Partition tolerance （分区容错性） ：系统中任意信息的丢失或失败不会影响系统的继续运作。
⏱ 2025-05-09 10:36:39 ^30638159-156-454-773
📌 因此系统架构师不要把精力浪费在如何才能设计出同时满足CAP三者的完美分布式系统上，而应该研究如何进行取舍，以满足实际的业务需求。
⏱ 2025-05-09 10:34:23 ^30638159-156-832-896
📌 ACID模型是指在数据库管理系统 (DBMS) 中，事务 (Transaction) 所具有的如下4个特性。• Atomicity：原子性；• Consistency：一致性；• Isolation：隔离性；• Durability：持久性。
⏱ 2025-05-09 10:36:27 ^30638159-156-1045-1274
📌 传统关系型数据库实现了CAP定理中的Consistency （一致性） 和Availability （可用性） ，但对Partition Tolerance （分区容错性） 不够支持。
⏱ 2025-05-09 10:36:31 ^30638159-156-1303-1395
📌 但关系型数据库对集群的Sharding （分片） 支持极弱，如Oracle、MySQL、SQL Server等典型的关系型数据库，并没有MongoDB、Redis对应的Sharding （分片） 集群功能。
⏱ 2025-05-09 10:35:11 ^30638159-156-1479-1582
📌 BASE模式呢？它具有以下特性。• Basically Availble：基本可用；• Soft-state：软状态；• Eventual Consistency：最终一致性。
⏱ 2025-05-09 10:36:56 ^30638159-156-2075-2244
📌 BASE思想主要强调基本的可用性，支持分区失败，允许状态在一定时间内不同步，保证数据达到最终一致性即可。所以BASE模型也是对CAP定理的实现，实现了CAP定理中的Availability （可用性） 和Partition tolerance （分区容错性） ，弱化了Consistency （一致性）
⏱ 2025-05-09 10:36:11 ^30638159-156-2309-2460
📌 ostgreSQL的主要优点是，基于坚实的RDBMS实现 （实现了CAP定理中的Consistency （一致性） 和Availability （可用性） ) ，因其稳定性和功能集而倍受青睐。特别是对JSON数据类型和运算符的支持，以及在新版本中提高了分布式数据库的性能和支持，让其在数据库领域格外耀眼。
⏱ 2025-05-09 10:41:45 ^30638159-156-4275-4427
📌 MongoDB的主要优点是面向文档存储，它支持的数据结构是类似JSON的BSON格式，在使用MongoDB的时候，首选要学会忘记SQL。相较于通过表状的结构来保存数据，文档结构的存储方式能够更加便捷地获取数据。在MongoDB中，不用因为增加一个属性而去声明表结构及字段类型，而在MongoDB中这些都是不需要的，这一优势给我们的业务开发带来了很大便捷性。同时MongoDB使用的是内存映射存储引擎，特别是大内存的服务器让其性能更优越，加上提供内置Sharding+GridFS出色的分布式文件系统功能，其在海量数据存储、高并发读写的场景下有得天独厚的优势。
⏱ 2025-05-09 10:41:31 ^30638159-156-4625-4904
📌 Redis在Key-Value数据库领域提供丰富的数据结构存储、数据持久化 （内存数据保存在磁盘中） 、主从及Sharding集群的架构功能，故其适用于很多业务场景，几乎取代了Memcache。
⏱ 2025-05-09 10:42:13 ^30638159-156-5169-5266
📌 表4-12 数据库性能对比[插图]
⏱ 2025-05-09 10:43:56 ^30638159-157-608-655
📌 在关系型数据库中，单表存储的极限在亿级别。特别是MySQL，单表存储过亿时，数据查询会异常缓慢。而Redis、MongoDB、HBase等非关系型数据库，都支持Sharding分区功能，数据存储基本不受限制。在QPS方面，关系型数据库的极限在万级别，而非关系型数据库，根据集群规模不同，能轻松应对10万级别以上的高并发读写需求。
⏱ 2025-05-09 10:44:06 ^30638159-157-838-1002
📌 进行一个数据库的选型，主要需要考虑如下两点：• 一是业务侧的背景需求
⏱ 2025-05-09 10:44:35 ^30638159-158-462-523
📌 二是运维侧的架构需求
⏱ 2025-05-09 10:44:37 ^30638159-158-663-674
5.1 衡量业务量的指标
📌 PV访问量、IP访问量、用户数、活跃用户数等都是常见衡量业务访问量大小的指标。通过合适的指标来评估及衡量业务量，是我们做容量配置规划的基础也是第一步。
⏱ 2025-05-09 10:47:18 ^30638159-160-407-482
📌 如果未来业务量增加，要做容量规划和成本评估，可以直接根据对应的业务指标将当前系统性能状态指标关联起来。常见的做法是使用简单的四则运算，比如，100万用户量，当前用了10台服务器，业务高峰期资源使用率是50%。如果变成200万用户量，至少要再加10台服务器
⏱ 2025-05-10 21:09:53 ^30638159-164-1756-1883
📌 一天中的80%业务请求量主要发生在40%的时间内，这成为我们计算PV值对应请求压力的重要依据
⏱ 2025-05-10 21:08:00 ^30638159-165-858-904
📌 假如一天中高峰期的请求量是平时请求的两倍或3倍
⏱ 2025-05-10 21:07:53 ^30638159-165-1442-1466
📌 IP的访问量转到PV访问量，其实转换的核心在于Web网站的业务类型，不同业务特性的计算模型实践总结如表5-2所示，仅供读者参考。
表5-2 不同业务特性的计算模型

⏱ 2025-05-11 07:59:29 ^30638159-166-823-1126
📌 计算模型参考：
用户数×业务因子 (10%～30%) =活跃用户数
活跃用户数×业务因子 (10%～30%) =在线用户数
在线用户数×业务因子 (10%～30%) =并发用户数≈每秒请求数 ^30638159-166-2041-2214
- 💭 计算因子就是访问模式，反应了真正发给后端的请求量 - ⏱ 2025-05-11 08:08:20
📌 一台8核16GB的服务器基本上能处理Web类应用上百的请求，所以可以对应100万PV。 ^30638159-168-558-601
- 💭 这两句话是怎么计算出来的？ - ⏱ 2025-05-11 10:59:03
📌 主要原因在于大家对相应中间件的特性不了解，不知道采用什么样的服务器配置最合理，因此采用高配的服务器相对会比较保险
⏱ 2025-05-12 08:52:11 ^30638159-169-592-648
📌 1∶2的处理器与内存配比可以获得最优计算资源性价比
⏱ 2025-05-14 08:35:23 ^30638159-169-1460-1485
📌 Tomcat适用中低配：2核4GB、4核8GB，特别是4核8GB是最优选择。因为Tomcat是单进程多线程的模式，是个轻量级且并发请求数最多也就只能跑到1000左右。所以单台Tomcat高配的服务器并不能跑满服务器的性能，会造成很大的资源浪费。如果想跑满中高配服务器性能，常规做法就是在一台服务器上部署多台Tomcat。
⏱ 2025-05-15 10:02:09 ^30638159-169-1931-2091
📌 因为PHP是多进程模式，常规的PHP-FPM就是PHP的FastCGI进程管理器。不管低配、中配还是高配，都能跑满服务器性能，所以PHP的实践配置是根据业务访问量来决定的。PHP的进程管理，在实践中低配适用于动态模式，高配适用于静态模式，这会让PHP的性能达到最优。由此也可以看到，PHP的多进程的模式相比于Tomcat单进程多线程的模式，在性能架构方面更优。
⏱ 2025-05-15 10:02:02 ^30638159-169-2144-2324
📌 Nginx是轻量级的高性能中间件，Nginx基于Epoll网络I/O模型，在高并发场景下对性能消耗很低。如果在服务器上仅部署Nginx做转发，2核4G/4核8G的配置足够了，无须8核16G的高配。
⏱ 2025-05-15 10:04:01 ^30638159-169-2353-2451
📌 Apache基于Select网络模型，偏向计算型中间件。所以在服务器配置中，起码用4核8GB，有一定业务量推荐用8核16GB
⏱ 2025-05-15 10:04:14 ^30638159-169-2536-2598
📌 数据库主要满足的是数据读写的需求，所以对磁盘I/O有一定要求，一般采用SSD云盘
⏱ 2025-05-16 09:54:12 ^30638159-169-4554-4594
📌 通过实践发现，100GB、300GB、500GB存储空间是企业对服务器磁盘配置的标配，但同时80%的企业服务器的磁盘利用率仅在20%～30%
⏱ 2025-05-16 09:54:28 ^30638159-169-4651-4721
📌 核心点在于未能将业务访问量有效转换成开发人员所熟悉的带宽性能数据
⏱ 2025-05-16 09:56:50 ^30638159-171-598-630
📌 如果需求只是入口流量，带宽一般采用SLB，带宽性能、架构扩展、安全性都比ECS直接绑定公网带宽要好
⏱ 2025-05-16 09:57:14 ^30638159-171-721-770
📌 如果需求是出口流量，需要主动去访问公网服务，需要配置公网带宽
⏱ 2025-05-16 09:57:26 ^30638159-171-843-873
📌 对于已上线的业务估算带宽配置，看平时带宽的峰值即可。如果业务还处于前期需求规划期间，对于带宽配置的评估，关键还是先把业务请求量 （这里用的更多的是PV量，如果是其他业务请求量，要先转换为对应的PV请求量） 先转换成每秒请求量，然后再把每秒请求量转换为带宽配置。
⏱ 2025-05-16 09:59:28 ^30638159-171-1057-1187
📌 带宽配置=每秒请求数量×每次请求传输的数据量
⏱ 2025-05-16 09:59:38 ^30638159-171-1250-1272
📌 = （80%×总PV量） / （24小时×60分×60秒×40%） ×X Mbps/s
⏱ 2025-05-16 09:59:48 ^30638159-171-1299-1342
📌 • 80%的应用默认选择按量带宽，即按量带宽是云端带宽类型选择的最佳实践
⏱ 2025-05-16 10:02:56 ^30638159-172-547-583
📌 • 20%的应用选择固定带宽。这个特定的条件就是，如若每天按量下载的量合计费用超过带宽平均每天费用，则使用固定带宽。
⏱ 2025-05-16 10:03:19 ^30638159-172-611-669
📌 选择SLB并且是1Gbps的带宽峰值，相比于ECS带宽的性能及稳定性更好，并且成本上可节省1100元/月，而且效率变高了
⏱ 2025-05-16 10:09:27 ^30638159-172-2155-2215
📌 2Mbps的按量带宽，也仅用于远程管理服务器，产生的流量费用几乎可以忽略不计，并且云上的5Gbps的免费防御DDoS攻击流量，基本上可以防御小规模的流量攻
⏱ 2025-05-16 10:08:55 ^30638159-172-2216-2293
6.1 云网络下的业务新架构
📌 BGP线路之所以能解决这个问题，就是因为其解决了路由选择的问题，即能决定走什么路由过来，不绕远路，这样一来，问题自然就解决
⏱ 2025-05-18 18:58:45 ^30638159-175-1280-1341
📌 这是因为云主机底层基于虚拟化，针对很多物理机虚拟出了很多的云主机 （类似VPS虚拟机，只不过和VPS虚拟机不同的是，云主机是基于分布式的，没有单点问题） ，主要解决了IDC时代下资源利用的问题。
⏱ 2025-05-18 22:19:27 ^30638159-177-571-668
📌 共享型实例系统采用的是随机的更贪婪的调度CPU的模式，一个核的使用可能会调度分配给不同的云主机实例。
⏱ 2025-05-18 22:30:13 ^30638159-177-1077-1127
📌 独享型实例用系统固定调度CPU模式，一个核的使用会固定调度给某云主机实例，不会因为其他用户的资源使用繁忙或空闲而产生波动
⏱ 2025-05-18 22:30:21 ^30638159-177-1200-1260
📌 对云主机的性能进行评测，以便对容量进行规划 （用多少台服务器） ，这才是有意义的
⏱ 2025-05-18 22:31:30 ^30638159-177-2346-2386
6.3 云时代下的资源自动化管理
📌 不仅是在Web控制台上操作方便，随着云API的推出，还能让我们通过代码接口管理云端资源。API的开放，意味着云时代下面的资源管理控制完全不需要人工干预，全部都可以交给程序完成
⏱ 2025-05-18 22:35:43 ^30638159-179-1146-1233
📌 不过对于此类功能在云端已经做成成熟的产品了，如ESS弹性伸缩，它能动态调整弹性计算资源，实现真正意义上的无须人工干预、资源动态伸缩。
⏱ 2025-05-18 22:36:22 ^30638159-179-1878-1944
第7章 云端负载均衡实践
📌 集群架构主要是热备的高可用架构，它通常采用虚拟VIP技术 （如Keeplived、Hearbeat） 来解决单点故障的问题，让架构高可用。集群的虚拟VIP技术只能让一台服务器平时作为Backup热备，只有在出现故障的时候才会切换到Backup上，平时Backup热备都处于空闲状态。分布式架构的技术特点就是引入了负载均衡，让不同服务器来同时处理业务压力。
⏱ 2025-05-18 22:38:30 ^30638159-180-440-617
7.2 单机+SLB架构的必要性
📌 单机与单机+SLB架构对比

⏱ 2025-05-19 07:17:22 ^30638159-182-533-729
7.4 DNS的两大主流实践
📌 凭借核心秘密的智能解析功能，在CDN、跨地域分布式架构中得到广泛且重要的应用。
⏱ 2025-05-19 07:38:49 ^30638159-184-543-582
📌 所以中小型架构并不适合以DNS作为负载均衡。DNS的负载均衡架构，主要适合大规模应用。当后端有一两百台ECS，而一台SLB的性能又有限时，此时采用多个SLB，DNS调用的优势和必要性就体现出来了
⏱ 2025-05-19 21:36:41 ^30638159-185-3121-3218
📌 DNS作为负载均衡还有一个问题没有解决，那就是本地DNS缓存的问题。不过随着云时代的普及以及技术的发展，这方面所带来的问题几乎可以忽略不计。
⏱ 2025-05-19 21:27:10 ^30638159-185-4759-4829
📌 阿里云CDN的DNS调度系统根据终端用户的源IP判断出该终端属于上海地域，并为该终端用户请求分配上海缓存节点IP，则LDNS获取DNS返回的解析IP地址2.2.2.2。
⏱ 2025-05-20 09:30:02 ^30638159-186-5825-5909
📌 如果是动态请求则直接转给后端源站进行处理，由此可见CDN只做静态缓存加速，对动态请求是没办法进行加速的。
⏱ 2025-05-20 09:29:41 ^30638159-186-6274-6326
📌 CDN所谓“就近访问”的核心在于DNS的智能解析能分辨不同终端用户源IP的地域，然后再返回该地域的CDN缓存节点IP地址，从而实现“就近访问”。 ^30638159-186-6435-6508
- 💭 CDN就近访问 - ⏱ 2025-05-21 09:48:01
📌 业务中分多个域名，比如海外用户访问abroad.a.com，解析IP绑定到海外机房部署的业务站点。国内用户访问home.a.com，然后解析IP绑定国内机房部署的业务站点。
⏱ 2025-05-21 21:47:45 ^30638159-186-7243-7329
📌 这种加上多个域名的方式，可能很多业务是不能接受的，大多数业务需求是只能用一个域名作为访问入口。比如国内知名扫地机器人在海外的官网，在日本、新加坡、美国、德国都部署节点，但暴露给用户的仅有一个域名地址。这时智能解析就很好地解决了该问题，它可以根据海外不同的地域，设置多个不同的A解析记
⏱ 2025-05-21 21:49:14 ^30638159-186-8354-8495
📌 [插图]
⏱ 2025-05-21 22:43:31 ^30638159-186-8786-8787
📌 通过智能解析把不同地域的请求引流至各自不同地域部署的节点中，然后将节点中部署的业务再采用Docker进行部署
⏱ 2025-05-21 22:42:53 ^30638159-186-8887-8941
📌 但是还有个问题没有解决，即数据库也可能需要进行跨地域部署。所以底层数据库跨地域进行同步时所带来的数据同步的延时问题，就成了跨地域分布式架构的第二大难题。不过，当前在云端可以通过高速通道进行专线打通。当前实际案例中，许多客户已经将海外部署节点和国内部署节点通过高速通道打通，从而保障网络传输速度及传输质量。然后结合DTS工具进行数据库底层的实时同步。
⏱ 2025-05-21 22:43:25 ^30638159-186-9007-9181
📌 DTS数据传输 (Data Transmission) 是阿里云提供的一种支持RDBMS （关系型数据库） 、NoSQL、OLAP等多种数据源之间数据交互的数据服务。它提供了数据迁移、实时数据订阅及数据实时同步等多种数据传输能力。通过数据传输可实现不停服数据迁移、数据异地灾备、跨境数据同步、缓存更新策略等多种业务应用场景，帮助用户构建安全、可扩展、高可用的数据架构。DTS将会成为云端数据同步、跨地域数据同步的最佳实践方案。
⏱ 2025-05-21 22:44:44 ^30638159-186-9423-9636
📌 七层的负载均衡，在中大型项目中并不适合作为业务请求的流量入口，特别是在电商高并发的场景下，七层SLB显得格外力不从心。
⏱ 2025-05-31 23:28:25 ^30638159-189-2362-2421
📌 我们并不会采用七层Nginx、七层Haproxy作为流量入口，也不会采用Nginx四层、Haproxy四层作为流量入口，主要是因为Nginx/Haproxy的“二次连接”对性能有损耗。
⏱ 2025-05-31 23:30:01 ^30638159-190-1314-1406
📌 采用LVS或者负载均衡作为互联网架构的流量入口，可以保障入口流量最大性能及效率被负载均衡转发，这是中大型项目的标准应用。
⏱ 2025-05-31 23:30:13 ^30638159-190-1406-1466
📌 流量处仅通过硬件或LVS负载均衡做流量分发。而七层虚拟主机、Rewrite等功能需求，就放在后端服务器上通过搭建Nginx/Apache来实现。
⏱ 2025-05-31 23:32:07 ^30638159-190-1630-1702
📌 [插图]
⏱ 2025-05-31 23:32:22 ^30638159-190-1884-1885
7.7 通过代理+VPN提速跨国际网络访问
📌 通过代理+VPN提速跨国际网络访问，在云端算是经典的应用实践。
⏱ 2025-06-02 17:58:40 ^30638159-193-557-588
📌 那能不能只通过一个域名结合反向代理，来解决跨国际网站访问延时的问题呢？答应是可以的，我们需要借助DNS智能解析的核心功能。
⏱ 2025-06-04 12:19:22 ^30638159-198-462-523
📌 技巧一：分布式部署
⏱ 2025-06-05 13:40:20 ^30638159-201-627-636
📌 技巧二：夜间活动减少资源共抢
⏱ 2025-06-05 13:40:28 ^30638159-201-1809-1823
📌 所以在进行架构设计的时候，可把需要I/O、需要CPU计划的任务放在晚间进行。
⏱ 2025-06-05 13:40:38 ^30638159-201-2268-2306
📌 技巧三：云盘的拆分及合并
⏱ 2025-06-05 13:40:30 ^30638159-201-2332-2344
📌 在两块物理硬盘上读写总比在一块物理硬盘上读写性能要好，尤其是将不同的应用部署在不同的磁盘空间上时效果更加明显
⏱ 2025-06-05 13:38:09 ^30638159-201-2496-2550
📌 技巧一：在云盘中不建议进行分区
⏱ 2025-06-05 13:40:05 ^30638159-202-451-466
📌 技巧二：在云盘中不建议使用LVM
⏱ 2025-06-05 13:40:48 ^30638159-202-677-693
📌 技巧三：云盘的系统盘不建议做数据存储
⏱ 2025-06-05 13:42:21 ^30638159-202-1081-1099
📌 不建议存储业务代码、业务日志、数据库数据等
⏱ 2025-06-05 13:43:13 ^30638159-202-1182-1203
📌 我们有时候需要进行系统调优、内核升级，或者装一个软件，若此时系统出现问题需要回滚系统盘，那么就会导致存放在系统盘中的业务数据、数据库数据一起回滚。
⏱ 2025-06-05 13:43:01 ^30638159-202-1261-1334
📌 技巧四：云盘最好不要依赖ECS
⏱ 2025-06-05 13:43:24 ^30638159-202-1360-1375
📌 在IP上通常不建议开通ECS的时候直接勾选绑定公网IP，这时候这个公网IP会跟ECS绑定也会随着ECS的释放而释放
⏱ 2025-06-05 13:44:31 ^30638159-202-1658-1715
📌 由于rc.local中的内容是顺序执行的，一些执行异常、文件权限、环境变量等问题，都可能导致rc.local中的命令没办法开机自启动，所以在磁盘挂载的开机自启动中，默认需要把挂载命令放在/etc/fstab中。
⏱ 2025-06-05 13:45:27 ^30638159-202-1968-2073
📌 DRBD的核心功能通过Linux的内核实现，最接近系统的I/O栈，但它不能添加上层的功能，比如检测到EXT3文件系统的崩溃
⏱ 2025-06-12 08:07:23 ^30638159-206-1508-1569
📌 相比于OSSFS，建议优先使用2019年新推出的阿里云云存储网关产品
⏱ 2025-06-23 08:54:28 ^30638159-213-1505-1539
📌 闪电立方离线迁移是阿里云提供的安全、高效、便捷的数据迁移服务，致力于保障大规模数据高传输效率、安全等。
⏱ 2025-06-23 09:30:48 ^30638159-220-1561-1612
📌 我们可以用last-modified参数来实现，last-modified是根据文件更新时间来确定是否再次发送加载的。
⏱ 2025-06-26 08:38:03 ^30638159-224-2123-2182
📌 首先，Session存放的用户状态数据是有大小的，这里假设每个Session存放的大小为1KB。其次，Tomcat使用的内存大小也有限制，这主要取决于Tomcat设置的可使用最大JVM内存，假设设置的大小为1024MB （等于1024×1024=1048576KB） 。则Tomcat中存放的Session的个数极限值是：1048576KB/1KB，即一百万个，这也从侧面说明能支持一百万用户同时在线。不过这是极值，我们未考虑代码处理中，还有其他业务计算的地方需要大量占用内存。
⏱ 2025-07-28 20:07:50 ^30638159-230-1410-1649
📌 策略一：基于源IP的会话保持
基于源IP的会话保持，是指负载均衡识别客户端请求的源IP地址，将同一IP地址的请求转发到同一台后端服务器进行处理
⏱ 2025-08-01 07:39:13 ^30638159-230-1981-2080
📌 策略二：基于浏览器Cookie的会话保持
⏱ 2025-08-04 16:58:01 ^30638159-230-3324-3344
📌 第一招：通过Nginx内置Proxy模块实现动态页面缓存
⏱ 2025-08-05 20:42:25 ^30638159-231-1235-1447
📌 内置Proxy模板proxy_cache实现动静态缓存，缓存文件是存放在磁盘文件中的。在高并发访问的场景中，磁盘I/O可能是性能的瓶颈点。
⏱ 2025-08-05 20:42:49 ^30638159-231-1803-1872
📌 第二招：PHP的动态页面缓存：fastcgi_cache
⏱ 2025-08-05 20:44:30 ^30638159-231-6684-6712
📌 第三招：通过Nginx内置Memcache模块实现动态页面缓存
⏱ 2025-08-05 20:44:52 ^30638159-231-8147-8178
📌 第四招：通过Nginx第三方模块实现动态页面缓存
⏱ 2025-08-05 20:46:03 ^30638159-231-10393-10417
📌 方案一：经典主从架构的实践
⏱ 2025-08-28 10:37:04 ^30638159-235-561-574
📌 方案二：主从架构的三种扩展应用
(1) 一主多从架构应用
⏱ 2025-08-28 11:03:36 ^30638159-235-1901-2012
📌 (2) 主主架构应用
⏱ 2025-08-28 11:03:42 ^30638159-235-2820-2830
📌 自定义自增偏移
⏱ 2025-08-28 10:54:13 ^30638159-235-3633-3640
📌 个同时写问题很多，三个同时写则会有主从同步等更多问题，很不靠谱
⏱ 2025-08-28 10:55:09 ^30638159-235-3778-3809
📌 而相比传统主从架构，MongoDB副本集 （如图10-7所示） ，集群中的任何节点都可能成为Master节点。一旦Master节点发生故障，副本集可以自动投票，则会在其余节点中选举出一个新的Master节点。并引导剩余节点连接到新的Master节点，这个过程对于应用是透明的。目前MongoDB官方已不推荐使用主从模式，取而代之的是副本集模式
⏱ 2025-08-28 10:56:54 ^30638159-235-4133-4304
📌 业务代码连接数据源的配置放在Zoo-keeper （或Consul/Etcd） 中来管理，通过简单心跳代码，自动Check主从的节点是否可用。如果对应的节点异常，更新Zookeeper （或Consul/Etcd） 中的数据源地址，这样业务代码获取的连接地址便会是最新无异常的地址。 ^30638159-235-8269-8410
- 💭 配置中心
- ⏱ 2025-08-28 11:12:24
📌 最为常见的数据库集群技术，当属于Oracle RAC和MySQL Cluster了
⏱ 2025-08-28 11:41:27 ^30638159-236-416-457
读书笔记
3.5 “世界上最好”的语言
划线评论
📌 Tomcat是一个轻量级中间件，一般单台Tomcat的极限并发能力在1000左右。所以单台Tomcat适合部署在中低配的服务器配置中，比如4核8GB是部署单台Tomcat的完美服务器配置；而在8核16GB等中高配的服务器配置中，运行单台Tomcat往往会造成服务器的性能浪费；对于中高配的服务器，要想把服务器性能都利用起来，不让服务器的配置浪费，一般要在中高配服务器中跑多个Tomcat。 ^37992928-7ZsyW4a1R
- 💭 tomcat 极限1000并发，4核8g，刚刚好。8核16g，性能过剩，可以部署其他服务来压榨内存和CPU。
- ⏱ 2025-04-17 00:40:43
4.1.1 策略一：网络类型选型的五个注意点
划线评论
📌 经典网络采用三层 （网络层，即IP层） 隔离，所有的经典网络类型实例都建立在一个共用的基础网络上。VPC采用二层隔离 （数据链路层） ，相对经典网络而言，VPC具有更高的安全性和灵活性。 ^37992928-7Zt2Sr8Cq
- 💭 一、数据链路层隔离的核心技术
基于隧道的二层扩展
通过VPN 隧道技术（如 IPSec、GRE）在公有网络中创建逻辑隔离的私有网络通道，确保不同 VPC 的流量在隧道内传输，避免直接暴露于公网。
隧道两端通过虚拟隧道接口（VTI）关联，实现跨地域或跨网络的二层通信。
分布式交换机与 MAC 地址管理
VPC 内的交换机采用分布式架构，支持MAC 地址学习和帧转发，仅允许同一 VPC 内的节点通过 MAC 地址直接通信。
通过硬件交换机实现高速帧传输，结合控制器动态下发转发表，确保流量路径灵活可控。
二、SDN 控制器的核心作用
策略驱动的网络配置
控制器（如阿里云的 VPC 控制器）通过OpenFlow或NetConf协议与交换机、网关交互，动态下发路由表、安全组规则等配置。
支持用户自定义IP 段划分、子网掩码和路由策略，实现灵活的网络拓扑调整。
多链路冗余与容灾
控制器集群多机房互备，通过BGP 协议实现跨区域路由同步，确保链路故障时自动切换至备份路径。
三、硬件与软件的协同架构
自研交换机与网关
阿里云基于硬件网关和自研交换机构建 VPC 数据通路，支持硬件级流量调度和低延迟传输。
网关负责公网流量与私有网络之间的转换，通过NAT技术实现安全隔离。
分离的配置与数据通路
配置通路：控制器通过 API 或管理界面接收用户策略，生成配置指令下发至设备。
数据通路：交换机和网关直接处理帧转发，与控制逻辑解耦，提升传输效率。
- ⏱ 2025-04-17 08:17:54
4.1.2 策略二：入网请求选型的四种方法
划线评论
📌 在云端对ECS实现入网请求的功能，可以通过以下4种方法实现。 ^37992928-7Zut5KUxq
- 💭 云端访问ecs，可以通过以下方式：slb，公网ip，弹性eip，dnat
- ⏱ 2025-04-18 06:44:50
划线评论
📌 在很多场景中，给服务器开公网带宽只是为了让服务器能够远程SSH连接而已。我见到过这样的场景，一个客户有二三十台服务器，为每台服务器开个公网IP，目的就是方便远程，但这样使用的合理性、安全规范性有很大隐患。 ^37992928-7ZusasYc4
- 💭 我也想这么干
- ⏱ 2025-04-18 06:30:44
划线评论
📌 远程登录流程架构图 ^37992928-7ZusuxL5T
- 💭 这样就不需要每台ecs服务器绑定公网
- ⏱ 2025-04-18 06:35:40
划线评论
📌 给ECS绑定公网存在很大安全隐患，这等同于给黑客开了一道能触达ECS的门，方便通过端口扫描、漏洞嗅探实现入侵。 ^37992928-7ZusqBX4h
- 💭 有安全隐患
- ⏱ 2025-04-18 06:34:42
划线评论
📌 比如让ECS绑定公网，外网就不能直接访问） 。 ^37992928-7Zusm1XT7
- 💭 都绑定公网了，还不让外网访问？
- ⏱ 2025-04-18 06:33:34
4.1.3 策略三：出网请求选型的三种方法
划线评论
📌 ECS实现出网请求的功能，可以通过以下3种方法实现。 ^37992928-7ZutgTTAr
- 💭 出网请求方式：公网ip，弹性eip，snat
- ⏱ 2025-04-18 06:47:35
划线评论
📌 阿里云流量带宽峰值、流量带宽费用针对的是出口流量峰值及出口流量带宽费用。 ^37992928-7Zxx5s5ki
- 💭 出口流量
- ⏱ 2025-04-20 07:05:51
4.2.3 考虑三：对负载均衡功能的支持
划线评论
📌 上述架构中，3台MySQL主主同步架构也不建议运用在生产环境中，因为主主同步架构在高并发场景下，在不同主机上同时对某条数据进行写操作，很可能导致数据不一致性的问题。 ^37992928-7ZAzhIiNS
- 💭 mysql主主同步架构很多坑
- ⏱ 2025-04-22 06:59:25
4.2.5 考虑五：丰富的插件及支持灵活的二次开发
划线评论
📌 而Nginx源代码采用C语言开发，这将使我们的二次开发变得非常复杂。为了方便开发人员，OpenResty整合了Nginx和Lua的框架，它帮我们实现用Lua的规范开发实现各种业务，并且厘清各个模块的编译顺序。 ^37992928-7ZDzRR6TO
- 💭 OpenResty 整合了nginx和lua
- ⏱ 2025-04-24 06:28:20
4.3 云端负载均衡选型的五个方面
划线评论
📌 负载均衡既是分布式架构的基础也是其核心，负载均衡的使用可以实现会话同步，消除服务器单独故障；也可以进行请求流量分流，提升冗余，保证服务器的稳定性。 ^37992928-7ZIWgFVEC
- 💭 把1分成10
- ⏱ 2025-04-27 19:03:43
4.3.1 对比方面：四大热门负载均衡的优缺点
划线评论
📌 在开源的软件负载均衡中，应用最为广泛的为LVS、Nginx、HAProxy，甚至阿里云的SLB也是基于LVS及Nginx的 ^37992928-7ZDC6rzd0
- 💭 四大热门负载均衡
- ⏱ 2025-04-24 07:02:28
划线评论
📌 特点是占用内存少、并发能力强，加上丰富的插件功能模块，当前是云端Web类应用中首选的一款软件。以下是它的具体特性。 ^37992928-7ZDCUKfGN
- 💭 nginx 特点
- ⏱ 2025-04-24 07:14:51
4.3.2 分类方面：五大类型负载均衡的原理场景详解
章节评论 No.1
- 之前做mysql双主和主从的时候，用过keepalived ，所以对这本章内容有一些亲切感。 ^37992928-7ZWGLAJtD
- ⏱ 2025-05-06 20:00:25
4.3.3 演变方面：负载均衡的两种演变
章节评论 No.1
- 可以这样理解吗？
正向代理：内网的客户端通过代理访问公网服务器
反向代理：客户端通过公网ip访问内网服务器 ^37992928-7ZWIeiP1G- ⏱ 2025-05-06 20:22:45
5.2.3 业务指标转换计算模型实践
划线评论
📌 计算模型参考：
用户数×业务因子 (10%～30%) =活跃用户数
活跃用户数×业务因子 (10%～30%) =在线用户数
在线用户数×业务因子 (10%～30%) =并发用户数≈每秒请求数 ^37992928-803xLrWUh
- 💭 计算因子就是访问模式，反应了真正发给后端的请求量
- ⏱ 2025-05-11 08:09:39
5.3.1 PV量对应的服务器配置
划线评论
📌 一台8核16GB的服务器基本上能处理Web类应用上百的请求，所以可以对应100万PV。 ^37992928-803IU3wbz
- 💭 这两句话是怎么计算出来的？
- ⏱ 2025-05-11 10:59:44
7.4.2 实践二：DNS不为人知的核心秘密功能
划线评论
📌 CDN所谓“就近访问”的核心在于DNS的智能解析能分辨不同终端用户源IP的地域，然后再返回该地域的CDN缓存节点IP地址，从而实现“就近访问”。 ^37992928-80iRjQsL8
- 💭 CDN就近访问
- ⏱ 2025-05-21 09:48:17
10.1.2 场景二：主从的四种实践方案
划线评论
📌 业务代码连接数据源的配置放在Zoo-keeper （或Consul/Etcd） 中来管理，通过简单心跳代码，自动Check主从的节点是否可用。如果对应的节点异常，更新Zookeeper （或Consul/Etcd） 中的数据源地址，这样业务代码获取的连接地址便会是最新无异常的地址。 ^37992928-82Jxtn08t
- 💭 配置中心
- ⏱ 2025-08-28 11:12:31