一、架构基础 架构定义：有关软件整体结构与组件的抽象描述，用于指导软件系统各个方面的设计 常见软件架构 单机：所有功能都实现在一个进程里，进程部署在单台机器上，运维时需要停服 C10K问题（Concurrent 10,000 Connection）：服务器如何支持10K个并发连接，进行高性能网络编程。解决方式：采用IO复用模型epoll方法，在调用返回时，只给应用提供发生了状态变化的文件句柄，不需要轮询fd（文件描述符） 单机架构瓶颈： 需要大量进程 / 线程作为处理单元，需要占用大量内存空间 进程 / 线程切换，系统调度代价高 解决方案：采用协程（Routine），一个线程中，存在多个协程。协程实现如Go语言的轻量级线程Goroutine。协程由程序控制，在用户态中执行，在线程的基础上通过分时复用的方式运行多个协程 协程适用场景：IO密集型任务，异步IO型任务（异步IO型任务包括：主动查询是否有数据；被动监听是否有数据状态） 单体：分布式部署，进程部署在多台机器上，具备水平扩容能力（添加更多服务器），运维不需要停服 CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）三项中的两项 一致性：所有节点同时看到相同的数据 可用性：读写总是成功的 分区容错性：尽管任意消息存在丢失或部分系统存在故障，系统继续运行 垂直应用：单体架构基础上，将进程按照应用垂直切分开的单体，在一定程度上减少了后端进程职责 面向服务型架构（SOA，Service Oriented Architecture）：将进程按照不同的功能单元进行抽象，拆分为服务。SOA为服务间通信提供标准，采用重量级协议，如SOAP及其他WS标准 微服务（Micro-Service）：SOA的去中心化的演进，每个服务都有自己的数据模型和数据库 注意事项： 数据一致性 高可用 治理、容灾 解耦 vs. 过微 权衡运维成本 架构演进方式：业务需求量逐渐增大、系统逐渐复杂 水平切分：分层 / 模块化 垂直切分：分布式 二、企业级后端架构 云计算：通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模数据分析和存储的基石 虚拟化技术：对计算机资源的抽象，实现资源隔离与共享，资源异构性屏蔽，资源池化 硬件层：VMware 操作系统层：Docker 网络层：Open V Switch（OVS），基于软件实现的开源虚拟交换机 编排方案 VM：OpenStack（一款开源虚拟化平台） / VMWare Workstation OpenStack各组件： Horizon，Web前端服务 Nova，计算服务 Neutron，网络服务 Swift，对象存储服务 Cinder，块存储服务 Keystone，认证服务 Glance，镜像服务 Ceilometer，监控服务 Heat，集群服务 Trove，数据库服务 Container：Kubernetes、Docker Swarm 云架构 IaaS：Infrastructure as a Service，基础设施即服务，对底层硬件资源池的抽象。消费者在其中的角色是开发者或系统管理员。如阿里云的ECS云主机、Amazon EC2（2006年推出） PaaS：Platform as a Service，平台即服务，基于资源池抽象，云中有完整开发和部署环境。消费者在其中的角色是开发者。如Google App Engine、Windows Azure Platform SaaS：Software as a Service，软件即服务，基于弹性资源平台，一切不需要本地化部署的云服务软件产品。消费者在其中的角色是终端用户。如OA、CRM、E-mail服务 FaaS：Function as a Service，函数即服务，更轻量级的函数服务。开发者只需要编写业务代码，无需关注服务器，并且代码的执行由事件触发。如LeetCode的Online Judge系统、AWS Lambda 云原生（Cloud Native）：构建和运行可弹性拓展的应用 弹性资源 弹性计算资源：虚拟化容器、快速扩缩容 服务资源调度 微服务 大服务：调用量多 计算资源调度 在线计算：互联网后端服务，如热销榜单 离线计算：大数据分析，MapR / Spark / Flink，如热销榜单更新 消息队列 在线队列：削峰、解耦 离线队列：结合数据分析的一整套方案，如ELK 弹性存储资源：将存储资源当成服务一样 经典存储 对象存储：视频、图片等 大数据存储：应用日志、用户数据等 关系型数据库 元数据： 服务发现：程序如何通过一个标志来获取服务列表，并且这个服务列表能够随着服务的状态而动态变更 NoSQL KV存储：Redis 文档存储：MongoDB 微服务架构：提供业务功能单元解耦，提供统一的通信标准。微服务将单一应用程序划分成一组小的服务，每个服务域进行在独立的进程中。云原生场景下，微服务不必在业务逻辑中实现符合通信标准的交互逻辑，而是交给框架来做 通信协议：轻量级的通信机制 HTTP（RESTful API） RPC（Thrift，gRPC） 微服务中间件RPC和HTTP：选用时从性能（RPC提供大量压缩方案）、服务治理、协议可解释性（HTTP的JSON格式）来考虑 微服务的部署方式 虚拟机 容器 解决了应用程序运行环境依赖 实现计算资源、网络、存储的隔离 提高部署密度和计算资源的利用率 无服务器模式（Serverless）：由开发者实现的服务端逻辑运行在无状态的计算容器中，由事件触发，完全被第三方管理 无需管理基础设施 事件驱动 自动化构建部署 无服务器计算 = FaaS + BaaS（Function as a Service + Backend as a Service） DevOps：贯穿整个软件开发周期 敏捷开发 CI / CD（Continuous Integration / Continuous Delivery，持续集成 / 持续交付）：实现应用开发中高度持续自动化和持续监控 服务网格（Service Mesh）：微服务之间通信的中间层，一个高性能的四层网络代理，数据平面代理与业务进程采取进程间通信的模式，将流量层面的逻辑（包含治理）与业务进程解耦 业务与治理解耦，生命周期易于管理 异构系统的治理统一化 具有复杂治理能力 三、后端架构的挑战 基础设施层面 存在问题： 离线任务（主要为CPU密集型，非实时性）和在线任务（主要为IO密集型，潮汐性、实时性）的物理资源用量峰期不同。 物理资源有限、带宽有限，资源利用率受限于部署服务 解决思路： 离在线资源并池：采用混合资源池，按时间段划分离线资源池和在线资源池，提高物理资源利用率 同一个机器上的离在线隔离：使用容器对CPU核心做隔离，使用cgroup统一对离在线进程进行分组 利用在线业务潮汐性自动扩缩容，扩缩容的依据指标：如CPU使用率的P50数值（中位数值）、内存利用率等 用户层面 存在问题： 网络抖动导致运维成本提高 异构环境中，不同实例间的算力差异（CPU型号差异、网络请求差异） 目标：打平异构环境算力差异，为自动扩缩容提供正向输入 解决思路：如何屏蔽异构环境的算力差异？CPU水位负载均衡 IaaS：提供资源探针（Probe） 服务网格：动态负载均衡 微服务层面 存在问题1：微服务间的高通信成本 目标：降低业务成本，提高服务可用性 解决思路：微服务亲和性部署，满足亲和性条件的容器微服务中间件采用IPC（Inter-Process Communication）通信，不满足亲和性条件的容器通过服务网格RPC（Remote Procedure Call），从而减少网络通信。 将满足亲和性条件（调用关系紧密、通信量大的服务）的容器部署到一台宿主机 微服务中间件与服务网格通过共享内存通信 服务网格控制面实施灵活、动态的流量调度 存在问题2：流量治理问题 目标：提高微服务调用容错性、提供容灾、DevOps提高开发效率 解决思路：基于微服务中间件和服务网格的流量治理 熔断、重试 单元化 复杂环境（功能、预览）的流量调度 四、后端架构实战 如何做架构设计 需求先行：问题定义 业界调研：可参考的业界解决方案 技术选型：内部 / 社区中的基础组件 考虑异常情况：考虑某服务不行了怎么办 基本概念 负载均衡（Load Balancing）：将工作负载分布到多个服务器来提高服务的性能和可靠性 服务发现（Service Discovery）：容器部署在集群时，服务地址（IP和端口）是集群动态分配的。服务发现解决了在微服务中如何精确的定位需要调用的服务IP及端口 服务注册（Service Registry）：服务提供者将自己的服务地址等信息登记到服务注册中心 注册中心：服务提供者和服务消费者之间的桥梁，提供管理和查询服务注册信息的API。当服务提供者的实例发生变更时，服务注册表更新最新的状态列表，并通知服务消费者 如Zookeeper、Netflix Eureka 宿主机（Host）：可以是物理机或虚拟机 容器（Container）：包含了完整的运行时环境，基于内核的轻量级虚拟化技术。容器允许同一物理或虚拟服务器上毫不冲突地运行多项工作负载 时序数据（Times Series）：与时间序列相关的数据，如哨兵监控的指标数据、业务数据（JVM GC、时延） 一致性哈希（Consistent Hash）：由于HTTP协议的无状态，服务器可能选择存储会话日志来记住用户，从而减少身份验证。因此，在添加或删除服务器时，需要尽可能减少对其他服务器的影响 一致性哈希算法的步骤： 将服务器节点哈希映射到[0, 2^32-1]的整数圆环上 将请求哈希映射到圆环上 从请求哈希映射的顺时针方向找到其右侧最近的服务器 作用：增加 / 删除服务器时，最多只有一台服务器会受到服务器数量变化的影响 问题：如何设计一个根据主机层面的资源信息，实时进行流量调度的系统，屏蔽不同宿主机异构环境的算力差异？ 输入 服务网格数据面：支持带权重的负载均衡策略，服务发现，流量调度 注册中心：存储所有容器的权重信息 宿主机：提供容器的资源使用情况、物理资源信息（如CPU型号） 关键点 紧急回滚能力 大规模场景中使用：主要考虑系统稳定性和计算瓶颈 极端场景 架构演进方向 方案一：自适应静态权重。采集宿主机物理资源信息，调权代理调整容器注册的权重，缺少紧急回滚能力 方案二：自适应动态权重。动态权重决策中心从注册中心获取和更新服务注册信息，从配置中心获取服务在注册中心的名字，通过计算赋予服务运行时自适应动态权重，具备紧急回滚能力 方案三：在服务网格层面上报RPC指标（e.g. 实例：X:9090，延迟P50:10ms，延迟P99:100ms），防止权重调节过于偏颇。动态权重中心除了方案二的作用以外，还采集所有服务容器指标，使得极端场景处理成为可能，但时序数据库压力较大 方案四：构建更复杂的动态权重决策中心 微服务化进行拆分（如分为入口层、离线分析层、在线分析层等） 引入消息队列削峰、解耦 离在线链路切分 梳理强弱依赖 ———————————————— 版权声明：本文为CSDN博主「Remoa」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：blog.csdn.net/Remoa_Dengq…
