- 综合排序
- 最热优先
- 最新优先
- 来自专栏架构之家
高德打车通用可编排订单状态机引擎设计
以高德打车业务的订单状态为例，订单状态就有乘客下单、司机接单、司机已到达乘车点、开始行程、行程结束、确认费用、支付成功、订单取消、订单关闭等；订单车型有专车、快车、出租车等几种车型，而专车又分舒适型、豪华型 二 实现方案 要解决"多状态+多类型+多场景+多维度"的复杂订单状态流转业务，我们从纵向和横向两个维度进行设计。 1 纵向解决业务隔离和流程编排 状态模式的应用 通常我们处理一个多状态或者多维度的业务逻辑，都会采用状态模式或者策略模式来解决，我们这里不讨论两种设计模式的异同，其核心其实可以概括为一个词"分而治之"， 这不仅仅是从可扩展性和可维护性的角度出发，其实我们做架构做稳定性、隔离是一种减少影响面的基本手段，类似的隔离环境做灰度、分批发布等，这里不做扩展。 还是有的，对于数据库状态变更和消息的一致性的问题，细节比较多，每种方案又都有相应的优缺点，本文主要是介绍状态机引擎的设计，对于消息一致性的问题就不过多介绍，后面也许会有单独的文章对数据库变更和消息的一致性的问题进行介绍和讨论
1.8K31编辑于 2022-09-01 - 来自专栏Java项目实战
滴滴打车系统架构设计
一、需求分析 系统高清架构图参考链接 滴滴打车系统架构图_系统架构图_打车软件系统架构图_功能架构图_系统架构图模板 - 在线模板社区 (edrawmax.cn) 1.1 业务需求 打车系统是一种基于互联网的出行服务 1.3 非功能需求 1.3.1 性能需求 系统需要保证高并发、低延迟，能够在瞬时大量请求下快速响应，保证系统的稳定性和可靠性。 二、系统架构设计 2.1 架构模式 系统采用微服务架构模式，将系统拆分成多个小型服务，每个服务都是独立的，可以独立部署和扩展。这种架构模式能够更好地满足系统的可扩展性和可维护性需求。 四、总结 本文介绍了打车系统的架构设计，包括需求分析、架构模式、系统模块、技术选型、系统架构图、系统交互流程和部署方案。 打车系统是一种基于互联网的出行服务，需要保证高并发、低延迟、数据安全等需求，采用微服务架构模式能够更好地满足这些需求。系统的部署方案需要根据实际情况进行调整，保证系统的稳定性和可靠性。
4.2K71编辑于 2023-03-18 - 来自专栏AI实验室应用
揭秘高德地图智能助手：基于Assistant的优化实践与架构设计
摘要：本文深入探讨基于Assistant框架实现的高德地图智能助手的优化版本，从配置解耦、错误处理、性能优化到安全设计等维度，揭示其技术架构与工程实践。 一、引言：智能助手的需求与挑战 在位置服务日益重要的今天，高德地图智能助手需要具备快速响应、精准查询、灵活扩展等能力。传统实现常面临配置管理混乱、错误处理薄弱、API调用效率低等问题。 """基于 Assistant 实现的高德地图智能助手 优化版本改进： 1. 配置与代码分离 2. 更好的错误处理 3. 性能优化 4. 更安全的API密钥管理 5. '你应该充分利用高德地图的各种功能来提供专业的建议。' '回答要简洁明了，重点突出。' 高德API封装与工具调用 地点查询工具通过_amap_query_tool解析用户意图，分发至_query_location方法，封装API请求逻辑。
25210编辑于 2025-10-28 - 来自专栏A周立SpringCloud
从MySQL高可用架构看高可用架构设计
高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务，我们说系统的可用性是100%。 1.2 高可用复制架构 ? 1.3.mysql 高可用架构 1.3.1 MySQL Cluster架构 限制存储引擎为NDB存储引擎： ? 此架构特点： 1、安装布署简单，不影响现有架构 2、自动监控和故障转移 3、保障数据一致性 4、故障切换方式可使用手动或自动多向选择 5、适应范围大（适用任何存储引擎） 2.MySQL高可用带给我们对高可用架构设计的思考 3.总结 我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。 所以，又往往是通过“自动故障转移”来实现系统的高可用。灾备的恢复一般通过日志来做，日志的设计也是难点，MySQL提供了一个思路。
1.2K20发布于 2019-08-23 - 来自专栏xin猿意码的公众号文章
听说你会架构设计？来，弄一个打车系统
设计一个“网约车系统” 面试官：“滴滴打车用过是吧！看你简历里写道会架构设计是吧，如果让你设计一个网约车系统，你会从哪些方面考虑呢？” 故我们需要开发两个 APP 应用，分别给乘客和司机打车和接单，架构图如下： 1）乘客视角 如上所示：乘客在手机 App 注册成为用户后，可以选择出发地和目的地，进行打车。 2.3 详细设计 打车平台的详细设计，我们会关注网约车系统的一些核心功能，如：长连接管理、地址算法、体验优化等。 相比短连接，长连接优势有三： 连接成功率高 网络延时低 收发消息稳定，不易丢失 2）长连接管理 前面说到了长连接的优势是实时性高，收发消息稳定，而打车系统里司机需要定期发送自身的位置信息，并实时接收订单数据 这些平台一部分是依靠高德打车、百度地图、美团打车为代表的网约车聚合平台；另一部分则是以滴滴出行、花小猪、T3 为代表的出行平台。 4.2 网约车平台现状 随着出行的解封，网约车平台重现生机。
1.6K21编辑于 2023-10-18 - 来自专栏性能与架构
架构设计原则 - 高并发
高并发设计可以从以下几方面考虑： 无状态 拆分 服务化 消息队列 数据异构 缓存 并发化 1. 无状态 无状态的应用容易进行水平扩展。 应用示例：电商促销时，流量会比平时高出几倍甚至几十倍，这就需要特殊的设计来保证系统平稳，一般是牺牲强一致性，保证最终一致性，如扣减库存，直接在 redis 中扣减，记录下日志，通过 worker 同步到数据库 再比如订单系统，可以这样设计： ? 结算服务调用订单接单服务，将订单存储到 redis 和订单队列中。订单redis用于用户查看订单详情，通过队列提升接单能力。 内容整理自张开涛的《亿级流量网站架构核心技术》，推荐详读。
97850发布于 2019-03-07 - 来自专栏用户7873631的专栏
设计第一个地图应用（高德地图）
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Document</title>. <script
44410发布于 2020-10-28 - 来自专栏数据库架构设计
mysql高可用架构设计
主要介绍：复制功能介绍，mysql二进制日志，mysql复制拓扑，高可用框架，单点故障，读写分离和负载均衡 一 mysql复制功能介绍 mysql复制功能提供分担读负载 二 复制解决的问题 需要其他组件配合完成 2.2 利用DNS轮询的方式把程序的连接到不同的备份数据库 2.3 利用LVS,haproxy这样的代理方式 2.4 非共享架构 所使用的高可用管理组件 对应用的支持程度 九 mysql复制拓扑 mysql5.7之前，一个从库只能又一个主库，5.7之后，支持一从多主 在从库上进行数据修改造成的主从复制错误 十二 mysql复制无法解决的问题 分担数据库的写负载 自动进行故障转移及主从切换 提供读写分离功能 十三 高可用架构 什么是高可用：通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机事件，以提高系统和应用的可用性 高可用的因子：正常可用时间，全年时间的百分比 引起系统不可用的原因
1.2K00发布于 2018-11-18 - 来自专栏后端系统和架构
高并发架构设计经验
我的《高并发架构设计经验》原文链接，欢迎前往微信关注 一、高并发的说明和背景 高并发解决的核心问题是在同一时间上有大量的请求过来，然后我们的系统要怎么抗住这些请求带来的压力。 二、高并发架构设计经验 高并发架构设计，需要从三大层来建设和分析 • 基础设施层：这个是最基础的依赖，主要是一些服务的部署。 • 服务端架构层：这个是我们重点要关注的架构设计，架构设计不合理，就很难抗住高并发，主要包括各种架构和模块的设计。 • 服务应用层：这个主要是针对我们写的代码来进行优化改进。 ，独立的应用服务器，数据库，缓存服务器，当业务达到一定用户量的时候，再进行服务器均衡负载，数据库，缓存主从集群 集群架构设计：应用集群、数据集群 应对高并发系统，不管是应用层面还是数据层面，单机都不可能搞定 • 其次需要考虑的是多级缓存架构。分几级缓存设计，同时设计热点缓存架构。 • 在分布式缓存之上，还可以加一个本地缓存，来缓存最热的数据 • 采用多个分布式缓存来搭建多级缓存。
1.6K82编辑于 2022-11-29 - 来自专栏博文视点Broadview
架构学习之路——高可用高并发系统设计原则
架构设计三大定律 墨菲定律 - 任何事没有表面看起来那么简单 - 所有的事都会比预计的时间长 - 可能出错的事情总会出错 - 担心某种事情发生，那么它就更有可能发生 康威定律 - 系统架构师公司组织架构的反映 - 按照业务闭环进行系统拆分/组织架构划分，实现闭环、高内聚、低耦合，减少沟通成本 - 如果沟通出现问题，应该考虑进行系统和组织架构的调整 - 适合时机进行系统拆分，不要一开始就吧系统、服务拆分拆的非常细 ，虽然闭环，但是每个人维护的系统多，维护成本高 - 微服务架构的理论基础 - 康威定律 https://yq.aliyun.com/articles/8611 - 每个架构师都应该研究下康威定律 http ://36kr.com/p/5042735.html 二八定律 - 80%的结果取决于20%的原因 架构设计三大定律 １．高并发原则 无状态 无状态应用，便于水平扩展 有状态配置可通过配置中心实现无状态 防重设计 幂等设计 流程定义 状态与状态机 后台系统操作可反馈 后台系统审批化 文档注释 备份 4．总结 先行规划和设计时有必要的，要对现有问题有方案，对未来有预案;欠下的技术债，迟早都是要还的。
1.1K11发布于 2020-06-11 - 来自专栏刷题笔记
【架构设计复习】高可用，高扩展实现方案
上一个是 高性能，这一篇就分析高可用。 文章目录 高可用实现 对等节点的故障转移 非对等节点的故障转移 接口层面的超时设置、重试策略和幂等设计。 降级处理 限流处理 MQ场景的消息可靠性保证 灰度发布 监控报警 灾备演练 高可用设计方向 高扩展实现方案 合理的分层架构 存储层的拆分 业务层的拆分 高可用实现 对等节点的故障转移 Nginx和服务治理框架均支持一个节点失败后访问另一个节点 接口层面的超时设置、重试策略和幂等设计。 降级处理 保证核心服务，牺牲非核心服务，必要时进行熔断；或者核心链路出问题时，有备选链路。 限流处理 对超过系统处理能力的请求直接拒绝或者返回错误码。 高可用设计方向 高可用的方案主要从冗余、取舍、系统运维3个方向考虑，同时需要有配套的值班机制和故障处理流程，当出现线上问题时，可及时跟进处理。 高扩展实现方案 分层+拆分 合理的分层架构 比如上面谈到的互联网最常见的分层架构，另外还能进一步按照数据访问层、业务逻辑层对微服务做更细粒度的分层（但是需要评估性能，会存在网络多一跳的情况）。
1.1K20发布于 2021-04-14 - 来自专栏飞总聊IT
高并发系统设计负载均衡架构
架构师修行之路 ， 作者 菜v菜 随着访问量的不断加大，网站我又加了nginx做负载均衡 ? ? 好呀，看来要进阶高级工程师啦~ ? ? 请求的过程中，其实会遇到有很多负载均衡的过程，一个系统在什么阶段做负载均衡取决于它的请求量，这和常说的QPS/TPS/DAU等有直接关系，假设系统的请求量非常少，其实完全没有必要做负载均衡，当然有时候为了达到高可用的目的也做负载均衡 说了这么多，其实以上几种方案是基于http请求的途经来解决问题，每种方案都有它自己的缺点和优点，设计一个系统的时候初期就把以上方案全部采用以达到高性能的要求，也许并不是什么好事，每一个系统都是随着业务的增长而逐渐改变架构形态
1K10发布于 2019-09-10 - 来自专栏devops
【架构实战】高并发系统设计思路
二、高并发带来的挑战性能瓶颈：CPU、内存、IO成为瓶颈资源竞争：数据库连接池、线程池耗尽雪崩效应：一个服务故障导致整个系统崩溃数据一致性：并发更新导致数据错乱三、高并发设计原则1.水平扩展vs垂直扩展类型方式特点垂直扩展增加单机硬件配置有上限 ，成本高水平扩展增加机器数量无上限，复杂度高2.无状态设计展开代码语言：JavaAI代码解释//❌有状态：用户会话存在单机内存publicclassUserService{privateMapsessions publicProductgetProduct(Longid){//只有缓存不存在时才查数据库returnproductRepository.findById(id).orElse(null);}}四、高并发架构演进展开代码语言 --写库--索引优化CREATEINDEXidx_user_timeONorders(user_id,create_time);2.缓存使用展开代码语言：TXTAI代码解释缓存架构演进：单机缓存→Redis newSeckillMessage(userId,productId));//4.标记用户已参与redis.opsForValue().set(userKey,"1",24,TimeUnit.HOURS);}}七、总结高并发系统设计的核心是
3800编辑于 2026-04-02 - 来自专栏一名叫大蕉的程序员
高并发系统设计负载均衡架构
请求的过程中，其实会遇到有很多负载均衡的过程，一个系统在什么阶段做负载均衡取决于它的请求量，这和常说的QPS/TPS/DAU等有直接关系，假设系统的请求量非常少，其实完全没有必要做负载均衡，当然有时候为了达到高可用的目的也做负载均衡 应用 说了这么多，其实以上几种方案是基于http请求的途经来解决问题，每种方案都有它自己的缺点和优点，设计一个系统的时候初期就把以上方案全部采用以达到高性能的要求，也许并不是什么好事，每一个系统都是随着业务的增长而逐渐改变架构形态
1.9K50发布于 2019-09-12 - 来自专栏JavaEdge
高可用架构设计(2) - hystrix
Hystrix的设计原则 对依赖服务调用时出现的调用延迟和调用失败进行控制和容错保护 在复杂的分布式系统中，阻止某一个依赖服务的故障在整个系统中蔓延，服务A->服务B->服务C，服务C故障了，服务B也故障了 整套分布式系统全部故障，整体宕机 提供fail-fast（快速失败）和快速恢复的支持 提供fallback优雅降级的支持 支持近实时的监控、报警以及运维操作5 Hystrix要解决的问题在复杂的分布式系统架构中 已经达到了99.99%的高可用性 那么该服务的可用性就是99.99%的30次方，也就是99.7%的可用性 99.7%的可用性就意味着3%的请求可能会失败，因为3%的时间内系统可能出现了故障不可用了。 上面也就是说，即使你每个依赖服务都是99.99%高可用性，但是一旦你有几十个依赖服务，还是会导致你每个月都有几个小时是不可用的。 Hystrix的更加细节的设计原则 阻止任何一个依赖服务耗尽所有的资源，比如tomcat中的所有线程资源 避免请求排队和积压，采用限流和fail fast来控制故障 提供fallback降级机制来应对故障
30420编辑于 2021-12-07 - 来自专栏后端系统和架构
高可用架构和系统设计经验
TOC高可用架构和系统设计经验图片本文从研发规范层面、应用服务层面、存储层面、产品层面、运维部署层面、异常应急层面这六大层面去剖析一个高可用的系统需要有哪些关键的设计和考虑一、高可用架构和系统设计思想可用性和高可用概念可用性是一个可以量化的指标 高可用系统设计思想高可用系统的设计，需要有一套比较科学的工程管理套路，要从产品、开发、运维、基建等全方位去考量和设计，高可用系统的设计思想包括但不限于：做好研发规范，系统都是研发人员设计和编码写出来的， 不同的量级对应的系统架构的设计会完全不一样，尤其到了千万、亿级别的量级的时候，架构的设计会有很多的考量。 五、产品层面产品层面的高可用架构解决方案，基本上就是指我们的兜底产品策略。降级/限流的策略，更多的是从后端的业务服务和架构上的设计来考虑相关解决方案。 推荐阅读推荐阅读我的其他文章：《高并发架构和系统设计经验》《TCP 长连接层的设计和 在 IM 项目中实战应用》《万字解读云原生时代，如何从 0 到 1 构建 K8s 容器平台的 LB（Nginx）负载均衡体系
2K163编辑于 2022-12-19 - 来自专栏JAVA开发专栏
架构设计---高可用的处理
前言： 系统的高可用架构就是要在上述各种故障情况下，保证系统依然可用提供服务，具体包括以下几种架构方案。 冗余备份： 各种服务器故障是不可避免的，架构设计上就要保证，当服务器故障的时候，系统依然可用访问。 在负载均衡架构中，可用将多台应用服务器构成一个集群一起对外提供服务，这样可以利用多台应用服务器的计算资源，满足高并发的用户访问请求，事实上，负载均衡可以实现系统的高可用。 失败隔离： 保证系统高可用的另外一个策略是失败隔离，将失败隔离在一个较小的范围之内，使故障影响范围不扩大，失败隔离的主要架构技术是消息队列。 异地多活架构考虑的重点就是，用户请求如何分发到不同的机房上面。
64750编辑于 2023-02-27 - 来自专栏Python乱炖
高并发系统设计负载均衡架构
请求的过程中，其实会遇到有很多负载均衡的过程，一个系统在什么阶段做负载均衡取决于它的请求量，这和常说的QPS/TPS/DAU等有直接关系，假设系统的请求量非常少，其实完全没有必要做负载均衡，当然有时候为了达到高可用的目的也做负载均衡 说了这么多，其实以上几种方案是基于http请求的途径来解决问题，每种方案都有它自己的缺点和优点，设计一个系统的时候初期就把以上方案全部采用以达到高性能的要求，也许并不是什么好事，每一个系统都是随着业务的增长而逐渐改变架构形态
1.4K20发布于 2019-10-21 - 来自专栏Java架构师必看
高并发大型网站架构设计
一个大型的网站网站应该由如下6个子系统组成 负载均衡系统 反向代理系统 Web服务器系统 分布式存储系统 底层服务系统 数据库集群系统 为什么要做高并发系统设计？ 目前的门户网站动辄几千万的访问量，所以，高并发的系统架构在所难免。 整体架构 真实中的网站架构也许并不如此也可以实现高性能。但是高性能的网站莫不过如此。如下图所示。 ? 硬件负载均衡效率高，但是价格贵，比如F5等。 软件负载均衡系统价格较低或者免费，效率较硬件负载均衡系统低，不过对于流量一般或稍大些网站来讲也足够使用，比如lvs。 第五 底层服务系统 根据各自需要由C/C++开发设计供上层CGI调用。 本文由来源 21aspnet，由 javajgs_com 整理编辑，其版权均为 21aspnet 所有，文章内容系作者个人观点，不代表 Java架构师必看 对观点赞同或支持。
97720发布于 2021-03-22 - 来自专栏大魏分享（微信公众号：david-share）
Openshift的高可用架构设计
第一部分：高可用设计 一、Openshift架构 Openshift架构如上图，其核心组件有： ●Multiple Masters ●External etcd ●Routers ●Registry 五、一个典型的Openshift高可用集群 根据以上的高可用原则，master至少应为三个，且为奇数个（上面有etcd）。 这样，当Openshift计算资源不够的时候，增加计算节点即可，不必对Master和基础架构节点进行变动。 六、多Openshift集群设计 Openshift在多数据中心上部署的时候，有两种模式：SEPARATE CLUSTERS和STRETCH CLUSTER。 生产环境的架构设置，上面已经提到了即典型的3（Master）+3（Infrastructure）架构。
2.8K40发布于 2018-03-22
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号