大型互联网项目架构设计实践及架构优化思路

本文链接：https://blog.csdn.net/yangwei234/article/details/113198522

架构师认知

架构师成长之路

在这里插入图片描述

架构是什么？

对业务场景抽象后得出的支持骨架（网络拓扑结构）
- 老板：100w 日活量，10W QPS 微服务架构
架构为业务场景而生、被业务场景而弃
- 老板：10天上线 – 单体架构
架构没有最好、只有“最合适”（人员技术研发能力、业务复杂度、数据规模大小、时间成本、运维能力….）
“最合适”架构都是业务场景折中（Balance）的选择

在这里插入图片描述

总结：选择架构时候，必须选择最适合公司当下环境的架构。

架构目标是什么？

在这里插入图片描述
用户网站访问调查：reponse time : 3s ---- 60% 用户流失

RT时间：ms 高性能（前端：美观大气的上档次页面—非常简单，后端：一系列的优化ms）
高可用：任何时候项目都必须可用
可升缩：大促，流量瞬间增大….
可扩展：开发角度（新需求进行迭代），扩展
安全性：网络安全，硬件安全，软件安全
敏捷开发：可持续交付，可持续部署

架构师目标：采用什么样方式，才能构建以上目标的项目？？

架构模式？-- 架构策略

在这里插入图片描述

分层：分层拆分（表现层，业务层，持久层）
分割：连接池分割，机房，进程（分布式）
分布式：分布式架构
集群：高可用
缓存：堆内存缓存，redis缓存，lua缓存
异步：写异步
冗余：数据库设计，读，写
安全：数据安全（加密）、系统安全
自动：运维，扩容，缩容
敏捷：可持续集成，交付，部署

高性能架构

以用户为中心，提供快速的网页访问体验。主要参数有较短的响应时间、较大的并发处理能力、较高的吞吐量与稳定的性能参数。
可分为前端优化、应用层优化、代码层优化与存储层优化。
- 前端优化：网站业务逻辑之前的部分；— vue ,react +nodejs – 工程化
- 浏览器优化：减少HTTP请求数，使用浏览器缓存，启用压缩，CSS JS位置，JS异步，减少Cookie传输；CDN加速，反向代理；
- 应用层优化：处理网站业务的服务器。使用缓存，异步，集群，架构优化
- 代码优化：合理的架构，多线程，资源复用（对象池，线程池等），良好的数据结构，JVM调优，单例，Cache等；
- 存储优化：缓存、固态硬盘、光纤传输、优化读写、磁盘冗余、分布式存储（HDFS）、NoSQL等
总结：
- 服务尽量进行拆分（微服务）---- 提高项目吞吐能力
- 尽量将请求拦截在上游服务（多级缓存）— 90% ----> 数据库压力非常小，闲庭信步，数据库架构（主从架构）
- 代理层（做限速，限流）
- 服务层：按照业务请求做队列的流量控制（流量削峰）

高可用架构

大型互联网高可用&高并发业务架构设计
大型网站应该在任何时候都可以正常访问，正常提供对外服务。
因为大型网站的复杂性，分布式，廉价服务器，开源数据库，操作系统等特点，要保证高可用是很困难的，也就是说网站的故障是不可避免的。
以上问题和我们架构师保证服务高可用性是相互矛盾的，因此架构师要做的事情就是解决以上问题，保证服务高可用性。
服务问题：
- 业务问题：业务高可用性，防止有bug、有异常，对输入有提示，数据有检查，防止数据异常。
- 系统的问题：系统高可用性，系统健壮性强，应该能处理系统运行过程中出现的各种异常情况，如：人为操作错误、输入非法数据、硬件设备失败等，系统应该能正确的处理，恰当的回避。
因软件系统的失效而造成不能完成业务的概率要小于5‰，要求系统7x24小时运行，全年持续运行故障停运时间累计不能超过10小时。系统缺陷率每1,000小时最多发生1次故障。在1,000,000次交易中，最多出现1次需要重新启动系统的情况。

在这里插入图片描述

如何提高可用性，就是需要迫切解决的问题。首先，需要从架构级别考虑，在规划的时候，就考虑可用性。不同层级使用的策略不同，一般采用冗余备份和失效转移解决高可用问题。
- 应用层：一般设计为无状态的，对于每次请求，使用哪一台服务器处理是没有影响的。一般使用负载均衡技术（需要解决Session同步问题）实现高可用。
- 服务层：负载均衡，分级管理，快速失败（超时设置），异步调用，服务降级，幂等设计等。
- 数据层：冗余备份（冷，热备[同步，异步]，温备），失效转移（确认，转移，恢复）。数据高可用方面著名的理论基础是CAP理论（持久性，可用性，数据一致性[强一致，用户一致，最终一致]）
总结起来就是：
1、负载均衡（故障转移）
2、限流
3、降级
4、隔离（线程隔离，进程隔离，集群隔离，机房隔离，读写分离，动静分离，热点隔离…）
5、超时、重试
6、压测与预案，例如：大促-演练

可伸缩架构

伸缩性是指在不改变原有架构设计的基础上，通过添加/减少硬件（服务器）的方式，提高/降低系统的处理能力。
- 应用层：对应用进行垂直或水平切分，然后针对单一功能进行负载均衡（DNS、HTTP[反向代理]、IP、链路层）。
- 服务层：与应用层类似。
- 数据层：分库、分表、NoSQL等，常用算法Hash，一致性Hash。
云原生：项目运行云端，可以随时动态扩容—K8S
8核心+16G : 2000QPS ± (此数字是估算结果，真实结果受到代码编写数据结构，业务逻辑，架构、rt，以现实测试结果)

可扩展架构

SOA、微服务 — 根据业务拆分模块 ----- 新业务需求 ---- 根据新的业务需求创建一个新模块服务。
可以方便地进行功能模块的新增/移除，提供代码/模块级别良好的可扩展性。
- 模块化，组件化：高内聚，低耦合，提高复用性，扩展性。
- 稳定接口：定义稳定的接口，在接口不变的情况下，内部结构可以“随意”变化。
- 设计模式：应用面向对象思想，原则，使用设计模式，进行代码层面的设计。
- 消息队列：模块化的系统，通过消息队列进行交互，使模块之间的依赖解耦。
- 分布式服务：公用模块服务化，提供其他系统使用，提高可重用性，扩展性。

安全架构

对已知问题有有效的解决方案，对未知/潜在问题建立发现和防御机制。对于安全问题，首先要提高安全意识，建立一个安全的有效机制，从政策层面，组织层面进行保障，比如服务器密码不能泄露，密码每月更新，每周安全扫描等。以制度化的方式，加强安全体系的建设。同时，需要注意与安全有关的各个环节。安全问题不容忽视，包括基础设施安全，应用系统安全，数据保密安全等。
基础设施安全：硬件采购，操作系统，网络环境方面的安全。一般采用正规渠道购买高质量的产品，选择安全的操作系统，及时修补漏洞，安装杀毒软件防火墙。防范病毒，后门。设置防火墙策略，建立DDOS防御系统，使用攻击检测系统，进行子网隔离等手段。
应用系统安全：在程序开发时，对已知常用问题，使用正确的方式，在代码层面解决掉。防止跨站脚本攻击（XSS），注入攻击，跨站请求伪造（CSRF），错误信息，HTML注释，文件上传，路径遍历等。还可以使用Web应用防火墙（比如：ModSecurity），进行安全漏洞扫描等措施，加强应用级别的安全。
数据保密安全：存储安全（存储在可靠的设备，实时，定时备份），保存安全（重要的信息加密保存，选择合适的人员复杂保存和检测等），传输安全（防止数据窃取和数据篡改）；常用的加解密算法（单项散列加密[MD5、SHA]，对称加密[DES、3DES、RC]），非对称加密[RSA]等。

互联网架构演进思考

架构演进

在这里插入图片描述

企业架构转型：数字化转型
传统架构过渡到云原生架构（容器云）

单体架构

什么是单体架构

所有业务都在同一个应用中，没有进行任何拆分。

在这里插入图片描述

注意：集中式架构模式，所有的请求都集中在同一个服务上面，对服务压力较大，因此这样的架构适合并发较小的架构。同时同一个服务器中，数据库、项目都会抢占服务内存、cpu资源，造成服务性能问题。

单体架构优化

应用程序、MYSQL分离部署
服务集群 – 提升性能
动态分离（静态资源存储CDN,nginx服务器）
隔离术（线程池隔离，进程隔离）
队列术（blockingQueue、disruptor队列，RocketMQ）
接入层限流（openresty）, 接口限流
MySQL优化（索引、缓存、表结构、分表分库、数据归档、冷热、SQL语句优化）
引入LVS （linux virtual server）
DNS 解决上层流量瓶颈问题
多级缓存

单体架构流量预估

单体架构真的不能承受亿级流量？？

单体架构：中小型企业，创业公司
- 1、传统项目（并发量小、业务简单、需求固定），项目体量比较小。
- 2、小程序
- 3、追求极致性能的项目（业务量少）
- 4、互联网项目（中小型企业，创业公司）

需求：某网站平均一天下单量100w单，根据100w 评估一下系统的流量！！

用户行为：
- 1、产生的时间段：11:00 – 14:00 17:00 – 24:00 ，订单产生时间段：12h
- 2、每下一单会发生多少个请求：50 QPS x 3 = 150 QPS
计算流量：

100w / day * 150 QPS = 1.5 亿 ----- 亿级流量
* 计算平均每一秒QPS:
	1.5亿/12 h = 1250 QPS / 60min = 20W / 60s = 3400 QPS

单点架构优缺点

单体架构优点：
- 部署简单
- 开发简单
- 测试简单
- 集群简单
- RT响应时间非常快速 — 适合一些特点的项目（极端苛刻响应时间）
单体架构缺点：
- 流量比较集中，所有的请求都集中一个服务中，单体无法应对。
- 无法实现敏捷开发，业务增大，代码结构越来越臃肿，维护变得非常困难。
  - 单体架构： war > 1G — IBM unix 高性能服务器 64cpus, 128GB — 1GB
- 单体架构牵一发而动全身
- 扩展性差
- 稳定性差

架构拆分

随着业务流量增大，需求的增多，必须对架构进行改进，就需要对项目进行业务拆分（水平拆分，垂直拆分）
数据库水平拆分，垂直拆分模式：

在这里插入图片描述

水平拆分模式、垂直拆分：SOA架构

在这里插入图片描述

微服务架构

在这里插入图片描述

注意：微服务架构就是水平拆分和垂直拆分的架构结合，就是微服务架构。

ServiceMesh架构

ServiceMesh服务网格架构，CNCF 把 ServiceMesh 定义为云原生架构，ServiceMesh 落地级实现的成熟框架：Istio框架

问题：为什么要是有ServiceMesh架构？？Spring Cloud alibaba微服务架构存在问题？？

ServiceMesh出现就是为了解决微服务架构中存在一些问题？？
- 1、服务性能监控(Zabbix,promutheus)
- 2、服务限流(sentinel)
- 3、服务降级(sentinel)
- 4、服务熔断(sentinel)
- 5、链路追踪(skywalking)
- 6、日志监控(elk)
- 7、服务告警
- 8、负载均衡
- …………………….
以上一系列的问题，作为架构师，开发人员都需要全盘的考虑；开发微服务架构在服务治理，服务监控非常困难。
以上的工作和业务没有太多的关系，但是架构人员必须考虑架构、设计，因此这些配套工作都会大大降低我们的开发效率、提升开发难度、增加开发成本。

在这里插入图片描述