两大定律

墨菲定律

任何事没有表面看起来那么简单 – 所有的事都会比预计的时间长 – 可能出错的事情总会出错 – 担心某种事情发生，那么它就更有可能发生

康威定律

系统架构师公司组织架构的反映

按照业务闭环进行系统拆分/组织架构划分，实现闭环、高内聚、低耦合，减少沟通成本，如果沟通出现问题，应该考虑进行系统和组织架构的调整 – 适合时机进行系统拆分，不要一开始就把系统、服务拆分拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高 –

微服务架构的理论基础 – 康威定律

二八定律

80%的结果取决于20%的原因

系统设计遵循的原则

1.高并发原则

无状态

• 便于水平扩展的无状态应用

• 如果是有状态，需要配置可通过配置中心实现无状态

• 实践: Yaconf、Zookpeer、Consul、Diamond、Xdiamond。。。

拆分

• 系统维度：按照系统功能、业务拆分等

• 功能维度：需要对系统功能层面上做细粒度拆分

• 读写维度：根据读写比例特征拆分（读多则可以考虑多级缓存，写多则可以考虑分库表）

• AOP维度：根据访问特征，按照AOP进行拆分

• 模块维度：对整体代码结构划分Web、Service、DAO

服务化

• 服务化演进: 进程内服务>单机远程服务>集群手动注册服务-自动注册和发现服务>服务的分组、隔离、路由>服务治理

• 应考虑服务的分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等

• 实践：利用Nginx、HaProxy、LVS等实现负载均衡，ZooKeeper、Consul等实现自动注册和发现服

消息队列

• 目的: 服务解耦(一对多消费)、异步处理、流量削峰缓冲等

• 大流量缓冲：牺牲强一致性，保证最终一致性(案例：库存扣减，现在Redis中做扣减，记录扣减日志，通过后台进程将扣减日志应用到DB)

• 数据校对: 解决异步消息机制下消息丢失问题

数据异构

• 数据异构: 通过消息队列机制接收数据变更，原子化存储

• 数据闭环: 屏蔽多从数据来源，将数据异构存储，形成闭环

缓存银弹

• 用户层:

• 浏览器DNS缓存：浏览器会缓存之前解析过的域名和对应的IP地址，以减少DNS解析的时间和网络请求的数量。

• 操作系统DNS缓存：操作系统也会维护一个DNS缓存，用于存储最近解析的域名和IP地址的映射关系，以提高系统整体的DNS解析性能。

• 本地DNS服务商缓存：本地ISP（互联网服务提供商）或其他DNS服务提供商可能会在其服务器上缓存DNS记录，以降低对上游DNS服务器的请求频率，并提高整体性能。

• DNS服务器缓存：DNS服务器本身也会对解析的域名和IP地址进行缓存，以降低对上游DNS服务器的请求频率，并提高整体的解析性能。

• 客户端缓存：一些网络应用或客户端可能会缓存DNS查询结果，以减少对DNS服务器的请求，提高访问速度。

• 浏览器缓存：浏览器还会缓存网页的静态资源，如图片、CSS文件、JavaScript文件等，以减少对服务器的请求，加快页面加载速度。缓存控制相关的头部包括：Expires、Cache-Control、Last-Modified、Etag等。

• App客户端缓存：手机应用程序或其他类型的应用程序也可能会缓存一些静态资源，如JavaScript、CSS、图像等，以提高应用的性能和响应速度。

• 代理层：

  CDN（内容分发网络）是一种通过在全球各地部署服务器节点来加速内容传输的技术。这些节点位于边缘、二级、中心等不同层次，构建了一个分布式的网络架构。CDN通常使用一些流行的软件或服务来构建，包括ATS（Apache Traffic Server）、Varnish、Nginx和Squid等。

• 接入层：

• Proxy_cache（代理缓存）：

• Nginx的代理缓存模块允许将响应缓存到内存、磁盘或其他存储介质中，以提高对后端服务的响应速度和减轻服务器负载。

• 可以配置Nginx将代理请求的响应缓存起来，以便后续请求直接从缓存中获取数据，而无需再次访问后端服务器。

• 缓存可以存储在内存中（例如/dev/shm）或SSD等快速存储介质上，以确保快速访问。

• FastCGI Cache（FastCGI 缓存）：

• Nginx的FastCGI缓存模块允许缓存FastCGI服务器的响应，通常用于缓存动态生成的内容，比如PHP页面。

• 可以根据请求的URI、参数和其他变量来配置缓存策略，以便提高性能并降低服务器负载。

• Nginx + Lua + Redis（Nginx与Lua、Redis结合）：

• 结合Lua和Redis，可以在Nginx中实现更灵活和高效的业务数据缓存。

• Lua脚本可以与Redis交互，将数据缓存到内存中的Redis数据库中，或从Redis中获取数据以提供快速响应。

• 这种方式可以用于缓存静态内容、API响应、会话数据等，以减少对后端服务器的访问并提高系统性能。

• PHP中的缓存技术：

• Opcache（Opcode缓存）

• PHP的Opcache模块允许缓存PHP脚本编译后的Opcode，以避免每次执行脚本时都需要重新编译。

• 通过缓存Opcode，可以显著提高PHP应用程序的性能和响应速度，特别是对于频繁执行的脚本。

• 应用层：

• 页面静态化：将动态生成的页面内容转换为静态HTML文件，以减少服务器负载并加快页面加载速度。静态化可以通过预渲染技术或缓存技术实现，使得用户访问页面时可以直接获取预先生成好的静态文件，而无需每次都执行动态生成的过程。

• 业务数据缓存：通过使用Redis、Memcached、本地文件等技术，将业务中频繁访问的数据进行缓存，以提高数据访问速度和系统性能。这些缓存可以存储数据库查询结果、计算结果、会话数据等，从而减少对后端存储系统的访问压力，加快数据访问速度。

• 消息队列：消息队列是一种用于解耦和异步处理的通信机制，用于在不同的应用程序或服务之间传递消息。发送者将消息发送到队列中，而接收者则可以从队列中获取消息并进行处理。消息队列可以用于实现任务队列、事件驱动架构、分布式系统等，提高系统的可扩展性、可靠性和性能。

• 数据层：

• NoSQL：Redis、Memcache、SSDB等

• MySQL：Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等

• 系统层：

• CPU : L1/L2/L3 Cache/NUMA

• 内存

• 磁盘：磁盘本身缓存、dirtyratio/dirtybackground_ratio、阵列卡本身缓存

并发化

2.高可用原则

降级

• 降级开关集中化管理：通过集中管理降级开关的配置信息，并将其推送到各个应用程序中，可以实现对系统降级策略的统一管理和动态调整。这样可以根据系统负载、异常情况或业务需求快速启用或禁用降级策略。

• 可降级的多级读服务：对于读服务，可以实现降级策略，将服务调用降级为只读本地缓存。这样即使后端服务不可用或响应缓慢，仍然可以通过本地缓存提供部分功能，保证系统的可用性和性能。

• 开关前置化：通过在Nginx中使用Lua脚本（如OpenResty），可以配置降级策略，并在请求到达后端服务之前对请求进行处理。这样可以在高负载或异常情况下及时引流流量，并根据情况调整响应策略，实现灵活的降级和灰度控制。

• 业务降级：在高并发情况下，为了保证核心功能的稳定运行，可以对次要功能进行降级处理。例如，将某些功能从同步改为异步处理，或者暂时屏蔽某些功能以减少系统负载。这样可以确保系统在异常情况下仍能保持核心功能的可用性。

限流

• 目的: 防止恶意请求攻击或超出系统峰值

• 实践：

• 恶意请求流量只访问到Cache：通过将恶意请求流量限制在访问缓存层，可以降低对后端应用的负载和风险。这样即使恶意请求穿透缓存层，也不会直接对后端应用产生影响，提高了系统的安全性和稳定性。

• 穿透后端应用的流量使用Nginx的limit处理：Nginx的limit模块可以限制来自客户端的请求流量，包括连接速率、请求数量等。通过合理配置limit规则，可以有效防止大量恶意请求对后端应用造成过载或拒绝服务攻击。

• 恶意IP使用Nginx Deny策略或者iptables拒绝：通过Nginx的Deny策略或者使用iptables等工具，可以将恶意IP列入黑名单并拒绝其访问。这样可以有效阻止恶意IP对系统的攻击，提高系统的安全性。

切流量

• 目的：屏蔽故障机器

• 实践:

• DNS: 更改域名解析入口，如DNSPOD可以添加备用IP，正常IP故障时，会自主切换到备用地址;生效实践较慢

• HttpDNS: 为了绕过运营商LocalDNS实现的精准流量调度

• LVS/HaProxy/Nginx: 摘除故障节点

可回滚

• 发布版本失败时可随时快速回退到上一个稳定版本

3.业务设计原则

• 防重设计

• 幂等设计

• 流程定义

• 状态与状态机

• 后台系统操作可反馈

• 后台系统审批化

• 文档注释

• 备份

4.总结

先行规划和设计时有必要的，要对现有问题有方案

添加博主

微信号｜yfq940-