系统架构设计介绍
分布式架构
初始阶段架构
特征
- 应用程序,数据库,文件等所有资源都放在同一台服务器上
应用服务和数据服务以及文件服务分离
特征
- 应用程序,数据库和文件分别部署在独立的资源上
问题
- 随着系统访问量的再度增加 ,webserver机器的压力在高峰期会上升到比较高,需要开始考虑增加一台webserver
使用缓存改善性能
特征
- 数据库中访问较集中的一小部分数据存储在缓存服务器中,减少数据库的访问次数,降低数据库访问压力
问题
- 系统访问特点遵循二八定律,即80% 的业务访问集中在20% 的数据上
- 缓存分为本地缓存和远程分布式缓存
- 本地缓存访问的速度更快但是缓存数量有限,同时存在与应用程序争抢内存的情况
使用应用服务器集群
特征
- 多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题
描述
- 使用集群是解决高并发,海量数据问题的常用手段
- 通过向集群中追加资源,提升系统的并发处理能力,使得服务器的负载压力不再成为整个系统的瓶颈
问题
- Apache会阻塞很多请求,应用服务器对每个请求的比较快的
- 请求数太高会导致需要排队等待,响应速度变慢
数据库读写分离
特征
- 数据库引入了主备部署
描述
- 数据库划分为读库和写库
- 通过引入主从数据库服务,读和写操作在不同的数据库服务处理
- 读库可以有很多个,通过同步机制将写库的数据同步到读库
- 对于需要查询最新写入数据的场景,可以通过缓存中多写一份,通过缓存获得最新数据
问题
- 数据库写入,更新的操作部分对数据库连接的资源竞争非常激烈,导致系统变慢
反向代理和CDN加速
特征
- 采用CDN和反向代理加快系统的访问速度
描述
- 为了应付复杂的网络环境和不同地区用户的访问,通过CDN和反向代理加快用户访问的速度,同时减轻后端服务器的压力
- CDN与反向代理的基本原理都是缓存
分布式文件系统与分布式数据库
特征
- 数据库采用分布式数据库,文件系统采用分布式文件系统
描述
- 任何强大的单一服务器都满足不了大型系统持续增长的业务需求
- 数据库读写分离随着业务的发展最终也将无法满足需求,需要使用分布式数据库及分布式文件系统来支撑
- 分布式数据库:
- 是系统数据库拆分的最后方法,只有在单表数据规模非常庞大的时候才使用
- 更常用的数据库拆分手段是业务分库,将不同的业务数据库部署在不同的物理服务器上
问题
- 随着系统的不断运行,数据量开始大幅增长
- 数据库分库的查询仍然很慢,于是按照分库的思想来做分表的工作
使用NoSQL和搜索引擎
特征
- 系统引入NoSQL数据库和搜索引擎
描述
- 随着业务越来越复杂,对数据存储和检索的要求也越来越复杂,系统需要采用一些非关系型数据库NoSQL和分数据查询技术搜索引擎
- 应用服务器通过统一的数据访问模块访问各种数据,减轻程序管理诸多数据源的麻烦
业务拆分
扫描二维码关注公众号，回复：
11567495 查看本文章
特征
- 系统按照业务进行拆分,应用服务器按照业务区分进行分别部署
描述
- 为了应对日益复杂的业务场景,通常使用分而治之的手段将整个业务系统分成不同的产品线
- 应用之间通过超链接建立关系,也可以通过消息队列进行数据分发.更多是通过访问同一数据存储系统来构成一个关联的完整系统
- 纵向拆分:
- 将一个大应用拆分成多个小应用
- 如果新业务比较独立,那么就直接设计部署为一个独立的Web应用系统
- 纵向拆分相对比较简单,通过梳理业务,可以将较少相关的业务剥离即可
- 横向拆分:
- 将复用的业务拆分出来,独立部署为分布式系统
- 新增的业务只需要调用这些分布式服务
- 横向拆分需要识别可复用的业务,设计服务接口,规范服务依赖关系
分布式服务
特征
- 公共的应用模块被提取出来,部署在分布式服务器上供应用服务器调用
问题
- 随着业务越拆越小,应用系统整体复杂程度呈指数级上升
- 由于所有应用要和所有数据库系统连接,最终导致数据库连接资源不足,拒绝服务
分布式架构问题和挑战
- 当服务越来越多时,服务URL配置管理变得非常困难,硬件负载均衡器的单点压力也越来越大
- 当服务越来越多时,服务间的依赖关系变得错综复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整地描述应用的架构关系
- 服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?
- 服务多了,沟通成本也开始上升,调用某个服务失败应该找谁?服务的参数都有什么约定?
- 一个服务有多个业务消费者,如何确保服务质量?
- 随着服务的不断升级,总有一些意想不到的事情发生: 比如cache写错了导致内存溢出,故障不可避免,每次核心服务宕机,影响损失大,如何控制故障的影响面?服务是否可以功能降级?服务是否可以资源劣化?
- 针对这个问题,可以使用以下架构解决:
- 单元化架构
- 微服务架构
- Serveless架构
- 针对业务系统,做到以下几个方面可以解决上述问题:
- 业务与业务隔离
- 管理域和运行域分开
- 业务与平台隔离
单元化架构
什么是单元化
- 单元化架构师是从并行计算领域发展而来
- 在分布式架构领域:
- 一个单元Cell: 满足某个分区所有业务操作的自包含的包装
- 一个分区Shard: 整体数据集的一个子集. 比如如果是用尾号来划分用户,那么同样尾号的那部分用户就可以认为是一个分区
- 单元化就是将一个服务设计改造成符合单元特征的过程
单元化的必要性
- 随着硬件的不断升级,计算机硬件能力已经越来越强,CPU越来越快,内存越来越大,网络越来越宽.这样就有了在单台机器上进行垂直扩展的能力
- 当遇到一个性能要求和容量增长可以预期的业务,单元化可以有效降低资源的使用,提供更高的性能服务
- 经过单元化改造,可以只使用一半的机器,获得比原来接近百倍的性能
- 性能的提升很大部分原因在于服务本地化,而服务的集成部署又进一步降低了资源的使用
- 单元化除了性能收益,还有更好的隔离性,包括请求隔离和资源隔离.更友好的升级,产品可以灰度发布
- 单元化改造后可以对高峰的应对以及扩容方式的解决
如何实现单元化
- 传统的服务架构:
- 服务是分层的
- 每一层使用不同的分区算法
- 每一层都有不同数量的节点
- 上层节点随机选择下层节点
- 单元化架构:
- 服务虽然分层划分,但是每个单元自成一体
- 所有层次使用相同的分区算法,每一层都有相同数量的节点,上层节点也会访问指定的下层节点
SOA架构
SOA架构基本概念
- SOA: Service-Oritented Architecture
- 面向服务的架构
- 是一个组件模型
- 将应用程序的不同功能单元,即服务.通过这些服务之间定义良好的接口和契约联系起来
- 接口采用中立的方式进行定义的,独立于实现服务的硬件平台,操作系统和编程语言
- 这样使得构建在各种个样的系统中的服务可以以一种统一和通用的方式进行交互
- 面向服务架构,可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署,组合和使用
- 服务层是SOA的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性
SOA实施基本特征
- 实施SOA的关键目标是实现企业IT资产的最大化作用.要实现这一目标,就要在实施SOA的过程中牢记以下特征:
- 可以从企业外部访问
- 随时可用
- 粗粒度的服务接口分级
- 松散耦合
- 可重用的服务
- 服务接口设计管理
- 标准化的服务接口
- 支持各种消息模式
- 精确定义各种服务契约
- 服务消费者Service Consumer可以通过发送消息来调用服务
- 这些消息由一个服务总线Service Bus转换后发送给适当的服务实现
- SOA架构可以提供一个业务规则引擎Business Rules Engine允许业务规则被合并在一个服务或者多个服务里
- SOA架构也提供了一个服务管理基础Service Management Infrastructure用来管理服务,比如审核,列表和日志等功能
- SOA架构给企业提供了灵活的业务流程,更好地处理控制请求Regulatory Requirement. 比如Sarbanes Oxley(SOX), 并且可以在不影响其余服务的情况下更改某项服务
微服务架构
传统的Web开发方式
- 所有的功能打包在一个war包里
- 除了容器之外,基本没有外部依赖
- 部署在一个JEE容器里,比如Tomcat, JBoss和WebLogic
- 包含了DO或者DAO,Service,UI等所有逻辑
优点
- 开发简单,集中式管理
- 基本不会重复开发
- 功能都在本地,没有分布式管理和协调消耗
缺点
- 效率低: 开发都在同一个项目改代码,相互等待,冲突不断
- 维护难: 代码功能耦合在一起,难以维护
- 不灵活: 构建时间长,任何小修改都要构建整个项目,耗费时间
- 稳定性差: 一个微小的问题,都可能导致整个应用宕机
- 扩展性不够: 无法满足高并发下的业务需求
系统架构的标准
- 提高敏捷性: 及时响应业务需求,促进企业发展
- 提升用户体验: 提升用户体验,减少用户流失
- 降低成本: 降低增加产品,客户活业务方案的成本
基于微服务的架构设计
- 目的: 有效拆分应用,实现敏捷开发和部署
- 微服务:
- X轴: 运行多个负载均衡器之后的运行实例
- Y轴: 将应用进一步分解为微服务 - 分库
- Z轴: 大数据时,将服务分区 - 分表
SOA和微服务的区别
- SOA偏重重用,微服务偏重重写
- SOA偏重水平服务,微服务偏重垂直服务
- SOA偏重自上而下,微服务偏重自下而上
Serverless架构
思想
- 无服务器是一种架构理念
- 核心思想: 将提供服务资源的基础设施抽象成各种服务,以API接口的方式供用户按需使用
- 真正做到按需收缩,按使用收费
优势
- 消除了对传统的海量持续在线服务器组件的需求
- 降低了开发和运维的复杂性
- 降低运营成本并缩短了业务系统的交付周期
- 使得用户能够专注在价值密度更高的业务逻辑的开发上
内容
- 无服务器架构主要包括两个方面:
- 提供计算资源的函数服务平台FaaS
- 提供托管云服务的后端服务BaaS
函数即服务-FaaS
- 是一项基于事件驱动的函数托管计算服务
- 开发者只需要编写业务函数代码并设置运行条件,无需配置和管理服务器基础设施
- 函数代码运行在无状态的容器中,由事件触发且短暂易失,并完全由第三方管理,基础设施对应用开发者完全透明
- 函数以弹性高,高可用的方式运行,并且按照实际执行资源计费,不执行不产生费用
后端即服务-BaaS
- Baas涵盖了应用可能依赖的所有第三方服务:
- 云服务
- 身份验证
- 对象存储等
- 开发人员通过API和由BaaS服务商提供的SDK, 能够集成所需的所有后端功能,而无需构建后端应用,更不必管理虚拟机或容器等基础设施,就能保证应用的正常运行
三个优秀的less架构概念
Codeless
- Codeless对应的是服务开发
- 实现了代码托管
- 只需要关心代码实现,不需要关心代码在哪,因为整个过程不会感受到代码库和代码分支的存在
Applicationless
- Applicationless对应的服务发布
- 在无服务化的框架下,服务发布不需要申请应用,不需要关注应用在哪
Serverless
- Serverless对应的是服务运维
- 不需要关注机器资源,Serverless会完成机器资源的弹性扩容