互联网架构演变过程梳理和架构思想的学习

文章目录

  • 版权声明
  • 业务架构
    • 单体模式
    • 中台战略
    • 去中台化
  • 数据架构
    • 单数据库架构
    • 主从读写
    • 分库分表
    • 高速缓存
    • 数据多样化
      • 分布式文件
      • nosql
      • 搜索引擎
      • 架构特点
  • 应用架构
    • 单机调优
    • 动静分离
    • SOA
    • 微服务
  • 部署架构
    • 单机部署
    • ⻆⾊划分
    • 应⽤集群
    • 多层代理
    • 异地访问
    • 云平台
  • 架构思想总结

在这里插入图片描述

版权声明

  • 本博客的内容基于我个人学习黑马程序员课程的学习笔记整理而成。我特此声明,所有版权属于黑马程序员或相关权利人所有。本博客的目的仅为个人学习和交流之用,并非商业用途。
  • 我在整理学习笔记的过程中尽力确保准确性,但无法保证内容的完整性和时效性。本博客的内容可能会随着时间的推移而过时或需要更新。
  • 若您是黑马程序员或相关权利人,如有任何侵犯版权的地方,请您及时联系我,我将立即予以删除或进行必要的修改。
  • 对于其他读者,请在阅读本博客内容时保持遵守相关法律法规和道德准则,谨慎参考,并自行承担因此产生的风险和责任。
  • 本博客中的部分观点和意见仅代表我个人,不代表黑马程序员的立场。

业务架构

单体模式

  • 早期系统以单体业务为主,逐个业务线扩张,呈现为多个独立运行状态的 MVC(Model-View-Controller)架构。每个业务线可能对应着不同的系统,例如在电商领域可能包括 B2B(Business-to-Business)、B2C(Business-to-Consumer)、C2C(Consumer-to-Consumer)等业务模式。每个业务线都有自己独立的系统,而每个系统又有各自的维护团队。
    在这里插入图片描述

  • ⽅案:代理层设置不同的⼆级域名,如b2b.abc.com,b2c.abc.com,分发给不同的服务器

  • 每个系统专注于处理特定业务领域,团队之间相对独立,有利于快速开发和迭代。然而,随着业务的不断扩张,这种架构也会带来一些挑战和问题。

    • 复杂性增加: 随着业务的发展,系统的复杂性逐渐增加。每个业务线的系统可能有重复的功能,但由于独立开发,这些功能可能以不同的方式实现,导致了代码冗余和维护困难。

    • 协同问题: 不同团队之间可能存在协同问题。当一个业务涉及多个系统时,需要确保它们能够有效地协同工作,而这可能需要更复杂的集成和通信机制。

    • 难以扩展: 在这种架构下,随着业务的不断扩张,添加新的功能或业务线可能会变得更加困难。新的需求可能需要修改多个系统,增加了开发和测试的工作量。

  • 存在的问题:功能重复、数据不互通

中台战略

  • 中台在2015由阿⾥提出,其实是阿⾥共享业务技术部的成型过程。
  • 中台战略是一种企业管理和技术架构的策略,是“共享”理念在业务、系统、组织架构上的⼀种落地与实施。
  • 中台战略的核心理念是将业务系统划分为前台和中台两个部分,分别负责不同的职责,以实现业务的快速创新和稳健运营。
  1. 前台和中台: 中台战略将业务系统划分为前台和中台两个部分前台主要关注用户体验、业务创新和客户交互,而中台则专注于业务逻辑、数据管理和基础设施。
  2. 前台特点: 前台是用户直接接触的部分,包括用户界面、交互设计、产品功能等。前台需要灵活、创新,能够迅速响应市场需求和用户反馈。
  3. 中台特点: 中台是业务逻辑和数据管理的核心,包括业务规则、数据模型、服务等。中台的设计追求通用性、标准化,以提供支持各业务线的共享服务。
  4. 服务化架构: 中台战略通常采用服务化架构,将业务拆分为独立的服务。这些服务可以被不同的业务线共享,实现业务功能的复用和标准化。
  5. 数据驱动: 中台强调数据的重要性,通过建设统一的数据管理平台,实现数据的集中管理和共享。这有助于提高数据质量、降低数据冗余,同时为业务智能决策提供支持。
  6. 敏捷开发和创新: 中台战略通过解耦前台和中台,使得业务线能够更加独立地进行敏捷开发。前台可以快速响应市场变化,而中台提供的服务则为业务线提供了基础设施和支持。
  7. 平台化思维: 中台战略鼓励企业以平台化思维进行运营,将中台打造成一个支持多业务线、多渠道的基础设施平台,实现资源共享和协同创新。
  • 中台战略的实施有助于解决传统单体架构下的业务发展难题,提高企业对市场变化的适应能力。然而,中台建设也面临一些挑战,包括组织文化的转变、技术架构的升级和对人才的需求等。成功实施中台战略需要企业在战略层面、组织层面和技术层面都进行全面的转型。

中台战略下:

  • 中台模式下,基础业务也下沉到技术部⻔,甚⾄通过技术反推业务正向发展。下层业务,变化不⼤的业务持续沉淀,接⼝像滚雪球⼀样越来越完善。上层业务,跟业务模式和运营产品有关的系统变化迅速,对底层接⼝封装组合即可

  • 通俗讲,中台模式就好比一个多层次的蛋糕,中间是中台,比如技术部门,负责处理一些基础的业务和技术工作。在这个模式下,基础业务被下沉到技术部门,甚至通过技术手段来推动业务的发展。底层的业务就像是一些变化不大的东西,一直在那里不断积累和改进,就像雪球越滚越大。而在上层,与业务模式和运营产品有关的系统变化很快,但它们只需要封装和组合底层的接口,就能够迅速适应不同的业务需求。
    在这里插入图片描述

  1. 业务中台
    • 业务中台基于公共服务的沉淀,需要积累⼀些基础的业务服务。它包括订单管理、支付服务、商品管理等业务功能的通用化和标准化。通过业务中台,不同的业务线可以共享这些通用功能,实现业务功能的复用,减少重复开发,提高效率。业务中台的建设旨在降低业务线之间的耦合度,使得每个业务线更加独立和灵活。
      • 商品中⼼:商品、类⽬、sku、spu
      • 交易中⼼:订单、状态流转、条⽬、⽀付
      • 营销中⼼:促销、优惠券、活动
      • 会员中⼼:账户、基本信息、收发货地址、商铺商家信息
      • 仓储中⼼:仓库、库存
      • 物流中⼼:发货信息、⾃主物流或外部物流对接
  2. 技术中台
    • ,。
    • 技术中台是电商系统中与业务⽆关的基础沉淀,包括基础服务、开发框架、运维工具等。它为业务中台和数据中台提供技术支持,技术类内容可以在各个团队之间共享,同时为整个系统提供一致的技术标准。
      • 基础架构:核⼼类库、公共框架、基础服务、服务治理框架
      • 中间件:分布式缓存、分布式消息、数据存储(,nosql)、分布式⽂件、分布式调度
      • ⾃动化运维:监控中⼼、资源管理、配置中⼼、发布中⼼、⽇志平台
      • ⾃动化测试:任务协同、基础测试、性能测试、接⼝测试、持续集成
  3. 数据中台
    • 数据中台是电商系统中负责数据管理的核心部分。它致力于构建一致性、高质量、可信赖的数据基础设施。通过数据中台,不同业务线可以共享数据,实现数据的集中管理和共享。这有助于提高数据的质量,减少数据冗余,支持数据驱动的决策。数据中台还为业务提供了数据治理、数据分析和挖掘的支持。
      • 数据抽取:从,nosql,⽇志等各个来源提供抽取接⼝
      • 数据接⼝:为上层业务提供需要的定制化业务数据接⼝
      • 数据分析:⾏业分析与决策、数据驱动运营
      • ⼈⼯智能:⽤户画像、商品推荐
      • 可视化:数据⼤屏、信息展示、活动报表等
  4. 服务接入层
    • 服务接入层是电商系统与外部服务或第三方服务进行交互的接口层。它可以是一组API(应用程序接口),也可以是其他形式的接口。服务接入层使得外部服务可以方便地接入电商系统,同时也为电商系统的不同业务线提供了接口访问。这有助于构建一个开放的生态系统,促进合作和创新。

去中台化

  • "去中台化"是企业从中台化架构转向更加扁平化或去中心化的组织结构或技术架构。它出现在企业经历了中台化转型后,发现需要调整或改变原先中台化架构的情况下。
  1. 简化架构:中台化架构过于复杂或不适用于其特定业务需求。因此,简化整个架构,减少中间层次和组件,使系统更加扁平化,以提高灵活性和效率。
  2. 业务焦点重置: 中台化过程中,可能导致减少对业务的关注。去中台化可以使企业重新聚焦于业务需求,将更多精力放在满足客户需求和提高业务价值上。
  3. 个性化服务和定制化需求: 部分行业或业务领域可能更需要个性化的服务或定制化的解决方案。去中台化可以使企业更专注于满足特定客户群体的需求,而不是过度依赖于中央化的服务和解决方案。
  • 注意:去中台化并不代表放弃所有中台化所带来的技术优势,而是可能更注重各业务之间的紧密整合和创新。企业可能会采用更灵活的技术架构,以更好地支持不同业务线的创新和发展。

数据架构

单数据库架构

  • 在单数据库架构中,整个系统使用一个单一的数据库来存储和管理所有的数据。这种架构形式相对简单,适用于小型和中型系统,尤其是对于一些规模较小的应用,如个人博客、小型企业管理系统等。
    在这里插入图片描述

主要特点包括:

  1. 集中管理: 所有数据都存储在一个数据库中,方便集中管理和维护。
  2. 简单: 单数据库架构相对来说比较简单,搭建和维护成本相对较低。
  3. 事务一致性: 由于只有一个数据库,事务管理相对较为简单,确保了数据的一致性。
  4. 易于备份和恢复: 数据库备份和恢复相对容易,因为只需处理一个数据库。

单数据库架构的缺点:

  1. 性能瓶颈: 数据库的读写负载瓶颈,导致性能下降。
  2. 可扩展性有限: 单数据库的可扩展性有限,无法以应对更多用户或更大的数据量。
  3. 单点故障: 单数据库是系统的单一数据存储点,一旦发生数据库故障,整个系统可能受到严重影响。
  4. 复杂查询影响性能: 复杂查询可能影响数据库的性能,尤其在大规模数据集上执行复杂的联合查询。
  5. 难以应对多样化需求: 单数据库架构可能无法灵活应对不同类型的数据存储需求。

主从读写

  • 主从读写是一种常见的数据库架构设计,它将数据库服务器分为主服务器(Master)和从服务器(Slave)。这种架构主要用于提高系统的读取性能和容错能力。
    在这里插入图片描述
  1. 主服务器(Master):

    • 主服务器负责处理所有的写操作(插入、更新、删除)。
    • 写操作将数据写入主数据库,并且主数据库负责同步更新到从服务器。
  2. 从服务器(Slave):

    • 从服务器主要用于处理读操作(查询)。
    • 从服务器定期从主服务器同步数据,以保持与主服务器的数据一致性。
  3. 读写分离:

    • 主从读写架构的主要优势在于读写分离。由于读操作通常比写操作频繁,通过将读操作分发到从服务器,可以有效减轻主服务器的读取负载,提高整个系统的读取性能。

优势:

优势详细说明
读性能提升通过将读操作分发到从服务器,有效减轻主服务器的读取负载,提高整个系统的读取性能。
容错和高可用性当主服务器发生故障时,从服务器可以接替主服务器的角色,确保系统的高可用性和容错能力。
数据备份和恢复从服务器可以作为主服务器的备份,当主服务器数据丢失或损坏时,可以通过从服务器进行数据恢复。
读写分离有效分离读写操作,提高系统的整体性能和响应速度。
资源有效利用主从服务器分工明确,可以充分利用硬件资源,提高系统整体的效率。
延迟可接受尽管存在一定的同步延迟,但对于对实时性要求不是非常高的应用,这种延迟是可以接受的。

劣势:

劣势详细说明
写性能瓶颈主服务器负责所有写操作,可能成为系统的写性能瓶颈,特别是在高写入负载的情况下。
同步延迟由于从服务器需要定期同步主服务器的数据,可能存在一定的同步延迟,对于某些实时性要求极高的应用可能不够理想。
配置和管理复杂主从读写架构需要进行配置和管理,确保主从服务器之间的数据同步正常,以及故障切换的机制得以正确配置。
一致性难保证在主从同步的过程中,如果主服务器和从服务器之间的网络发生故障,可能会导致数据同步不一致的问题。
数据安全风险从服务器可能成为攻击目标,需要采取额外的安全措施来保护数据的安全性。
可扩展性限制对于某些需要极高可扩展性的应用,主从读写架构的扩展性可能受到一定限制,需要考虑其他更为分布式的数据库架构。

主从读写架构在提高系统读性能、容错和高可用性方面有很大优势,但也存在一些劣势,特别是在写入负载较高、对实时性要求很高、配置和管理要求复杂等方面。在选择数据库架构时,需要根据具体的业务需求和系统特点进行权衡。

注意,**主从读写架构对于提高读取性能是有效的,但对于写操作的性能提升并不明显。**在高写入负载的情况下,还可能存在主服务器的性能瓶颈。

分库分表

在这里插入图片描述

  • 分库分表是一种常见的数据库架构设计,用于解决大规模应用中单一数据库的性能瓶颈问题。这种架构将数据库按照一定规则划分成多个库(Database)和表(Table),以提高系统的扩展性和性能。例如:主从库的写⼊依然是有⼀个统⼀的主库⼊⼝。随着业务量的提升,继续细粒度化拆分。
    • 业务分库:订单库,产品库,活动库,会员库
    • 横向分表:(拆记录)3个⽉内订单,半年内订单,更多订单
    • 纵向分表:(拆字段)name、phone⼀张表,info、address⼀张表,俩表id⼀致
  • 分库:不同的数据库,所以⽆法使⽤数据库事务,⽽分布式事务的效果并不理想,多采⽤幂等和最终⼀致性⽅案。分表:拆了再聚合是⼀对⽭盾,例如按下单时间维度的分表,需要按⽤户排序统计变得异常困难。中间件:Sharding-JDBC,Mycat,Atlas
  • 分库分表是一种在大规模数据应用中解决性能瓶颈问题的有效手段,但也需要在复杂性和管理成本之间进行权衡,根据具体的业务需求和数据特征做出明智的选择。

高速缓存

在这里插入图片描述

  1. 数据库往往是系统的瓶颈,根据数据的冷热划分,热点数据如类⽬、商品基础信息放在缓存中,其他数据延迟加载
    • ehcache:⾮分布式,简单,易维护,可⽤性⼀般
    • memcache:性能可靠,纯内存,客户端需要⾃⼰实现,⽆持久化
    • redis:性能可靠,纯内存,⾃带分⽚,集群,哨兵,⽀持持久化,⼏乎成为当前的标准⽅案
    • MTD巨头⾼性能缓存代理⽅案实战,Twemproxy⾼阶使⽤)
  2. 缓存策略:冷热数据的存放,缓存与的边界需要架构师去把控,重度依赖可能引发问题
    • 缓存陷阱:击穿(单⼀ key过期),穿透(不存在的 key),雪崩(多个 key 同时过期)
    • 数据⼀致性:缓存和 db 之间因为同⼀份数据保存了两份,⾃然带来了⼀致性问题

数据多样化

  • ⼀个⽹站中,数据库和缓存只是⼀种基本的存储⼿段,除了这些,随着⽹站架构的发展还需要各种形式的存储结构
    在这里插入图片描述
  • 数据库全⽂检索→搜索引擎、本地上传+nfs→分布式⽂件系统的演进

分布式文件

  • 分布式文件系统(Distributed File System)是一种将文件存储在多个节点或服务器上,以提供高性能、可靠性和可伸缩性的文件存储解决方案的系统。

    • hdfs(Hadoop Distributed File System):主要用于存储大规模数据集,并且与Hadoop生态系统集成,为MapReduce作业提供高吞吐量的数据访问。
    • fastdfs:主要用于构建大规模的分布式文件存储系统,特别适用于存储图片、音频、视频等大文件。
    • cephFs:CephFS提供了面向文件的接口,适用于需要大规模、高性能分布式文件存储的场景。
  • 总结

    • HDFS是专门为Hadoop生态系统设计的,适用于大数据处理。它使用分块存储和数据复制机制。
    • FastDFS专注于文件存储和访问,适用于构建大规模的分布式文件存储系统,如图片、音频、视频存储。
    • CephFS是Ceph存储系统的一部分,支持多种存储方式(块、对象、文件),具有很高的可扩展性和灵活性。

nosql

  • NoSQL(Not Only SQL)是一类数据库系,提供了灵活的数据存储模型、高度的可扩展性和性能优势
    • redis:基于内存的数据存储系统,被广泛用作缓存、消息代理和数据库
    • mongodb:文档型数据库,使用类似JSON的BSON格式存储数据
    • hbase:分布式、面向列的NoSQL数据库,运行在Hadoop文件系统(HDFS)之上。
    • TiDB:分布式SQL数据库,结合了传统的关系型数据库和NoSQL的优势

搜索引擎

  1. Lucene:Lucene是一个开源的全文搜索引擎库

    • 用途: 它提供了强大的文本搜索和检索功能,可以被用于构建自定义的搜索引擎。
    • 特点: Lucene是一个Java库,为开发人员提供了搜索引擎的基本构建块。它不是独立的搜索引擎,而是一个用于构建搜索引擎的库。
  2. Solr:Solr是一个构建在Lucene之上的开源企业搜索平台

    • 用途: Solr简化了在应用中集成全文搜索和其他类似功能的过程。它提供了RESTful API,使得与各种编程语言和应用程序轻松集成。
    • 特点: Solr包含了一些附加功能,如分布式搜索、复制和负载均衡等。它支持多种数据格式,并提供了强大的查询和分析功能。
  3. Elasticsearch: Elasticsearch也是一个构建在Lucene之上的开源搜索引擎。

    • 用途: Elasticsearch专注于实时数据分析和可视化,适用于日志、指标和全文搜索等场景。
    • 特点: Elasticsearch具有分布式特性,能够处理大规模数据。它提供了RESTful API,支持多种数据格式,还包括了丰富的聚合和分析功能。Elasticsearch被广泛用于构建实时搜索和分析引擎。

共同点

  1. Lucene是搜索引擎的核心库,而Solr和Elasticsearch是构建在Lucene之上的应用。
  2. Solr和Elasticsearch都提供了方便的HTTP接口,使得它们易于集成到各种应用中。
  3. Solr和Elasticsearch都支持分布式架构,可以水平扩展以处理大规模的数据和请求。

区别

  1. Solr更专注于企业级搜索,提供了更多的功能来满足企业需求,如复制、分片等。
  2. Elasticsearch更专注于实时数据分析和可视化,适用于日志和指标等场景。它在聚合和分析方面提供了更强大的功能。

架构特点

  • 开发框架⽀持:存储的数据多样化,要求开发框架架构层⾯要提供多样化的⽀撑,并确保访问易⽤性
  • 数据运维:多种数据服务器对运维的要求提升,机器的数据维护与灾备⼯作量加⼤
  • 数据安全:多种数据存储的权限,授权与访问隔离需要注意

应用架构

单机调优

  • 早年间的项⽬⼤多采⽤mvc开发
    在这里插入图片描述
  • 每个项⽬成⼀个mvc结构,部署在应⽤服务器上(tomcat、jboss、websphere,weblogic)。
  • 随着业务扩张,需求迭代,项⽬变得越来越⼤,⼀个war包动辄几百兆。

动静分离

  • 早年间的Apache+tomcat,后被Nginx替代(前后端开发模式的演进:mvc页面嵌套→接⼝化)
    在这里插入图片描述
  • 优势
    • 静态响应:tomcat对静态⽂件响应⼀般,提取静态⽂件,直接由Nginx响应
    • 动态代理:后端api通过代理转发给tomcat应⽤机器
    • 开发层⾯调整:项⽬结构要同步调整,由原来的⼀体化mvc转换为后端api+前端形式。
    • 前后协调:前后端的分⼯变得更明确,互相并并行开发,独立部署,但也带来了接口协调与约定等沟通问题
    • 跨域问题:后段与前端如果域名不同,可能存在跨域问题(head头,jsonp等⼿段可以解决)。

SOA

  • 单纯的动静分离只解决了自己服务的项⽬结构,跨项目接口调⽤时,必须经过rest请求,不利于服务之间的交互

在这里插入图片描述

  • 公共服务:重复开发的基础服务提取出来,形成服务中心,避免重复造轮⼦,降低成本,架构团队出现。

  • 独立性:各⾃服务独⽴部署升级,粒度更细,低耦合,高内聚

  • SOA理念诞⽣:服务治理的范畴,重在服务之间的拆分与统⼀接口。SOA(Service-Oriented Architecture,面向服务的架构)是一种软件设计和架构风格,其主要思想是通过将软件系统划分为独立且松散耦合的服务单元,这些服务单元通过标准化的协议进行通信,从而实现应用程序的构建和整合。

  • 技术⼿段

    • 异步化:rabbitmq、rocketmq、kafka
    • RPC:Dubbo、Zookeeper
    • RPC框架
    • 界限把控:服务的粒度、拆分和公共服务提炼需要架构师的全局把控。设计不好容易引发混乱
    • 部署升级:服务数量增多,⼈⼯部署变的不现实,必须借助⾃动化运维
    • 服务可⽤性:抽调的微服务因需要被多个上层业务共享,可⽤性等级变⾼,⼀旦down机就是灾难
    • 熔断和限流:做好服务熔断和限流,提防服务单点瓶颈造成整个系统瘫痪。短信提醒失败不要影响下单。

微服务

在这里插入图片描述

  • 微服务是基于SOA思想,将系统粒度进⼀步细化而诞⽣的⼀种手段。中台化得以实现,各个中⼼以及前端业务拆解为多个小的服务单元

  • 微服务经历了从1.0(cloud)到2.0的演化(service mesh),目前企业中主流的解决⽅案依然是cloud全家桶Spring Cloud Spring Cloud微服务前沿技术栈,Spring、Spring Boot。

  • 服务拆分:粒度并非越小越好,太小会增加维护成本。

  • 接口约束:系统增多,各个服务接口的规范化日益重要,要求有统⼀的服务接口规范,推动企业消息总线的建设。

  • 权限约束:接口不是任意想调就可以调的,做好权限控制,借助oauth2等⼿段,实现服务之间的权限认证。

部署架构

单机部署

在这里插入图片描述

  • 部署简单:采用web、jar包部署与发布,等资源同台机器连接,简单易操作。
  • 资源争夺:在业务发展的初始阶段尚可支撑,随着访问量的上升,单机性能很快会成为系统瓶颈。

⻆⾊划分

  • 稍微⼤⼀点的系统,把数据库、缓存、消息等中间件剥离出去,单独机器来部署
    在这里插入图片描述
  • 多台机器:tomcat与mysql各⾃独占机器资源
  • 针对性扩容:tomcat应⽤机更注重cpu的运算和内存,mysql更注重io与磁盘性能,针对各⾃情况扩容
  • 数据维护:可以抽出单独的dba来维护数据库服务器
  • 数据安全:需要跨机器访问数据库,链接密码需要注意防范泄漏

应⽤集群

  • 2004-2005,淘宝V2.0,EJB为核⼼。V2.1架构下,引⼊Spring框架⾛向轻量化和集群
    请添加图片描述

  • apache:早期负载均衡⽅案,性能⼀般

  • Nginx:7层代理,性能强悍,配置简洁,当前不⼆之选

  • haproxy:性能同样可靠,可做7层或4层代理。

  • lvs:4层代理,性能最强,linux集成,配置麻烦

  • f5:4层,硬件负载,财⼤⽓粗的不⼆选择

  • session保持:集群环境下,⽤户登陆需要分布式session做⽀撑

  • 分布式协同:分布式环境下对资源的加锁要超出线程锁的范畴,上升为分布式锁

  • 调度问题:调度程序不能多台部署,容易跑重复,除⾮使⽤分布式调度,如elastic-job

  • 机器状态管理:多台应⽤机的状态检测与替换需要做到及时性,⼀般niginx层做故障转移

  • 服务升级:滚动升级成为可能,灰度发布

  • 日志管理:⽇志⽂件分散在各个机器,促进集中式⽇志平台的产⽣

多层代理

在这里插入图片描述

  • 机器规模进⼀步加⼤,动静态均有多个Nginx负载,⼊⼝统⼀交给lvs负载。多层代理形成。
  • 机房受限:lvs依然是单⼀节点,即使keepalived做到⾼可⽤,流量仍然需要在唯⼀⼊⼝进⼊

异地访问

  • 将相同的系统部署多份,分散到异地多个机房,或者电信、移动等多个⽹络中。不同地点,不同⽹络接⼊的⽤户,有了不同的访问⼊⼝和选择。
    在这里插入图片描述
  • dns轮询:通过配置多个ip将服务部署到多个机房,通过dns的策略轮询调⽤,可以实现机房层⾯的扩容
  • CDN:就近原则,使⽤户获得就近的机房访问相关资源,投资太⼤,购买他⽅需要付费
  • 基本解决了机器部署的扩容问题,随着业务的发展,扩容与收缩变得困难,促进资源调度层⾯的技术发展

云平台

  • 针对中台化的建设及微服务数量的飙升,部署和运维⽀撑同步进⾏着变⾰。⾯临微服务的快速部署,资源的弹性伸缩等挑战,容器化与云被推进。
    在这里插入图片描述

  • 虚拟化:vm⽅案,Openstack,Vmware,VirtualBox

  • 容器化:docker

  • 编排:swarm,k8s,k3s(课题:运维篇 docker,k8s深⼊原理与应⽤)

  • 云化:容器化解决了资源的快速伸缩,但仍需要企业⾃备⼤量机器资源。推动私有云到企业云进化

  • 资源预估:注意资源的回收,降低资源闲置和浪费,例如⼤促结束后要及时回收。

  • 运维要求:需要运维层⾯的⾼度⽀撑,⻔槛⽐较⾼

  • 预估⻛险:云瘫痪的故障造成的损失不可估量

架构思想总结

  1. 知行合一,确保技术决策与业务目标紧密一致
    • 在构建技术架构之前,首先要理解业务需求和问题的实质。技术应该服务于业务目标,而不是为了技术而技术
  2. 原生优于定制,约定大于配
    • 尽量使用原生(标准)的解决方案,而不是进行过多的定制。同时,通过共识和约定来减少配置的复杂性
  3. 控制技术欲,不要瞎折腾
    • 不要过度追求新技术,避免为了使用新技术而不加思考地改变架构。技术选型应该基于实际需求和业务场景,而非盲目跟风。
  4. 留下扩展,,但要避免过度设计和过度优化。
    • 架构应该具有一定的扩展性,能够容纳未来的增长和变化。然而,也要在现实可预见的范围内进行规划。
  5. 没有最好的,只有最合适的
    • 没有一种通用的、适用于所有场景的最佳解决方案。技术选择应该基于具体的需求、团队的技术栈和经验,以及系统的特定要求
  6. 够用就好,玩的越花,风险越大
    • 在技术决策上要保持实用主义,选择足够满足需求的方案,避免过度投入。
  7. 简约最美
    • 保持系统和代码的简洁性有助于提高可读性、可维护性,减少错误和降低复杂性。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/180094.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

封装可多选的组件(Autocomplete)

一。组件库Material UI 1.1 地址 https://v4.mui.com/zh/getting-started/installation/ 1.2 简介 自称世界上最受欢迎的React UI组件库(能看到这里的基本用法应该都清楚了,我就不重复了) 二。效果展示 三。代码展示 import React from reactimport { useField, us…

【VRTK】【VR开发】【Unity】9-瞬移

课程配套学习资源下载 https://download.csdn.net/download/weixin_41697242/88485426?spm=1001.2014.3001.5503 【移动的种类】 瞬移只是VR中移动的一种种类,其它还有连续移动,物理移动,摔臂移动等等。 瞬移自身也有多个分类,本篇介绍: 即时瞬移冲刺瞬移定点瞬移【瞬…

项目七 熟练使用Vim程序编辑器与shell

项目七 熟练使用Vim程序编辑器与shell #职业能力目标和要求 1,学会使用vim编辑器。 2,了解shell的强大功能和shell的命令解释过程。 3,学会使用重定向和管道的方法。 4,掌握正则表达式的使用方法。7.1 熟悉使用vim编辑器 7.1.1 …

羽隔已就之图像处理之BP神经网络入门

小y最近非常忙,这一年来,活很多,一直在加班、出差,也没好好休息过。最近在武汉出差一个多月了,项目逐渐完结,有点闲时间了,回首望,这一年设定的很多目标都没完成。 还记得&#xff0…

深入Rust的模式匹配与枚举类型

今天,我们将深入探讨Rust语言中的两个强大特性:模式匹配(Pattern Matching)和枚举类型(Enums)。这两个特性是Rust提供的核心工具之一,它们在处理多种类型的数据和复杂的逻辑控制中发挥着关键作用…

七、Lua字符串

文章目录 一、字符串(一)单引号间的一串字符(二)local str "Hello, "(三)[[ 与 ]] 间的一串字符(四)例子 二、字符串长度计算(一)string.len&…

技巧-PyTorch中num_works的作用和实验测试

简介 在 PyTorch 中,num_workers 是 DataLoader 中的一个参数,用于控制数据加载的并发线程数。它允许您在数据加载过程中使用多个线程,以提高数据加载的效率。 具体来说,num_workers 参数指定了 DataLoader 在加载数据时将创建的…

深度学习之图像分类(十五)DINAT: Dilated Neighborhood Attention Transformer理论精简摘要(二)

Dilated Neighborhood Attention Transformer摘要 局部注意力机制:例如滑动窗口Neighborhood Attention(NA)或Swin Transformer的Shifted Window Self Attention。 优点:尽管在降低自注意力二次复杂性方面表现出色, …

微服务知识大杂烩

1.什么是微服务? 微服务(Microservices)是一种软件架构风格,将一个大型应用程序划分为一组小型、自治且松耦合的服务。每个微服务负责执行特定的业务功能,并通过轻量级通信机制(如HTTP)相互协作。每个微服务可以独立开发、部署和扩展,使得应用程序更加灵活、可伸缩和可…

docker 安装elasticsearch集群

准备工作 docker 安装好,docker compose 安装好编辑好docker-compose.yml文件(本文会提供)生成elastic-certificates.p12密钥,与docker-compose文件在同一个目录(本文会介绍生成方式)准备elasticsearch配置…

Selenium 学习(0.17)——软件测试之测试用例设计方法——白盒测试——逻辑覆盖法(条件覆盖和条件判定覆盖)

条件覆盖 设计测试用例,使每个判断中每个条件的可能取值至少满足一次。 条件判定覆盖 通过设计足够的测试用例,满足如下条件: 所有条件的可能至少执行一次的取值 所有判断的可能结果至少执行一次 条件判定覆盖同时满足判定覆…

centos7.9 + gitlab12.3.0安装

本文在centos7.9操作系统上安装gitlab 12.3.0,gitlab官方最新的版本已经是16.6.0了,这里仍然安装12.3.0版本的原因是汉化包的最新版本是12.3.0,如果汉化包的版本和gitlab的版本不对应,会出现汉化他无法启动的现象。 1、安装依赖 …

Python 图形用户界面详解(GUI,Tkinter)

文章目录 1 概述1.1 TK:窗口1.2 官方文档 2 组件2.1 Label:标签2.2 Button:按钮2.3 Entry:输入2.4 Text:文本2.5 Radiobutton:单选框2.6 Checkbutton:复选框2.7 Canvas:画布2.10 Men…

Shell条件变量练习

1.算数运算命令有哪几种? (1) "(( ))"用于整数运算的常用运算符,效率很高 [rootshell scripts]# echo $((24*5**2/8)) #(( ))2452814 14 (2) "$[ ] "用于整数运算 [rootshell scripts]# echo $[24*5**2/8] #[ ]也可以运…

Python缺失值处理实现

在数据处理相关工作中,读取的数据中常常会有缺失值的情况,为顺利进行后续的操作,需要首先对缺失值进行处理,处理的方式一般为删除或填充,Python中提供了专门的工具包,可以方便地进行实现。读取操作可以由pa…

WebGL技术框架及功能

WebGL(Web Graphics Library)是一种用于在Web浏览器中渲染交互式3D和2D图形的JavaScript API。它允许在不需要插件的情况下,在支持WebGL的浏览器中直接运行高性能的图形渲染。WebGL没有一个固定的技术框架,而是基于JavaScript API…

【Vue】绝了!这生命周期流程真...

hello,我是小索奇,精心制作的Vue系列持续发放,涵盖大量的经验和示例,如果对您有用,可以点赞收藏哈~ 生命周期 Vue.js 组件生命周期: 生命周期函数(钩子)就是给我们提供了一些特定的…

SpringBoot整合MongoDB: 构建高效的数据存储应用

文章目录 1. 引言2. MongoDB简介3. 准备工作4. SpringBoot中配置MongoDB5. 创建MongoDB实体类6. 使用Spring Data MongoDB进行数据操作7. 编写Service层8. 控制器层9. 测试10. 拓展10.1. 复杂查询10.2. 数据分页10.3. 索引优化 11. 总结 🎉SpringBoot整合MongoDB: 构…

Django回顾2

目录 一.HTTP 1.URL介绍 2.格式: 3.补充: 二.web框架 1.什么是框架 2.什么是web框架 3.wsgi协议 基于wsgi协议的web服务器: 4.协议是怎么规定的 三.Django 1.MVC与MTV模型(所有框架其实都遵循MVC架构) 2.…

别太担心,人类只是把一小部分理性和感性放到了AI里

尽管人工智能(AI)在许多方面已经取得了重大进展,但它仍然无法完全复制人类的理性和感性。AI目前主要侧重于处理逻辑和分析任务,而人类则具有更复杂的思维能力和情感经验。 人类已经成功地将一些可以数据化和程序化的理性和感性特征…