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

架构师认知

架构师成长之路

架构是什么？

• 对业务场景抽象后得出的支持骨架（网络拓扑结构）
  • 老板：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、负载均衡
  • …………………….
• 以上一系列的问题，作为架构师，开发人员都需要全盘的考虑；开发微服务架构在服务治理，服务监控非常困难。
• 以上的工作和业务没有太多的关系，但是架构人员必须考虑架构、设计，因此这些配套工作都会大大降低我们的开发效率、提升开发难度、增加开发成本。

Serverless

• Serverless 架构体系： 无服务架构，面向未来的架构体系，从开发人员来说，不需要关心底层哪些和业务没有关系的代码，只需要开发业务即可；
• 例如： 向CDN上传图片，视频文件。
  • 不需要上传到哪一个服务器
  • 不需要关心服务器是如何扩容的
• 这样的概念，思想就叫做Serverless。

总结

• 架构选型的时候，必须选择企业合适的架构，而不是采用最新架构。