当前位置：
  1. 首页
  2. 互联网
  3. 正文
本文介绍: 知行合一，确保技术决策与业务目标紧密一致在构建技术架构之前，首先要理解业务需求和问题的实质。技术应该服务于业务目标，而不是为了技术而技术原生优于定制，约定大于配尽量使用原生（标准）的解决方案，而不是进行过多的定制。同时，通过共识和约定来减少配置的复杂性控制技术欲，不要瞎折腾不要过度追求新技术，避免为了使用新技术而不加思考地改变架构。技术选型应该基于实际需求和业务场景，而非盲目跟风。留下扩展,，但要避免过度设计和过度优化。架构应该具有一定的扩展性，能够容纳未来的增长和变化。

文章目录

在这里插入图片描述

版权声明

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

业务架构

单体模式

中台战略

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

中台战略下：

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

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

  1. 业务中台
    • 业务中台基于公共服务的沉淀，需要积累⼀些基础的业务服务。它包括订单管理、支付服务、商品管理等业务功能的通用化和标准化。通过业务中台，不同的业务线可以共享这些通用功能，实现业务功能的复用，减少重复开发，提高效率。业务中台的建设旨在降低业务线之间的耦合度，使得每个业务线更加独立和灵活。
      • 商品中⼼：商品、类⽬、sku、spu
      • 交易中⼼：订单、状态流转、条⽬、⽀付
      • 营销中⼼：促销、优惠券、活动
      • 会员中⼼：账户、基本信息、收发货地址、商铺商家信息
      • 仓储中⼼：仓库、库存
      • 物流中⼼：发货信息、⾃主物流或外部物流对接
  2. 技术中台
  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），以提高系统的扩展性和性能。例如：主从库的写⼊依然是有⼀个统⼀的主库⼊⼝。随着业务量的提升，继续细粒度化拆分。
  • 分库：不同的数据库，所以⽆法使⽤数据库事务，⽽分布式事务的效果并不理想，多采⽤幂等和最终⼀致性⽅案。分表：拆了再聚合是⼀对⽭盾，例如按下单时间维度的分表，需要按⽤户排序统计变得异常困难。中间件：Sharding-JDBC，Mycat，Atlas
  • 分库分表是一种在大规模数据应用中解决性能瓶颈问题的有效手段，但也需要在复杂性和管理成本之间进行权衡，根据具体的业务需求和数据特征做出明智的选择。

高速缓存

在这里插入图片描述

  1. 数据库往往是系统的瓶颈，根据数据的冷热划分，热点数据如类⽬、商品基础信息放在缓存中，其他数据延迟加载
  2. 缓存策略：冷热数据的存放，缓存与的边界需要架构师去把控，重度依赖可能引发问题
    • 缓存陷阱：击穿（单⼀ key过期），穿透（不存在的 key），雪崩（多个 key 同时过期）
    • 数据⼀致性：缓存和 db 之间因为同⼀份数据保存了两份，⾃然带来了⼀致性问题

数据多样化

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

分布式文件

nosql

  • NoSQL（Not Only SQL）是一类数据库系，提供了灵活的数据存储模型、高度的可扩展性和性能优势

搜索引擎

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

  2. Solr：Solr是一个构建在Lucene之上的开源企业搜索平台。

    • 用途： Solr简化了在应用中集成全文搜索和其他类似功能的过程。它提供了RESTful API，使得与各种编程语言和应用程序轻松集成。
    • 特点： Solr包含了一些附加功能，如分布式搜索、复制和负载均衡等。它支持多种数据格式，并提供了强大的查询和分析功能。

  3. Elasticsearch： Elasticsearch也是一个构建在Lucene之上的开源搜索引擎。

共同点

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

区别

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

架构特点

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

应用架构

单机调优

动静分离

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等⼿段，实现服务之间的权限认证。

部署架构

单机部署

在这里插入图片描述

⻆⾊划分

应⽤集群

多层代理

在这里插入图片描述

  • 机器规模进⼀步加⼤，动静态均有多个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. 简约最美
    • 保持系统和代码的简洁性有助于提高可读性、可维护性，减少错误和降低复杂性。

原文地址:https://blog.csdn.net/yang2330648064/article/details/134671635

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。

如若转载，请注明出处：http://www.7code.cn/show_4355.html

如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！

上一篇 Docker Remote API 使用详解
下一篇 Baidu Comate 基于百度文心一言的智能编码助手

相关文章

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

插入图片
浏览器会保存昵称、邮箱和网站cookies信息，下次评论时使用。