目录
目标
一.前期演进
1. 单机架构
2. 应用数据分离架构
3. 应用集群架构
4. 读写分离/主从分离架构
5. 冷热分离架构
二. 架构
分布式数据库架构
微服务架构
容器编排架构
三. An Internet Application Architecture
理解
上层传输
框架
数据处理
主要思想
本专栏将根据如上思路 来学习 docker
下面让我们来开启第一部分的学习叭~
目标
- 理解每种技术架构以及如何演进的，结合电商平台为例
- 熟悉Docker在架构中的核心作用。
一.前期演进
1. 单机架构
简介
- 应用服务和数据库服务共用一台服务器
出现原因
- 出现在互联网早期，访问量比较小，单机足以满足需求。
- 以电子商城为例，可以看到通过应用（划分了多个模块）和数据库在单个服务器上协作完成业务运行。
抽象
批注：
- DNS（Domain Name System，域名系统）是互联网的一项服务，它作为将域名和IP地址相互映射的一个分布式数据库
- 能够使人更方便地访问互联网，而不需要记住能够被机器直接读取的IP数串。
- 通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）
Tomcat 是一个非常适合初学者和小型项目的Java Web应用服务器
优点
- 部署简单
- 成本低
缺点
- 存在严重的性能瓶颈
- 数据库和应用互相竞争资源
2. 应用数据分离架构
简介
- 应用服务和数据库服务使用不同服务器。
出现原因
- 单机存在严重的资源竞争，导致站点变慢。
- 以电子商城为例，可以看到应用和数据库在各自的服务器上通过网络协作完成业务运行。
优点
- 性能相比单机有提升
- 数据库单独隔离，不会因为应用把数据库搞坏，有一定的容灾能力
缺点
- 硬件成本变高，显而易见的多了一台服务器~
- 性能有瓶颈，无法应对海量并发
3. 应用集群架构
简介
- 引入了负载均衡，应用以集群方式运作。
出现原因
- 单个应用不足以支持海量的并发请求，高并发的时候站点响应变慢。
- 以电子商城为例，可以看到应用不再是一个，而是变成了多个，通过负载均衡来支持海量的并发。
说明：
- LVS/F5 主要负责负载均衡，在多个服务器之间分配流量，确保系统的高可用性和性能。
- Nginx 既可以作为一个独立的 Web 服务器来提供静态内容，也可以作为反向代理来分发请求到后端服务器。
- Tomcat 则专注于 Java 应用的部署和运行，是 Java 开发者常用的服务器之一。
优点
- 应用服务可用性：应用满足高可用，不会一个服务出问题整个站点挂掉
- 应用服务具备一定高性能：如果不访问数据库，应用相关处理通过扩展可以支持海量请求快速响应
- 应用支持横向扩展
缺点
- 数据库成为性能瓶颈，无法应对数据库的海量查询
- 数据库是单点，没有高可用
- 运维工作增多，扩展后部署运维工作增多，需要开发对应的工具应对快速部署
- 硬件成本较高
4. 读写分离/主从分离架构
简介
- 将数据库读写操作分散到不同的节点上，数据库服务器搭建主从集群，一主一从、一主多从都可以。数据库主机负责写操作，从机只负责读操作。
出现原因
- 数据库成为瓶颈，而互联网应用一般读多写少，数据库承载压力大，主要是由这些读的请求造成的，那么我们可以把读操作和写操作分开。
优点
- 数据库的读取性能提升
- 读取被其他服务器分担，写的性能间接提升
- 数据库有从库，数据库的可用性提高了
缺点
- 当同步挂掉，或者同步延迟比较大时，写库和读库的数据不一致
- 服务器成本需要进一步增加
5. 冷热分离架构
简介
- 引入缓存，实行冷热分离，将热点数据放到缓存中快速响应。
出现原因
- 海量的请求导致数据库负载过高，站点响应速度变慢。
- 例如双十一秒杀的时候，秒杀的数据就可以放到 缓存服务器中
优点
- 大幅降低对数据库的访问请求，性能提升非常明显
- 带来了缓存一致性，缓存击穿，缓存失效，缓存雪崩等问题
缺点
- 缓存一致性问题
- 服务器成本需要进一步增加
- 业务体量支持变大后，数据不断增加，数据库单表太大，单个表体量也太大，数据查询会很慢，导致数据库再度成为系统瓶颈
二. 架构
分布式数据库架构
简介
- 数据库的数据被拆分，数据库数据分布式存储，分布式处理，分布式查询，也可以理解为分布式数据库架构。
出现原因
- 单机的写库会逐渐达到性能瓶颈，需要拆分数据库，数据表的数据量太大，处理压力太大，需要进行分表，为降低运维难度，业界逐渐研发了分布式数据库，库表天然支持分布式。
- 可以以集群 为单位，进行部署
优点
- 数据库吞吐量大幅提升，不再是瓶颈
- 跨库join、分布式事务等问题，这些需要对应的去进行解决，目前的mpp都有对应的解决方案
缺点
- 数据库和缓存结合目前能够抗住海量的请求，但是应用的代码整体耦合在一起，修改一行代码需要整体重新发布
微服务架构
简介
- 微服务是一种架构风格，按照业务板块来划分应用代码，使每个应用的职责更清晰，相互之间可以做到独立升级迭代。
出现原因
- 扩展性差：应用程序无法轻松扩展，因为每次需要更新应用程序时，都必须重新构建整个系统
- 持续集成困难：一个很小的代码改动，也需要重新部署整个应用，无法频繁并轻松地发布版本
- 不可靠：即使系统的一个功能不起作用，可能导致整个系统无法工作
- 不灵活：无法使用不同的技术栈构建单体应用程序
- 代码维护难：所有功能耦合在一起，新人不知道何从下手
优点
- 灵活性高：服务独立测试、部署、升级、发布
- 独立扩展：每个服务可以各自进行扩展
- 提高容错性：一个服务问题并不会让整个系统瘫痪
- 新技术的应用容易：支持多种编程语言
缺点
- 运维复杂度高：业务不断发展，应用和服务都会不断增多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难（后面引入了 K8S~)
- 资源使用变多：所有这些独立运行的微服务都需要占用内存和CPU
- 处理故障困难：一个请求跨多个服务调用，需要查看不同服务的日志完成问题定位
应用
拿用户信息的时候 也可以同时拿取商品信息~
容器编排架构
简介
- 借助容器化技术（如docker）将应用/服务打包为镜像，通过容器编排工具（如k8s）来进行动态分发和部署镜像，服务以容器化方式运行。
出现原因
- 微服务拆分细，服务多部署工作量大，而且配置复杂，容易出错
- 微服务数量多扩缩容麻烦，而且容易出错，每次缩容后再扩容又需要重新配置服务对应的环境参数信息
- 微服务之间运行环境可能冲突，需要更多的资源来进行部署或者通过修改配置来解决冲突
抽象的理解
- 应用--快递
- 容器--docker--箱子
- 镜像--包裹
- k8s--快递公司，使几千台 docker 可以快速部署，减少了运维 环境配置 的工作量
- 服务端--收货地
优点
- 部署、运维简单快速：一条命令就可以完成几百个服务的部署或者扩缩容
- 隔离性好：容器与容器之间文件系统、网络等互不影响，不会产生环境冲突
- 轻松支持滚动更新：版本间切换都可以通过一个命令完成升级或者回滚
缺点
- 技术栈变多，对研发团队要求高
- 机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都很高，资源利用率低，可以通过购买云厂商服务器解决。
三. An Internet Application Architecture
理解
上层传输
一些说明
- WAF（Web Application Firewall，Web 应用防火墙）
-
- 作用：保护 Web 应用程序免受常见的攻击，如 SQL 注入和 XSS（跨站脚本）。
- 功能：通过监控和过滤 Web 流量，阻止恶意请求，提高网站安全性。
- CLB（Cloud Load Balancer，云负载均衡）
-
- 作用：将流量分发到多台服务器，保证服务的高可用性和可靠性。
- 功能：在多台服务器间分摊流量压力，提高系统的稳定性。
- SLB（Server Load Balancer，服务器负载均衡）
-
- 作用：类似于 CLB，将流量分配到多台服务器，但通常用于私有网络或内网环境。
- 功能：实现高可用的负载分担，提高资源利用率。
- API（Application Programming Interface，应用程序接口）
-
- 作用：提供应用之间的通讯标准，使它们能够互相调用功能。
- 功能：定义了不同软件系统之间如何交互的规则和协议。
- 网关（Gateway）
-
- 作用：作为系统的入口，控制流量、转发请求、保护后端服务。
- 功能：实现流量控制、身份验证和日志记录等功能。
- K8S（Kubernetes，容器编排平台）
作用：管理和自动化容器化应用的部署、扩展和运维。
功能：支持容器集群的调度和管理，常用于微服务架构。
- TKE：腾讯云的 Kubernetes 服务。
- ACK：阿里云的 Kubernetes 服务。
框架
Spring Cloud
- 作用：用于构建分布式系统的框架，提供配置管理、服务发现、断路器等工具。
- 功能：让微服务的管理和调用更加便捷，适合云原生应用的开发。
Dubbo
- 作用：一种 RPC（远程过程调用）框架，用于服务之间的调用。
- 功能：支持高效的服务发现和负载均衡，适合大规模微服务架构。
TSF（Tencent Service Framework，腾讯服务框架）
- 作用：腾讯云提供的微服务架构平台，支持微服务治理和监控。
- 功能：帮助企业快速搭建微服务体系，实现分布式系统管理。
Istio
- 作用：服务网格（Service Mesh）框架，管理微服务之间的通信。
- 功能：实现流量管理、故障恢复和安全策略，适合大型微服务集群。
数据处理
缓存数据
- Redis
-
- 作用：高性能的键值对存储数据库，常用作缓存。
- 功能：支持数据的快速存储和读取，适用于高并发场景。
- Tair
-
- 作用：阿里巴巴开发的分布式缓存系统。
- 功能：提供高性能数据缓存，支持大规模访问。
- Keewideb
-
- 作用：类似 Redis 的缓存系统，专注于高效的缓存服务。
- 功能：提供快速的数据读取和写入。
基础数据
- MySQL
-
- 作用：关系型数据库管理系统，广泛应用于 Web 开发。
- 功能：支持结构化数据的存储、查询和管理，数据一致性强。
- PolarDB
-
- 作用：阿里云推出的云数据库，兼具 MySQL 兼容性和高性能。
- 功能：支持弹性扩展和高并发访问，适合企业级应用。
- TDSQL
-
- 作用：腾讯云推出的分布式数据库，适合金融级业务。
- 功能：提供高可用和强一致性，支持海量数据的分布式存储。
- TiDB
-
- 作用：分布式 NewSQL 数据库，兼容 MySQL，适合大数据处理。
- 功能：支持水平扩展和强一致性，适合 OLTP 和 OLAP 场景。
- GBase
-
- 作用：国产数据库，支持事务和分析，适合大数据处理。
- 功能：适合于高并发访问的大规模数据处理任务。
- OSS/COS/MinIO
-
- 作用：对象存储服务，用于存储大量非结构化数据，如图片、视频。
- OSS：阿里云对象存储服务。
- COS：腾讯云对象存储服务。
- MinIO：开源对象存储解决方案。
- ES 集群（Elasticsearch）
-
- 作用：分布式搜索和分析引擎，支持全文检索。
- 功能：适合日志分析和大规模文本数据的搜索，广泛应用于日志管理和数据分析。
- MongoDB 集群
-
- 作用：分布式文档数据库，适合处理半结构化数据。
- 功能：支持高并发和大数据量存储，灵活性高。
- MaxCompute/EMR/GFS
-
- MaxCompute：阿里云的分布式计算服务，支持大数据分析。
- EMR（Elastic MapReduce）：阿里云和 AWS 提供的分布式数据处理服务，基于 Hadoop。
- GFS（Google File System）：谷歌的分布式文件系统，用于存储海量数据。
这些技术广泛应用于分布式系统和云计算，适用于构建可扩展、高效的现代化应用。
主要思想
- 一个人扛不住，喊兄弟过来
- 软件上，没有什么是加一层 解决不了的
“背锅”演进之路
通过对架构的优化，解决系统的问题
思考
1. 如何决策 要不要演进？
- 结合 满足 实际业务需求 即可
2. 架构必须这么演进吗？
- 结合 实际情况
3. 架构必须是这么几个么？
- 可以自行 增减，结合业务
4.docker 的核心作用？
- 容器化 实现细化