版权声明
- 本博客的内容基于我个人学习黑马程序员课程的学习笔记整理而成。我特此声明,所有版权属于黑马程序员或相关权利人所有。本博客的目的仅为个人学习和交流之用,并非商业用途。
- 我在整理学习笔记的过程中尽力确保准确性,但无法保证内容的完整性和时效性。本博客的内容可能会随着时间的推移而过时或需要更新。
- 若您是黑马程序员或相关权利人,如有任何侵犯版权的地方,请您及时联系我,我将立即予以删除或进行必要的修改。
- 对于其他读者,请在阅读本博客内容时保持遵守相关法律法规和道德准则,谨慎参考,并自行承担因此产生的风险和责任。
- 本博客中的部分观点和意见仅代表我个人,不代表黑马程序员的立场。
业务架构
单体模式
-
早期系统以单体业务为主,逐个业务线扩张,呈现为多个独立运行状态的 MVC(Model-View-Controller)架构。每个业务线可能对应着不同的系统,例如在电商领域可能包括 B2B(Business-to-Business)、B2C(Business-to-Consumer)、C2C(Consumer-to-Consumer)等业务模式。每个业务线都有自己独立的系统,而每个系统又有各自的维护团队。
-
每个系统专注于处理特定业务领域,团队之间相对独立,有利于快速开发和迭代。然而,随着业务的不断扩张,这种架构也会带来一些挑战和问题。
中台战略
- 中台在2015由阿⾥提出,其实是阿⾥共享业务技术部的成型过程。
- 中台战略是一种企业管理和技术架构的策略,是“共享”理念在业务、系统、组织架构上的⼀种落地与实施。
- 中台战略的核心理念是将业务系统划分为前台和中台两个部分,分别负责不同的职责,以实现业务的快速创新和稳健运营。
- 前台和中台: 中台战略将业务系统划分为前台和中台两个部分。前台主要关注用户体验、业务创新和客户交互,而中台则专注于业务逻辑、数据管理和基础设施。
- 前台特点: 前台是用户直接接触的部分,包括用户界面、交互设计、产品功能等。前台需要灵活、创新,能够迅速响应市场需求和用户反馈。
- 中台特点: 中台是业务逻辑和数据管理的核心,包括业务规则、数据模型、服务等。中台的设计追求通用性、标准化,以提供支持各业务线的共享服务。
- 服务化架构: 中台战略通常采用服务化架构,将业务拆分为独立的服务。这些服务可以被不同的业务线共享,实现业务功能的复用和标准化。
- 数据驱动: 中台强调数据的重要性,通过建设统一的数据管理平台,实现数据的集中管理和共享。这有助于提高数据质量、降低数据冗余,同时为业务智能决策提供支持。
- 敏捷开发和创新: 中台战略通过解耦前台和中台,使得业务线能够更加独立地进行敏捷开发。前台可以快速响应市场变化,而中台提供的服务则为业务线提供了基础设施和支持。
- 平台化思维: 中台战略鼓励企业以平台化思维进行运营,将中台打造成一个支持多业务线、多渠道的基础设施平台,实现资源共享和协同创新。
- 中台战略的实施有助于解决传统单体架构下的业务发展难题,提高企业对市场变化的适应能力。然而,中台建设也面临一些挑战,包括组织文化的转变、技术架构的升级和对人才的需求等。成功实施中台战略需要企业在战略层面、组织层面和技术层面都进行全面的转型。
中台战略下:
-
中台模式下,基础业务也下沉到技术部⻔,甚⾄通过技术反推业务正向发展。下层业务,变化不⼤的业务持续沉淀,接⼝像滚雪球⼀样越来越完善。上层业务,跟业务模式和运营产品有关的系统变化迅速,对底层接⼝封装组合即可
-
通俗讲,中台模式就好比一个多层次的蛋糕,中间是中台,比如技术部门,负责处理一些基础的业务和技术工作。在这个模式下,基础业务被下沉到技术部门,甚至通过技术手段来推动业务的发展。底层的业务就像是一些变化不大的东西,一直在那里不断积累和改进,就像雪球越滚越大。而在上层,与业务模式和运营产品有关的系统变化很快,但它们只需要封装和组合底层的接口,就能够迅速适应不同的业务需求。
- 业务中台
- 技术中台
- 数据中台
- 服务接入层
去中台化
- 简化架构:中台化架构过于复杂或不适用于其特定业务需求。因此,简化整个架构,减少中间层次和组件,使系统更加扁平化,以提高灵活性和效率。
- 业务焦点重置: 中台化过程中,可能导致减少对业务的关注。去中台化可以使企业重新聚焦于业务需求,将更多精力放在满足客户需求和提高业务价值上。
- 个性化服务和定制化需求: 部分行业或业务领域可能更需要个性化的服务或定制化的解决方案。去中台化可以使企业更专注于满足特定客户群体的需求,而不是过度依赖于中央化的服务和解决方案。
数据架构
单数据库架构
主要特点包括:
- 集中管理: 所有数据都存储在一个数据库中,方便集中管理和维护。
- 简单: 单数据库架构相对来说比较简单,搭建和维护成本相对较低。
- 事务一致性: 由于只有一个数据库,事务管理相对较为简单,确保了数据的一致性。
- 易于备份和恢复: 数据库备份和恢复相对容易,因为只需处理一个数据库。
单数据库架构的缺点:
- 性能瓶颈: 数据库的读写负载瓶颈,导致性能下降。
- 可扩展性有限: 单数据库的可扩展性有限,无法以应对更多用户或更大的数据量。
- 单点故障: 单数据库是系统的单一数据存储点,一旦发生数据库故障,整个系统可能受到严重影响。
- 复杂查询影响性能: 复杂查询可能影响数据库的性能,尤其在大规模数据集上执行复杂的联合查询。
- 难以应对多样化需求: 单数据库架构可能无法灵活应对不同类型的数据存储需求。
主从读写
-
从服务器(Slave):
-
读写分离:
优势:
优势 | 详细说明 |
---|---|
读性能提升 | 通过将读操作分发到从服务器,有效减轻主服务器的读取负载,提高整个系统的读取性能。 |
容错和高可用性 | 当主服务器发生故障时,从服务器可以接替主服务器的角色,确保系统的高可用性和容错能力。 |
数据备份和恢复 | 从服务器可以作为主服务器的备份,当主服务器数据丢失或损坏时,可以通过从服务器进行数据恢复。 |
读写分离 | 有效分离读写操作,提高系统的整体性能和响应速度。 |
资源有效利用 | 主从服务器分工明确,可以充分利用硬件资源,提高系统整体的效率。 |
延迟可接受 | 尽管存在一定的同步延迟,但对于对实时性要求不是非常高的应用,这种延迟是可以接受的。 |
劣势:
劣势 | 详细说明 |
---|---|
写性能瓶颈 | 主服务器负责所有写操作,可能成为系统的写性能瓶颈,特别是在高写入负载的情况下。 |
同步延迟 | 由于从服务器需要定期同步主服务器的数据,可能存在一定的同步延迟,对于某些实时性要求极高的应用可能不够理想。 |
配置和管理复杂 | 主从读写架构需要进行配置和管理,确保主从服务器之间的数据同步正常,以及故障切换的机制得以正确配置。 |
一致性难保证 | 在主从同步的过程中,如果主服务器和从服务器之间的网络发生故障,可能会导致数据同步不一致的问题。 |
数据安全风险 | 从服务器可能成为攻击目标,需要采取额外的安全措施来保护数据的安全性。 |
可扩展性限制 | 对于某些需要极高可扩展性的应用,主从读写架构的扩展性可能受到一定限制,需要考虑其他更为分布式的数据库架构。 |
主从读写架构在提高系统读性能、容错和高可用性方面有很大优势,但也存在一些劣势,特别是在写入负载较高、对实时性要求很高、配置和管理要求复杂等方面。在选择数据库架构时,需要根据具体的业务需求和系统特点进行权衡。
注意,**主从读写架构对于提高读取性能是有效的,但对于写操作的性能提升并不明显。**在高写入负载的情况下,还可能存在主服务器的性能瓶颈。
分库分表
- 分库分表是一种常见的数据库架构设计,用于解决大规模应用中单一数据库的性能瓶颈问题。这种架构将数据库按照一定规则划分成多个库(Database)和表(Table),以提高系统的扩展性和性能。例如:主从库的写⼊依然是有⼀个统⼀的主库⼊⼝。随着业务量的提升,继续细粒度化拆分。
- 分库:不同的数据库,所以⽆法使⽤数据库事务,⽽分布式事务的效果并不理想,多采⽤幂等和最终⼀致性⽅案。分表:拆了再聚合是⼀对⽭盾,例如按下单时间维度的分表,需要按⽤户排序统计变得异常困难。中间件:Sharding-JDBC,Mycat,Atlas
- 分库分表是一种在大规模数据应用中解决性能瓶颈问题的有效手段,但也需要在复杂性和管理成本之间进行权衡,根据具体的业务需求和数据特征做出明智的选择。
高速缓存
数据多样化
分布式文件
nosql
搜索引擎
共同点
- Lucene是搜索引擎的核心库,而Solr和Elasticsearch是构建在Lucene之上的应用。
- Solr和Elasticsearch都提供了方便的HTTP接口,使得它们易于集成到各种应用中。
- Solr和Elasticsearch都支持分布式架构,可以水平扩展以处理大规模的数据和请求。
区别
架构特点
- 开发框架⽀持:存储的数据多样化,要求开发框架架构层⾯要提供多样化的⽀撑,并确保访问易⽤性
- 数据运维:多种数据服务器对运维的要求提升,机器的数据维护与灾备⼯作量加⼤
- 数据安全:多种数据存储的权限,授权与访问隔离需要注意
应用架构
单机调优
- 早年间的项⽬⼤多采⽤mvc开发
- 每个项⽬成⼀个mvc结构,部署在应⽤服务器上(tomcat、jboss、websphere,weblogic)。
- 随着业务扩张,需求迭代,项⽬变得越来越⼤,⼀个war包动辄几百兆。
动静分离
SOA
-
公共服务:重复开发的基础服务提取出来,形成服务中心,避免重复造轮⼦,降低成本,架构团队出现。
-
独立性:各⾃服务独⽴部署升级,粒度更细,低耦合,高内聚
-
SOA理念诞⽣:服务治理的范畴,重在服务之间的拆分与统⼀接口。SOA(Service-Oriented Architecture,面向服务的架构)是一种软件设计和架构风格,其主要思想是通过将软件系统划分为独立且松散耦合的服务单元,这些服务单元通过标准化的协议进行通信,从而实现应用程序的构建和整合。
-
技术⼿段
微服务
-
微服务是基于SOA思想,将系统粒度进⼀步细化而诞⽣的⼀种手段。中台化得以实现,各个中⼼以及前端业务拆解为多个小的服务单元
-
微服务经历了从1.0(cloud)到2.0的演化(service mesh),目前企业中主流的解决⽅案依然是cloud全家桶Spring Cloud Spring Cloud微服务前沿技术栈,Spring、Spring Boot。
-
服务拆分:粒度并非越小越好,太小会增加维护成本。
部署架构
单机部署
⻆⾊划分
- 稍微⼤⼀点的系统,把数据库、缓存、消息等中间件剥离出去,单独机器来部署
- 多台机器:tomcat与mysql各⾃独占机器资源
- 针对性扩容:tomcat应⽤机更注重cpu的运算和内存,mysql更注重io与磁盘性能,针对各⾃情况扩容
- 数据维护:可以抽出单独的dba来维护数据库服务器
- 数据安全:需要跨机器访问数据库,链接密码需要注意防范泄漏
应⽤集群
多层代理
异地访问
- 将相同的系统部署多份,分散到异地多个机房,或者电信、移动等多个⽹络中。不同地点,不同⽹络接⼊的⽤户,有了不同的访问⼊⼝和选择。
- dns轮询:通过配置多个ip将服务部署到多个机房,通过dns的策略轮询调⽤,可以实现机房层⾯的扩容
- CDN:就近原则,使⽤户获得就近的机房访问相关资源,投资太⼤,购买他⽅需要付费
- 基本解决了机器部署的扩容问题,随着业务的发展,扩容与收缩变得困难,促进资源调度层⾯的技术发展
云平台
-
针对中台化的建设及微服务数量的飙升,部署和运维⽀撑同步进⾏着变⾰。⾯临微服务的快速部署,资源的弹性伸缩等挑战,容器化与云被推进。
-
运维要求:需要运维层⾯的⾼度⽀撑,⻔槛⽐较⾼
-
预估⻛险:云瘫痪的故障造成的损失不可估量
架构思想总结
- 知行合一,确保技术决策与业务目标紧密一致
- 在构建技术架构之前,首先要理解业务需求和问题的实质。技术应该服务于业务目标,而不是为了技术而技术
- 原生优于定制,约定大于配
- 尽量使用原生(标准)的解决方案,而不是进行过多的定制。同时,通过共识和约定来减少配置的复杂性
- 控制技术欲,不要瞎折腾
- 不要过度追求新技术,避免为了使用新技术而不加思考地改变架构。技术选型应该基于实际需求和业务场景,而非盲目跟风。
- 留下扩展,,但要避免过度设计和过度优化。
- 没有最好的,只有最合适的
- 没有一种通用的、适用于所有场景的最佳解决方案。技术选择应该基于具体的需求、团队的技术栈和经验,以及系统的特定要求
- 够用就好,玩的越花,风险越大
- 在技术决策上要保持实用主义,选择足够满足需求的方案,避免过度投入。
- 简约最美
原文地址:https://blog.csdn.net/yang2330648064/article/details/134671635
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_4355.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!