简朝阳:高可用可扩展数据库架构

合集下载

构建高可用性系统架构的最佳实践

构建高可用性系统架构的最佳实践

构建高可用性系统架构的最佳实践在今天的数字化时代,高可用性系统架构对于许多企业来说已经成为一个关键的需求。

无论是金融行业中的在线支付系统,还是电子商务平台上的购物系统,都需要确保系统在面对突发情况时依然能够保持稳定运行。

本文将介绍构建高可用性系统架构的最佳实践。

一、容错性设计容错性是构建高可用性系统架构的基础。

通过对系统中的每个组件进行容错设计,可以在组件发生故障时保证系统的可用性。

以下是一些常见的容错性设计策略:1.冗余备份:通过增加冗余的服务器、存储设备、网络设备等,可以在主设备发生故障时快速切换到备份设备,从而保证系统的连续性运行。

2.负载均衡:通过在系统前端引入负载均衡设备,将流量分发到多个服务器上,可以有效避免单点故障,提高系统的可用性和性能。

3.错误检测和恢复机制:在系统中引入错误检测和恢复机制,可以及时发现并修复系统中的故障,避免故障的扩散和影响。

二、分布式架构设计分布式架构是构建高可用性系统的另一个重要策略。

通过将系统的各个模块部署在不同的服务器上,可以有效提高系统的可用性和性能。

以下是一些分布式架构设计的最佳实践:1.微服务架构:将系统拆分为多个独立的微服务,每个微服务负责一个特定的功能,通过微服务之间的通信协议进行协同工作。

这种架构可以增加系统的模块化程度,减少单点故障的风险。

2.数据分区和复制:将系统中的数据进行分区和复制,将数据存储在多个节点上,可以提高数据的可用性和可靠性。

当某个节点发生故障时,可以通过备份节点快速恢复数据。

3.消息队列:引入消息队列作为系统组件之间的通信媒介,可以实现异步通信,降低系统之间的耦合度。

当某个组件发生故障时,消息队列可以暂时存储消息,保证系统的稳定性。

三、监控和自动化运维监控和自动化运维是保证高可用性系统稳定运行的关键一环。

通过实时监控系统的运行状态,可以快速发现并解决潜在的故障。

以下是一些监控和自动化运维的最佳实践:1.实时监控:引入监控系统对系统的各个组件进行实时监控,包括服务器的负载、网络的带宽、服务的响应时间等指标。

分布式存储解决方案

分布式存储解决方案

分布式存储解决方案目录一、内容概览 (2)1. 背景介绍 (3)2. 目标与意义 (3)二、分布式存储技术概述 (5)1. 分布式存储定义 (6)2. 分布式存储技术分类 (7)3. 分布式存储原理及特点 (8)三、分布式存储解决方案架构 (9)1. 整体架构设计 (10)1.1 硬件层 (12)1.2 软件层 (13)1.3 网络层 (14)2. 关键组件介绍 (15)2.1 数据节点 (16)2.2 控制节点 (18)2.3 存储节点 (19)2.4 其他辅助组件 (20)四、分布式存储解决方案核心技术 (22)1. 数据分片技术 (23)1.1 数据分片原理 (25)1.2 数据分片策略 (26)1.3 数据分片实例分析 (28)2. 数据复制与容错技术 (29)2.1 数据复制原理及策略 (31)2.2 容错机制与实现方法 (32)2.3 错误恢复过程 (34)3. 数据一致性技术 (35)3.1 数据一致性概念及重要性 (36)3.2 数据一致性协议与算法 (37)3.3 数据一致性维护与保障措施 (38)4. 负载均衡与性能优化技术 (39)4.1 负载均衡原理及策略 (41)4.2 性能优化方法与手段 (43)4.3 实例分析与展示 (43)五、分布式存储解决方案应用场景及案例分析 (44)1. 场景应用分类 (46)2. 具体案例分析报告展示 (47)一、内容概览分布式存储解决方案是一种旨在解决大规模数据存储和管理挑战的技术架构,它通过将数据分散存储在多个独立的节点上,提高数据的可用性、扩展性和容错能力。

本文档将全面介绍分布式存储系统的核心原理、架构设计、应用场景以及优势与挑战。

我们将从分布式存储的基本概念出发,阐述其相较于集中式存储的优势,如数据分布的均匀性、高可用性和可扩展性。

深入探讨分布式存储系统的关键组件,包括元数据管理、数据分布策略、负载均衡和容错机制等,并分析这些组件如何协同工作以保障数据的可靠存储和高效访问。

高可用、高可靠微服务架构实践:7大顶级设计思维模型

高可用、高可靠微服务架构实践:7大顶级设计思维模型

高可用、高可靠微服务架构实践:7大顶级设计思维模型如果把单体比作军舰的话,那么微服务可以称得上是航空母舰,中型企业及大厂纷纷登上这艘舰,创造了一个又一个高光时刻。

随着业务规模扩大,微服务可以解决单体应用膨胀、团队开发耦合度高、协作效率低下等等问题。

服务拆分粒度更细。

微服务可以说是更细维度的服务化,小到一个子模块,只要该模块依赖的资源与其他模块都没有关系,那么就可以拆分为一个微服务。

服务独立部署。

每个微服务都严格遵循独立打包部署的准则,互不影响。

比如一台物理机上可以部署多个Docker实例,每个Docker 实例可以部署一个微服务的代码。

服务独立维护。

每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维,并对整个生命周期负责。

基于此微服务成为主流架构,也成为高薪技术人员必备技术栈。

但我们为微服务欢呼雀跃的同时,也总能听到身边的兄弟骂骂咧咧。

当然,微服务不是十全十美的。

1、服务治理能力要求高因为拆分为微服务之后,服务的数量变多,因此需要有统一的服务治理平台,来对各个服务进行管理。

2、复杂度高微服务间通过REST、RPC等形式交互,相对于Monolithic模式下的API形式,需要考虑被调用方故障、过载、消息丢失等各种异常情况,代码逻辑更加复杂。

3、性能问题相对于Monolithic架构,微服务的间通过REST、RPC等形式进行交互,通信的时延会受到较大的影响。

虽然这些问题需要我们解决,但有1点需要明确,这不是微服务的锅,而是规划和架构设计不到位的锅。

这的确是一个庞杂的系统性问题,曾经和玄姐(前58集团技术委员会主席、阿里云MVP、腾讯云TVP)探讨过关于微服务架构设计的思维模型,收获颇多。

作为百万年薪架构师的顶级思维模型之一:根据(业务)场景Balance的架构设计思维模型。

BAT超一线大厂架构设计固然优秀,但照搬拷贝就变得很可笑。

身为一名顶级架构师,你需要根据所处公司的业务特点、请求并发、数据规模等场景给出灵活优雅的架构设计解决方案,满足公司未来6个月到2年的业务发展需求。

如何构建高可用的容器化应用运维体系

如何构建高可用的容器化应用运维体系

如何构建高可用的容器化应用运维体系在当今数字化时代,容器化技术的应用日益广泛,为企业带来了高效、灵活和可扩展的优势。

然而,要确保容器化应用的稳定运行和高可用性,构建一个完善的运维体系至关重要。

下面我们将探讨如何构建这样一个体系。

一、理解容器化技术的基础首先,我们需要深入了解容器化技术的基本原理。

容器是一种轻量级的虚拟化技术,它将应用及其依赖项打包到一个可移植的单元中。

与传统的虚拟机相比,容器启动速度更快,资源利用率更高。

常见的容器技术如 Docker 和 Kubernetes 为容器的管理和编排提供了强大的支持。

二、基础设施的准备(一)选择合适的云服务提供商或自建数据中心如果选择云服务,要考虑其稳定性、性能、成本以及与容器技术的兼容性。

如果自建数据中心,需要确保硬件设施的可靠性和可扩展性。

(二)网络架构的优化构建高速、低延迟、高可靠的网络环境,以支持容器之间的通信和数据传输。

合理规划子网、VLAN 和防火墙规则,保障网络安全。

(三)存储方案的确定根据应用的需求选择合适的存储类型,如块存储、文件存储或对象存储。

同时,要考虑数据的备份和恢复策略。

三、容器平台的选型与部署(一)评估不同的容器平台如 Kubernetes、Docker Swarm 等,比较它们的功能、易用性、社区支持和扩展性。

(二)正确部署容器平台遵循最佳实践进行安装和配置,包括设置节点、集群、资源配额等。

确保平台的高可用性,例如通过部署多个控制平面节点和工作节点。

四、监控与告警系统的建立(一)指标收集监控容器的 CPU、内存、网络 I/O、磁盘 I/O 等关键指标,以及应用的性能指标,如响应时间、吞吐量等。

(二)可视化展示通过直观的图表和仪表盘展示监控数据,便于快速发现问题。

(三)告警设置设定合理的阈值,当指标超过阈值时及时发送告警通知,通知方式可以包括邮件、短信、即时通讯工具等。

五、自动化部署与更新(一)持续集成/持续部署(CI/CD)流程实现代码的自动构建、测试和部署到容器环境中,确保应用的快速迭代和更新。

数据库的高可用测试方案-概述说明以及解释

数据库的高可用测试方案-概述说明以及解释

数据库的高可用测试方案-概述说明以及解释1.引言1.1 概述概述:数据库的高可用性是指数据库系统在面临各种故障或异常情况时依然能够保持正常运行,提供可靠的数据访问和服务。

对于企业和组织来说,数据库的高可用性是确保业务连续运行的关键要素之一。

因此,针对数据库的高可用性进行测试和评估具有重要意义。

数据库的高可用性测试主要通过模拟各种故障情况和极限负载条件来验证数据库系统的稳定性、可靠性以及容灾能力。

通过高可用性测试,可以发现数据库系统在复杂环境下的弱点和瓶颈,并采取相应的措施进行优化和改进,从而提升数据库的可用性和可靠性。

本文将重点讨论数据库的高可用性测试方案。

首先,我们将介绍高可用性的概念和意义,阐述为什么数据库的高可用性对企业和组织至关重要。

然后,我们将详细讨论数据库的高可用性测试方法,包括常见的测试手段和技术。

最后,我们将重点介绍高可用性测试方案的设计与实施,从测试计划制定、测试环境搭建到测试案例设计和执行等方面进行深入探讨。

通过撰写这篇文章,旨在为读者提供一个全面了解数据库高可用性测试的指导,帮助他们更好地理解和应用高可用性测试方案。

同时,本文也为数据库系统的开发和运维人员提供了一些有益的经验和建议,以提升数据库系统的可用性和可靠性,确保数据的安全和稳定。

让我们一起深入探究数据库的高可用性测试方案,为企业和组织的数据服务保驾护航。

1.2 文章结构:本文主要围绕数据库的高可用性测试方案展开,分为引言、正文和结论三个部分。

在引言部分,我们将对高可用性的概念进行概述,介绍高可用性在数据库领域的重要意义,并明确本文的目的。

正文部分将在2.1节对高可用性的概念和意义进行详细阐述,包括对高可用性的定义和其对数据库系统稳定性和可靠性的影响等方面的探讨。

紧接着,在2.2节,我们将介绍数据库的高可用性测试方法。

这部分将涵盖常见的数据库高可用性测试手段,包括主备复制、双机热备、双机热备加异地灾备等,以及测试时需要考虑的因素和常见的测试指标。

云计算平台的高可用性和扩展性

云计算平台的高可用性和扩展性

云计算平台的高可用性和扩展性随着时代的发展,云计算成为了更多企业在进行IT现代化转型过程中的必备工具。

与传统的本地计算架构不同,云计算所具备的高可用性和扩展性能够大幅度提升业务的稳定性和容量,为企业带来更好的效益和竞争力。

首先,我们需要理解什么是高可用性和扩展性。

高可用性指的是系统在遇到故障或者一些不可预期的情况下,依然能够保持稳定运行的能力。

相对于时下流行的“五个九”技术目标,即达到99.999%的可靠性,高可用性的含义更广,包括但不限于硬件故障、网络中断、威胁攻击等情况下,依旧能够保证系统的稳定工作。

在云计算平台中,因为整个系统架构会涉及到多种服务,所以确保高可用性就意味着这个系统会有多套备份,以达到更可靠的恢复机制。

与此同时,扩展性则是指在遇到业务量的上升或者需要增加更多功能的情况下,系统可以自适应地扩展出更多的处理能力和资源,保证足够的容量来支撑业务增长。

在云计算的架构下,各种不同的应用、服务、接口都是可以横向扩展的,碰到需要处理的工作量变大的情况,可以通过自动增加计算资源、分散流量,或者增加服务器数量来实现。

在实现高可用性和扩展性的过程中,云计算平台采用的技术主要包括虚拟化、容器化、负载均衡等,下面我们逐一探究。

虚拟化是实现云计算平台高可用性和扩展性的关键技术之一。

通过该技术,将多个物理计算机合成一个巨型物理计算机,从而实现虚拟机的热迁移,而大大增加了系统的运行时可靠性、弹性和灵活性。

虚拟化技术不仅可以实现物理主机的高可用性,还可以实现虚拟机的高可用性,从而提供了更完善的解决方案,保证了整个云计算平台的稳定性。

容器化也是实现高可用性和扩展性的一项重要技术,它可以将应用及其依赖项打包成一个可移植的容器,从而可以部署到多台服务器上,同时,由于容器之间相互隔离,因此可以大幅度减少应用之间的干扰,从而加速系统的响应速度。

在容器化的系统下,从单个机器到大型集群,都可以方便快捷地管理内存、CPU、网络、存储等计算资源。

如何构建高可用和弹性的系统架构

如何构建高可用和弹性的系统架构在当今信息时代,系统架构的高可用性和弹性成为了企业和组织追求的目标。

高可用性指系统能够持续地提供服务,即使在面临故障或异常情况下也能保持正常运行;而弹性则指系统能够根据负载的变化自动扩展或缩减资源,以满足用户需求。

构建高可用和弹性的系统架构是一个复杂而关键的任务,下面将从几个方面进行探讨。

1. 分布式架构分布式架构是构建高可用和弹性系统的基础。

通过将系统拆分为多个独立的模块和服务,可以实现负载均衡和故障隔离。

同时,分布式架构也可以提供更好的可扩展性和性能。

例如,可以将系统拆分为多个微服务,每个微服务独立运行,通过消息队列或RPC进行通信,从而实现系统的高可用和弹性。

2. 容错设计容错设计是确保系统高可用性的关键。

通过引入冗余和备份机制,可以在单点故障发生时保持系统的正常运行。

例如,可以使用主备模式,当主节点发生故障时,备份节点会自动接管服务。

此外,还可以使用数据备份和数据冗余技术,确保数据的可靠性和完整性。

3. 自动化运维自动化运维是提高系统弹性的重要手段。

通过自动化部署、监控和扩缩容等操作,可以快速响应负载的变化,保证系统的稳定性和可用性。

例如,可以使用自动化部署工具如Docker和Kubernetes,实现快速部署和弹性扩缩容。

同时,还可以使用监控和告警系统,及时发现和解决潜在的故障。

4. 异地多活异地多活是提高系统高可用性的重要策略。

通过在不同地理位置部署系统的副本,可以在某一地区发生故障时,自动切换到其他地区的副本,保证系统的连续性和可用性。

例如,可以将系统部署在多个数据中心,通过负载均衡和故障切换机制,实现异地多活。

5. 容量规划容量规划是确保系统弹性的关键。

通过对系统负载和资源使用情况进行分析和预测,可以合理规划系统的容量,避免资源瓶颈和性能问题。

例如,可以使用性能测试工具和监控系统,收集系统的性能数据,并进行分析和预测,以确定系统的扩容和优化策略。

6. 容错测试容错测试是验证系统高可用性和弹性的重要手段。

高可用性架构设计

高可用性架构设计一、引言在当今的信息时代,对于系统的高可用性需求越来越高。

无论是企业的业务系统还是互联网的应用程序,都需要在面对各种故障和意外情况时保证系统的持续可用性。

本文将针对高可用性架构设计进行探讨,介绍常见的架构模式及其特点,并提出一些设计原则和最佳实践。

二、高可用性架构模式1. 负载均衡负载均衡是保证高可用性的基础。

通过将用户请求分发到多个服务器上,均衡系统的负载,提高系统的性能和可用性。

常见的负载均衡算法有轮询、随机和基于权重的算法。

2. 冗余备份冗余备份是通过复制系统的各个组件,确保系统在某个组件出现故障时可以无缝切换到备份组件,实现故障的快速恢复。

冗余备份可以应用在数据库、存储系统、网络设备等方面。

3. 容灾设计容灾设计是为了应对自然灾害、人为故障或其他灾难性事件而制定的一套应急计划。

通过将系统的不同组件部署在不同的地理位置或数据中心,确保即使出现灾难,系统仍能保持可用。

4. 无单点故障单点故障是指系统中存在一个关键组件,一旦该组件出现故障,整个系统将无法正常工作。

为了避免单点故障,需要将关键组件进行冗余设计,保证在某个组件故障时,系统能够自动切换到备用组件。

5. 异地多活异地多活是指将系统的不同实例部署在不同地理位置,实现跨地域的实时数据同步和故障切换。

通过异地多活架构,可以提高系统的容错能力和灾难恢复能力。

三、高可用性架构设计原则1. 设计要素模块化:将系统拆分为多个独立的模块,降低模块间的依赖性,提高系统的可扩展性和可维护性。

2. 引入冗余机制:在关键组件上引入冗余备份,保证系统在故障发生时的快速切换和恢复。

3. 多样化的故障恢复策略:系统应该具备多种故障恢复策略,包括自动切换、手动干预、数据回滚等方式。

4. 监控和告警:系统应该具备完善的监控系统,及时检测和预警异常情况,可以帮助运维人员快速响应并修复故障。

5. 定期测试和演练:对高可用性架构进行定期测试和演练,包括模拟故障、灾难恢复演练等,以验证系统的可用性和可恢复性。

海量并发下高可用库存中心的设计与实现

海量并发下高可用库存中心的设计与实现在海量并发下实现高可用的库存中心的设计至关重要,这可以确保系统能够稳定地处理大量的库存操作请求,并保证数据的准确性和一致性。

下面是一个可能的设计与实现方案:一、基础架构设计:1.库存中心采用分布式架构,包括多个库存节点,每个节点负责一部分库存数据的管理和处理。

2.使用主从复制的方式保证库存数据的可靠性和高可用性,每个节点都可以接收读操作请求,而写操作只能由主节点处理。

3.引入负载均衡的机制,将请求均匀地分发到各个库存节点,提高系统的吞吐量和并发处理能力。

二、一致性设计:1.引入分布式事务处理机制,确保库存操作的一致性。

通过如分布式锁、分布式事务协调器等技术来实现。

2.库存中心记录每次操作的流水日志,并定期对所有库存节点的数据进行校验和同步,以保证数据的准确性和一致性。

三、高可用性设计:1.使用可插拔式组件,将库存中心与外部系统解耦,以避免单点故障的问题。

2.设置监控系统和告警机制,及时发现和修复系统的故障,提高系统的可用性。

3.使用集群和冗余机制,确保系统在节点故障时仍能正常运行,同时要有自动重启和故障转移的机制。

四、性能优化设计:1.使用内存缓存技术,将热点数据保存在内存中,提高读写操作的性能。

2.利用异步处理和批处理机制,将一些耗时的操作异步化,并以批量方式执行,提高系统的吞吐量和并发能力。

3.优化数据库设计和索引,减少库存查询和更新的耗时,提高数据库的读写性能。

五、故障恢复设计:1.定期备份库存数据,以便在系统故障时能够及时恢复。

2.设计有效的灾难恢复机制,确保在灾难性事件发生时,能够快速将系统恢复到正常运行状态。

六、安全性设计:1.引入身份认证和权限控制机制,保护库存中心免受未经授权的访问和操作。

2.使用加密技术,保护库存数据在传输和存储过程中的安全性。

3.建立日志系统,记录所有的操作记录,以便进行安全审计和追踪。

总结:以上是一个可能的海量并发下高可用库存中心设计与实现的方案。

数据库的高可用性架构与故障恢复

数据库的高可用性架构与故障恢复随着计算机技术的不断进步,数据库已经成为现代社会中重要的数据存储和处理工具之一。

在大型企业和组织中,数据库的高可用性架构和故障恢复是确保业务连续性和数据完整性的重要组成部分。

本文将探讨数据库的高可用性架构和故障恢复的一些关键概念和方法。

首先,我们需要理解高可用性架构的概念。

高可用性是指在面对硬件、软件或网络故障时,系统仍然能够继续运行并提供服务。

数据库的高可用性架构旨在确保数据库系统在故障发生时能够快速恢复并保持数据的连续性。

为达到这一目标,常见的架构模式包括备份和恢复、主从复制和集群。

备份和恢复是数据库高可用性架构中最常见的一种方式。

它通过定期备份数据库,并在发生故障时恢复备份文件以恢复数据完整性。

备份可以以全量备份或增量备份的方式进行,全量备份是指备份整个数据库,而增量备份则是只备份发生变更的部分。

通过组合使用不同类型的备份,可以保证不同程度的数据丢失。

另一种常见的高可用性架构是主从复制。

主从复制是通过建立一个主数据库和一个或多个从数据库的关系。

主数据库负责处理读写操作,而从数据库则复制主数据库的数据,只处理读操作。

当主数据库发生故障时,从数据库可以接管并提供服务,实现快速故障恢复。

主从复制还可以用于水平扩展,通过增加从数据库来提高处理能力。

除备份和恢复和主从复制外,还有一种被广泛采用的高可用性架构是集群。

集群是指通过多个服务器(节点)组成的系统,这些节点共享相同的硬件和软件配置,并提供相同的数据库服务。

集群通过分布数据和计算负载来提供高可用性和扩展性。

常见的集群技术包括主备集群和主主集群。

主备集群是指在多个节点中,只有一个节点处于活动状态,其他节点处于待命状态,一旦活动节点失败,待命节点可以快速接管。

主主集群则是所有节点都处于活动状态,数据进行双向同步,提供更好的性能和数据一致性。

当数据库发生故障时,快速恢复数据是至关重要的。

数据库的故障恢复可以通过以下步骤来实现。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

简朝阳:高可用可扩展数据库架构
2010年04月15日00:27 IT168网站原创作者:IT168 溺水的鱼编辑:覃里评论:0条
本文Tag:IT业界MySQL达梦数据库
【IT168 评论】近期,DTCC 2010数据库技术大会在北京歌华开元大酒店盛大召开。

来自于全国各地包括宝岛台湾的700多位数据库及相关技术从业者参加了本次大会。

2天的大会,29场演讲,内容涵盖了Oracle,MySQL,DB2,SQL Server ,Sybase,达梦(国产数据库) 等多种数据库。

阿里巴巴MySQL数据库主管简朝阳
4月3日上午的开源数据库实践应用案例专场,来自阿里巴巴的MySQL数据库主管简朝阳给我们介绍了很多MySQL的应用架构,灵活的MySQL,就是为web2.0而存在。

简朝阳演讲主题“高可用可扩展数据库架构”主要从数据库的高可用和可扩展两个方面来进行了分享探讨。

高可用
软/硬件高可用(热/冷备)
数据高可用(共享,同/异步复制)
单独的硬件高可用除了冗余之外本身没有太多可以讲的,所以简朝阳一笔带过。

基于共享设备的数据高可用只是大概的介绍了可能的方案,由于各方案的实施都比较昂贵,更适合于Oracle,DB2等。

高可用架构图(部分)
高可用部分简朝阳重点介绍了利用MySQL 的Replication技术和应用程序的共同配合来实现Share Nothing 方式的高可用。

可扩展
向上扩展(Scale Up)
硬件扩容(增加CPU数量,增加内存容量,增加磁盘数量…)
硬件升级(更换更高端的主机,更换更高端的粗出设备,更换更高端CPU,更换转速更快的磁盘…)
向外扩展(Scale Out)
数据拷贝分发(一处写入多处读取,读写分离…)
数据垂直/水平切分(功能模块切分(vertical sharding),水平分片切分(horizontal sharding),两者综合)
Cache 和 Search(应用程序更新Cache,数据库更新 Cache,利用Search 全文搜索…)
扩展性简朝阳重点介绍的是Sharding过程中如何选择合适的Sharding方法,如何解决Sharding之后的数据合并问题,以及如何利用数据库外部资源(Cache,Search)来解决数据层的扩展性问题。

高扩展架构图(部分)
简朝阳表示:“其实架构这个东西本身就是仁者见仁智者见智,没有万能的架构,也没有长久适用的架构。

架构和业务场景息息相关密不可分,离开了实际业务场景谈架构,可以说就是纸上谈兵,那如果离开了架构仅仅追求快速的业务实现呢?出来混,迟早要还的。


相关PPT下载: /thread-1287920-1-1.html。

相关文档
最新文档