云计算架构设计原则

本文涉及的产品
云数据库 Redis 版,社区版 2GB
推荐场景:
搭建游戏排行榜
传统型负载均衡 CLB,每月750个小时 15LCU
云原生内存数据库 Tair,内存型 2GB
简介: 【4月更文挑战第6天】这篇文章介绍了基于云计算的架构设计六大原则:合理部署、业务持续、弹性扩展、性能效率、安全合规和持续运营。

基于云计算进行架构设计,所有的技术解决方案都应遵循一定的原则,这也是架构设计中要追求的目标。这6大原则,包括合理部署、业务持续、弹性扩展、性能效率、安全合规、持续运营。这6大原则代表了架构设计中需要考虑的不同角度,只有同时遵循这些原则才能设计出完善的架构方案,但在实际情况中,并不需要在所有架构设计中把所有设计模式都融入进去,构建繁杂的架构方案。

1、合理部署

业务系统在公有云上的部署包括使用虚拟机形式的云主机,还包括性能更强的物理云主机形式,托管服务包括托管应用、托管物理服务器。


基于IT历史资源状况、合规性要求等,很多企业还没有上云,针对这种情况,将云计算操作系统抽取出来打包为独立的软件和服务,在用户的私有化环境中进行部署。区别于公有云面向“任何”用户开放使用,私有化部署仅面向少数指定的用户使用。


混合架构能够对公有云和私有化部署的平台、传统的VMware、OpenStack虚拟化平台或物理服务器等资源进行统一管理和调度,混合架构既享受了不变更本地环境、满足合规要求的好处,又享受了云平台资源丰富、服务能力充足等优势。混合架构也是当前企业转型上云的一种中间状态,会长期存在。


在跨境电商、游戏出海等场景下会使用到全球范围内的多个地域,将业务和数据靠近用户来部署可以减少网络延迟、提升访问体验。因此,纳入了全球部署,来重点解决如何在全球范围内尽可能靠近用户部署的问题,也能实现数据同步存储和处理的方案。


不能相信任何一块硬盘、任何一台云主机、任何一个可用区、任何一个地域,也不能完全相信任何一个云服务商,进行业务部署时应选择多个公有云平台,提升业务持续性,弥补单个云服务商在资源和服务上的短板,屏蔽云服务商的一些技术锁定和商业绑定。


2、业务持续

业务持续性主要是指高可用、高可靠、灾难恢复三方面,在设计模式中也是按照这个逻辑展开的。

  • 高可用(High Availability),是指当业务运行的资源出现故障时,通过冗余等设计来避免业务中断。
  • 高可靠(Continuous Operations),是指业务运行的资源无故障,业务可持续提供服务。
  • 灾难恢复(Disaster Recovery),是指当业务运行环境遭到破坏时,在不同环境中恢复应用和数据的能力。


在架构设计的每一层中都应实现冗余和业务持续性,没有冗余就意味着会出现单点,而单点一旦出现故障,就会造成局部服务终止。

  • 存储产品:块存储通过三个副本实现冗余,当一个副本出现错误时,通过其他副本来校验和恢复数据;对象存储中通过纠删码来实现数据冗余校验,提供可恢复能力;对象存储提供跨区域复制功能,避免单个地域成为对象存储的单点。
  • 备份方案:在云端通过跨可用区、跨地域的数据备份提升可靠性,避免只存储一份数据;在混合架构中将数据备份到云端,在本地环境数据损坏时,可通过云端备份文件进行恢复。
  • 容灾方案:对业务系统实现容灾,避免当前业务环境成为单点,提升整体业务的可用性和抗风险能力。
  • 高可用:通过跨可用区的负载均衡部署实现云主机和可用区的冗余;通过全局负载均衡实现跨地域、跨云平台的高可用。


3、弹性扩展

紧耦合的系统不容易扩展,在出现软件Bug和系统故障时难以排查问题,调用每个系统组件的压力各不相同,小问题逐级放大,容易造成整个业务中断。要保持系统弹性扩展,首先要进行系统组件的解耦,包含动态数据和静态数据解耦,解耦后的组件可实现功能单元化,各司其职。


解耦之后再对组件和服务进行扩展,即计算资源的纵向扩展、横向扩展和自动伸缩,包括数据库层的扩展,还有通过混合架构延展本地环境的计算、存储备份、安全防护、产品服务能力。对应用和数据的迁移也算作整个系统的扩展,从一个环境迁移到另外一个环境,系统应保持弹性扩展,在需要迁移时能够快速实施迁移。最后还要进行均衡,组件解耦、资源和服务扩展之后需要统一的接入入口,以屏蔽底层解耦与扩展带来的接口不统一等问题。


在各个层面实现解耦,通过消息队列来解耦组件之间的通信,并解耦事件;通过Redis等共享存储实现状态数据与计算资源的解耦;采用云主机部署业务应该面向服务而非资源,将资源与业务解耦;存储实现弹性可挂载和可卸载的云硬盘,采用可绑定和解绑定的EIP;通过DDoS防护、WAF防护等解耦安全防护与计算资源;使用原生的计算能力、存储能力将业务与云平台的特性解耦,实现业务在多个云平台中的可扩展。


组件解耦是实现可扩展的前提,可通过以下方式进行解耦。

  • 保持无状态,将状态数据存储到Redis中。
  • 放到负载均衡中,扩容、缩容不影响整体业务。
  • 通过消息队列、API Gateway解耦,生产者、消费者可扩展且互不影响。
  • 实现业务的全局负载均衡,后端业务能够在混合架构、多云环境中进行扩展。


4、性能效率

非常多的解决方案和案例中都涉及高并发、流量激增带来的对性能的挑战,在性能效率中,主要目标是发现和提升应用的性能,提高资源和组件的效率。


首先是计算性能,通过采用高配置的云主机或物理云主机来提升单机性能,通过集群形式扩展整体服务性能。


其次是存储和缓存,通过Redis来缓存热点数据、存储临时状态数据,在内存中进行计算能够提升业务性能。在每一层使用缓存,通过CDN缓存静态文件,对没有命中的文件进行回源;通过Redis缓存数据库,加速数据库的访问;通过Redis缓存热点配置文件、热点数据,提前加载,减少访问时间。


再次是对网络性能的优化,在业务实现全球部署时选择最优数据中心,并且基于全球基础网络、CDN及全球应用加速来提升网络性能,获得请求加速效果。


最后应用性能监测和压力测试,从应用的角度上来评测当前的性能状况、发现问题瓶颈,并针对性地解决问题。


5、安全合规

安全合规一方面是为了满足业务安全防护的自身需求,另一方面是满足安全监管的合规要求,在具体实施时会将这两方面交叉在一起。


首先,从用户账号和权限管理切入,为合适的人员分配恰当的账号、角色,授予最低权限,对于通过API或CLI来访问的程序或人员分配恰当的公钥、私钥和权限,对于临时访问的对象存储文件Token等也进行严格管理。其次,还有在整个安全体系中的终端安全、数据安全、网络安全、应用安全,以及对日志、行为、数据库操作的审计。最后,还有等保2.0的要求、网站备案要求、满足GDPR等各地区对业务和数据隐私要求的制度等。

  • 在账号体系中设置主账号、子账号,并对公钥、密钥进行管理;设置合适的角色,为账号、角色分配所需要的最低权限。
  • 通过ACL控制网络访问;通过安全组限制云主机开放的端口等;通过子网和路由控制跨子网的通信。将数据库及只需要内部访问的云主机配置到内网VPC中,设置允许访问的VPC,设置为不连通外网。
  • 防止DDoS、cc、SQL注入、XSS等攻击。
  • 安全审计,保留访问日志、操作日志,逐步实现低频存储、归档存储等。


6、持续运营

云平台提供的资源与服务均有SLA,云主机的SLA通常为99.95%,用户构建的业务系统都是基于云资源和云服务的SLA,在此之上构建可用性、可靠性更高的业务系统。对于自身业务系统,也需要制定SLA来表明服务可用性或其他指标,制定了用户业务的SLA后,就可以按照SLA阈值来设置高可用限流值,综合评估整体业务的服务可用性和数据可靠性,并指定故障应急措施。


在持续运营中会对云资源、云服务、事件及用户的应用进行监控,并设置告警,在达到告警条件时,通过电话、短信、邮件、钉钉、微信等方式通知相关人员,将告警交给回调函数,可实现自动化故障处理或相应的应急预案,减少人工介入。


应该在架构设计的每一层进行监控与告警,包括对云资源、事件、应用运行状况的全方位监控。对于用户自定义的需要监测的资源与服务,需要配置合理有效的告警策略来及时发现异常情况。通过Advisor实现云平台巡检,持续监测资源的变化,持续定期评估业务架构,及时发现业务架构是否还匹配业务需求。


此外,还需要具备自动化响应及处理功能,自动伸缩能够通过监控CPU等指标自动扩容或缩容云主机数量;通过定时器固定周期扩容或缩容云主机数量。实现事件驱动响应,由事件消息触发执行脚本、回调函数等操作,实现智能运维,根据事件和告警自动触发运维操作,编排运维脚本,通过智能运维的方式来减少人工运维。


及时发现消费及业务成本的变化,并对成本进行优化。设置账户余额告警值,避免快速消费,实现成本控制。评估资源使用时长,将按时计费的资源转变为按月、按年计费,优化资源的使用。通过Advisor中建议的成本优化释放没有使用的EIP,根据CPU等指标来减少云主机数量或降低云主机配置,云主机处理对象存储时通过内网进行访问,减少外网访问的流量费用。通过多云部署实现成本优化,综合多个云平台的资源价格选择资源,选用较优的组合方案,通过其他云平台更低单价的竞价实例云主机来处理OLAP的业务。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore     ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
6天前
|
消息中间件 监控 API
深入浅出微服务架构设计原则
在软件开发的宇宙中,微服务如星辰般璀璨,引领着分布式系统的航向。本文将带你穿梭于微服务的星系,探索其背后的设计哲学与实践精髓,从服务边界的划分到数据一致性的保障,再到服务的通信与协作,我们将一同揭开微服务架构高效、可扩展且灵活的秘密。
16 4
|
4天前
|
存储 人工智能 云计算
云计算演进问题之冯·诺伊曼架构的主要特点如何解决
云计算演进问题之阿里云自研CPU倚天710的部署如何解决
|
7天前
|
消息中间件 设计模式 API
后端开发中的微服务架构设计原则
【8月更文挑战第13天】在软件工程的世界中,微服务架构已经成为一种流行的设计模式,它通过将复杂的应用程序分解成一组小的服务来简化开发和部署。本文探讨了微服务背后的设计理念,以及如何在后端开发实践中应用这些原则来构建可扩展、灵活且易于维护的系统。我们将深入讨论服务的划分、通信协议的选择、数据一致性的保障以及容错性策略的实施,旨在为后端开发人员提供一套实用的微服务架构设计指导。
20 1
|
26天前
|
NoSQL Redis UED
业务架构问题之在流程建模中,“定职责”的重要性是什么,流程建模中的交互设计原则是什么
业务架构问题之在流程建模中,“定职责”的重要性是什么,流程建模中的交互设计原则是什么
|
17天前
|
消息中间件 监控 Java
解锁Spring Cloud微服务架构的奥秘:深度剖析拆分原则,打造高内聚低耦合的业务创新引擎!
【8月更文挑战第3天】踏入微服务领域,Spring Cloud以丰富组件助力高效系统构建。微服务拆分需遵循原则确保系统高内聚低耦合且能适应变化。首要原则为单一职责,每个服务专注一个业务功能,降低复杂度并提高可维护性。其次,追求高内聚低耦合以减少服务间影响。围绕业务域拆分有助于保持逻辑清晰及团队协作。处理数据一致性问题时,考虑采用最终一致性模型。Spring Cloud提供Eureka、Zuul/Gateway、Sleuth和Config等工具支持服务发现、路由、跟踪及配置管理,共同构建灵活健壮的微服务架构。
32 2
|
25天前
|
存储 设计模式 前端开发
软件架构设计的原则与模式:构建高质量系统的基石
【7月更文挑战第26天】软件架构设计是构建高质量软件系统的关键。遵循高内聚、低耦合、单一职责等设计原则,并灵活运用分层架构、微服务架构、客户端-服务器架构等设计模式,可以帮助我们设计出更加灵活、可扩展、可维护的软件系统。作为开发者,我们应该不断学习和实践这些原则与模式,以提升自己的架构设计能力,为团队和用户提供更加优秀的软件产品。
|
26天前
|
Go C++ 云计算
云计算自旋锁问题之iLogtail架构重构的主要目标如何解决
云计算自旋锁问题之iLogtail架构重构的主要目标如何解决
30 1
|
1月前
|
运维 监控 Serverless
Serverless架构下的函数计算:重塑云计算的未来
【7月更文挑战第16天】Serverless架构下的函数计算作为云计算领域的一项重大创新,正以其独特的优势改变着应用开发和运维的方式。随着技术的不断成熟和完善,函数计算将在更多领域发挥重要作用,推动云计算技术向更加高效、灵活和智能的方向发展。对于开发者和企业来说,掌握函数计算技术将是把握未来云计算机遇的关键所在。
|
12天前
|
边缘计算 Kubernetes 持续交付
构建高效后端系统:面向未来的架构设计原则
【8月更文挑战第8天】在技术飞速发展的今天,后端系统的架构设计显得尤为关键。本文将探讨如何通过采用微服务、容器化及自动化等现代技术手段,来构建一个可扩展、高可用且易于维护的后端系统。我们将深入分析这些技术背后的原理及其在实际场景中的应用,同时也会讨论如何在保障数据一致性和系统安全性的前提下,提升系统的响应速度和处理能力。
|
30天前
|
搜索推荐
业务系统架构实践问题之有效地实现“域间不可见”原则问题如何解决
业务系统架构实践问题之有效地实现“域间不可见”原则问题如何解决