从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
149501 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

13 | 架构设计流程:详细方案设计

完成备选方案的设计和选择后,我们终于可以长出一口气,因为整个架构设计最难的一步已经完成了,但整体方案尚未完成,架构师还需继续努力。接下来我们需要再接再励,将最终确定的备选方案进行细化,使得备选方案变成一个可以落地的设计方案。所以今天我来讲讲架构设计流程第 4 步:详细方案设计。

架构设计第 4 步:详细方案设计

简单来说,详细方案设计就是将方案涉及的关键技术细节给确定下来。
假如我们确定使用 Elasticsearch 来做全文搜索,那么就需要确定 Elasticsearch 的索引是按照业务划分,还是一个大索引就可以了;副本数量是 2 个、3 个还是 4 个,集群节点数量是 3 个还是 6 个等。
假如我们确定使用 MySQL 分库分表,那么就需要确定哪些表要分库分表,按照什么维度来分库分表,分库分表后联合查询怎么处理等。
假如我们确定引入 Nginx 来做负载均衡,那么 Nginx 的主备怎么做,Nginx 的负载均衡策略用哪个(权重分配?轮询?ip_hash?)等。
可以看到,详细设计方案里面其实也有一些技术点和备选方案类似。例如,Nginx 的负载均衡策略,备选有轮询、权重分配、ip_hash、fair、url_hash 五个,具体选哪个呢?看起来和备选方案阶段面临的问题类似,但实际上这里的技术方案选择是很轻量级的,我们无须像备选方案阶段那样操作,而只需要简单根据这些技术的适用场景选择就可以了。
例如,Nginx 的负载均衡策略,简单按照下面的规则选择就可以了。
轮询(默认)
每个请求按时间顺序逐一分配到不同的后端服务器,后端服务器分配的请求数基本一致,如果后端服务器“down 掉”,能自动剔除。
加权轮询
根据权重来进行轮询,权重高的服务器分配的请求更多,主要适应于后端服务器性能不均的情况,如新老服务器混用。
ip_hash
每个请求按访问 IP 的 hash 结果分配,这样每个访客固定访问一个后端服务器,主要用于解决 session 的问题,如购物车类的应用。
fair
按后端服务器的响应时间来分配请求,响应时间短的优先分配,能够最大化地平衡各后端服务器的压力,可以适用于后端服务器性能不均衡的情况,也可以防止某台后端服务器性能不足的情况下还继续接收同样多的请求从而造成雪崩效应。
url_hash
按访问 URL 的 hash 结果来分配请求,每个 URL 定向到同一个后端服务器,适用于后端服务器能够将 URL 的响应结果缓存的情况。
这几个策略的适用场景区别还是比较明显的,根据我们的业务需要,挑选一个合适的即可。例如,比如一个电商架构,由于和 session 比较强相关,因此如果用 Nginx 来做集群负载均衡,那么选择 ip_hash 策略是比较合适的。
详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行,一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性。例如,我曾经参与过一个项目,在备选方案阶段确定是可行的,但在详细方案设计阶段,发现由于细节点太多,方案非常庞大,整个项目可能要开发长达 1 年时间,最后只得废弃原来的备选方案,重新调整项目目标、计划和方案。这个项目的主要失误就是在备选方案评估时忽略了开发周期这个质量属性。
幸运的是,这种情况可以通过下面方式有效地避免:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(107)

  • 最新
  • 精选
  • 正是那朵玫瑰
    可以完善的细节: 1、发送端和消费端如何寻址 利用zookeeper做注册中心,把broker的地址注册到zk上,发送端和消费端只要配置注册中心的地址即可获取集群所以broker地址,当有broker下线时,发送端和消费端能及时更新broker地址。 2、发送端消息重试 当发送消息发生网络异常时(不包括超时异常),可以重新选择下一台broker来重试发送,重试策略可以自定义。 3、消息消费采用pull还是push? 考虑push模式会更复杂,故放弃,采用pull模式,消费端主动去拉,为了达到与push模式相同的低延迟效果,可以采用长轮询的方式,消费端轮询拉取消息费,当有消费可消费时,返回消息,如果没有可消费的消息,挂起当前线程,直到超时或者有可消费的消息为止。 4、消息重复问题 消息中间件不解决消息重复的问题,有业务系统自己根据业务的唯一id去重。 5、顺序消息 发送端在发生顺序消息时,只发送到相同broker的相同队列,消费端消费时,顺序消息只能由同一个消费端消息。 6、定时消息 发送端指定消息延时多长时间消费,broker端定时扫描定时消息,达到延时时间的消息加入到消费队列。 7、事务消息 发送端分两步,先预发送消息,broker端只记录消息为预发送状态,再执行本地事务,然后再根据本地事务的成功或者失败发送确认消息(回滚还是提交),这步如果发生异常,broker启动定时任务,把未确认的消息发送给发送端回查事务状态(需要发送端提供回查接口)。 目前就想到这么多。

    作者回复: 厉害,基本上重点都涵盖了

    15
    253
  • ant
    很有幸我们现在的架构师就是PPT架构师,我觉得他的优点就是懂了很多的概念,能说话到,可以忽悠住老板。缺点也很明显,就是他知道的都不是很深,比如曾经我们的搜索引擎原型,他并不能说出ES和solr的优缺点(当然我也不知道,平时用solr多点),最后我们选了ES,他给的原因就是朋友说的ES比solr好,后面搜索这里就交给我来搞了。我们是互联网项目,在重构的项目的时候他选择了jpa,这就导致变化需求的时候,查询这块比较麻烦,不灵活。 其实就像前面说的,每个技术存在就是合理的,只是每个有每个技术的使用点,架构师应该对常见的技术栈原理非常清楚,知道什么时候应该使用什么技术。 我理解的PPT架构师的特点就是知识点多,知道概念,能虎住老板,缺点就是技术栈不咋滴,特别是细节上。我觉得架构师应该帮助员工成长,而不是遇到问题就说这个问题我没遇到过,你上网搜索下解决方案。 初次留言,欢迎板砖

    作者回复: 架构师确实需要技术面宽,但别只知道技术名词,基本使用,关键原理,优缺点都需要了解

    2
    57
  • 蜗牛
    就一些新的技术引入,架构师需要做哪些技术验证,或者研究到什么深度以后,才认为该技术适合呢?

    作者回复: 基本原理,优点缺点,关键设计点,架构师至少要安装过,编写demo体验过,确定选型后,要进行性能和可用性测试例如es的索性设计就是关键设计点

    2
    54
  • 稳健的少年
    PPT架构师以脱离一线时间较久的领导居多吧。很多技术他们没有真正使用过,只是从各种途径得知很强大,其他公司(BAT)都在用,于是就在PPT中写入这种技术。缺点就是很容易做出貌似可行,深究其细节全是坑的设计。

    作者回复: BAT三个字是设计捷径,但也很多坑

    2
    39
  • 李志博
    认识一个工作10多年的架构师,天天只会说代码命名和注释的问题,从来没谈过什么高大上的架构,也从来没见他写过代码,有一次我来他来帮我看一个问题,他装没听见,走了……

    作者回复: 你们公司还要架构师么😂😂

    5
    37
  • Nick
    好吧,我就是ppt架构师😓 架构的层级看,有企业架构、业务架构、IT架构等,EA分业务、应用、技术、数据、基础设施等,不同的架构对架构师要求不一样,这个教程主要是讲技术架构,要求架构师对技术细节掌握较深,其他几种架构师虽然在写ppt但是真得不简单呢,知识面广度,行业理解,客户需求,抽象思维,心理揣摩,产品知识样样都要掌握

    作者回复: 你这种叫“系统分析师”或者“解决方案架构师”更贴切😄

    4
    24
  • 空档滑行
    真见过PPT架构师,1.自己基本不写代码,2.对某一项技术比较精通所以架构设计时尽量往这上面靠,比如对mysql很熟悉所以设计出的系统大量用到mysql 存储过程,3.设计出来的架构完全不考虑老系统兼容或者迁移难度

    作者回复: 架构师手里有一把锤子,然后所有的问题都是钉子😂

    2
    15
  • YiZhiYu
    没理解日志表在这里的意义,如果单纯是为了尾部追加,消息表也是尾部追加的操作吧,如果是为了记录消息,可消息表本身也记录了消息。 原因我能想到的作用,是记录消息存储队列,即哪个消息存在了哪个队列 另外,消息表中是不是应该添加一个消息消费确认字段,当消息被消费成功后,更改该字段,这也可以避免重复消费 以上,请华哥指点

    作者回复: 1. 不同队列存储在不同的表,不同的表存储位置不同,直接写表不是顺序操作 2. 消费确认字段不是跟消息绑定的,是和消费者绑定的,同一条消息,有的消费者消费了有的还没消费

    13
  • crazyone
    华哥,"日志表是尾部追加,性能高",这个具体实施细节能否讲解下。

    作者回复: 其实高性能的很多存储方案都是这样设计的,MySQL有Binlog,HBase有HLog,道理都是相通的。 在这个备选方案中,我们设计一个日志表,假设名称叫MQ_LOG,包含ID, time, queueName, message, publisher等几个字段,每次收到消息发布请求时先写这个表,每次都是表尾部追加。 如果不用自己设计的日志表,mysql的binlog也类似尾部追加,性能也不错,缺点就是没法自己灵活实现各种刷盘机制了。

    3
    9
  • L
    业务系统发布消息时,首先写入到日志表,日志表写入成功就代表消息写入成功;后台线程再从日志表中读取消息写入记录,将消息内容写入到消息表中。 业务系统读取消息时,从消息表中读取。 这里的设计是不是冗余了??

    作者回复: 日志表是尾部追加,性能高

    6
    9
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部