从0开始学架构
李运华
资深技术专家
立即订阅
38893 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

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

李运华 2018-05-26
完成备选方案的设计和选择后,我们终于可以长出一口气,因为整个架构设计最难的一步已经完成了,但整体方案尚未完成,架构师还需继续努力。接下来我们需要再接再励,将最终确定的备选方案进行细化,使得备选方案变成一个可以落地的设计方案。所以今天我来讲讲架构设计流程第 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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(72)

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

    目前就想到这么多。

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

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

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

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

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

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

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

    2018-05-31
    17
  • Mars
    华哥,这个专栏讲解架构设计的概念、设计原则、设计规则等主演偏重理论上的设计。对很多没有亲身经历过架构设计的程序猿又想踏入架构师之旅,文章阅读之后文中讲的理论基本也都能懂,但要自己真正落地恐怕非常难?要是这个专栏之后华哥能再写一个专栏,就针对“前浪微博”的消息队列从设计前期、详细设计、框架搭建、开发实现、最后测试部署的一套流程的专栏。让我们亲自动手感受从系统设计到最终系统上线的一套完整流程。相信会受很多人欢迎及订阅。
    2018-06-04
    15
  • 蜗牛
    就一些新的技术引入,架构师需要做哪些技术验证,或者研究到什么深度以后,才认为该技术适合呢?

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

    2018-05-26
    15
  • 我的名字叫浩仔丶
    我们的架构师连PPT都懒得做。
    2018-05-30
    7
  • 空档滑行
    真见过PPT架构师,1.自己基本不写代码,2.对某一项技术比较精通所以架构设计时尽量往这上面靠,比如对mysql很熟悉所以设计出的系统大量用到mysql 存储过程,3.设计出来的架构完全不考虑老系统兼容或者迁移难度

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

    2018-05-26
    7
  • 燃烧的阿布
    业务系统发布消息时,首先写入到日志表,日志表写入成功就代表消息写入成功;后台线程再从日志表中读取消息写入记录,将消息内容写入到消息表中。

    业务系统读取消息时,从消息表中读取。


    这里的设计是不是冗余了??

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

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

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

    2018-11-28
    1
    4
  • bluefantasy
    请教华仔:您说的”日志表是尾部追加,性能高”,这个日志表是用myisam存储引擎吗?我刚刚查了文档innodb只有系统表空间和日志文件是序列化写呀,普通表文件都是随机写。 请指教。

    作者回复: 这个日志表是我们自己设计的,不管是innodb还是myisam都可以,我说的尾部追加是指我们只会往日志表插入数据,类似kafka的文件尾部追加一样

    2018-05-28
    4
  • Jolie Liang
    对于PPT架构师,总结有以下几个特点:
    1)整体思路照搬
    2)不能准确定位业务需要解决的痛点
    3)对所需技术的原理理解不深
    4)执行到后期,返工及补坑的工作比较多
    .......

    作者回复: PPT可以造火箭,实际实现只能造鞭炮

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

    作者回复: 其实高性能的很多存储方案都是这样设计的,MySQL有Binlog,HBase有HLog,道理都是相通的。

    在这个备选方案中,我们设计一个日志表,假设名称叫MQ_LOG,包含ID, time, queueName, message, publisher等几个字段,每次收到消息发布请求时先写这个表,每次都是表尾部追加。

    如果不用自己设计的日志表,mysql的binlog也类似尾部追加,性能也不错,缺点就是没法自己灵活实现各种刷盘机制了。

    2018-05-29
    3
  • Sylar.
    我也没有明白作者说的日志表尾部追加性能好,具体是什么操作,还望赐教,多谢了!
    2018-05-28
    3
  • 约书亚
    我理解的ppt架构师和大家不同,我理解的ppt架构师往往类似咨询公司的那种,要充分熟悉领域业务,有成熟方案经验,只要方案成功过就行,至于怎么落地就是你的事了。这种会有市场,主要还是对某些领域的整体摸得比较熟。
    今天这个方案,有一个日志消息表的目的,是为了把消费和写入操作带来的压力分开嘛?考虑到写和读的比例是11比10,所以日志表每个库只有一个?
    文章似乎没提具体如何记录消费者读取消息位置,这也是个关键trade off的点,决定了qos。下期会说?
    另外有个吹毛求疵的想法,自研发sdk往往比看起来的难,需要设计功力,有bug了如何及时分发新版本都是问题。选型时需要开发sdk的都是减分项。
    怎么看这都是消息队列擅长的场景,使用成熟三方实现成本会非常非常低,不能和运维大哥商量一下么?-_-

    作者回复: 1. 你说的一般叫系统分析师
    2. 日志表是尾部追加,写入性能高,日志表一个库只有一个
    3. sdk写稳定确实需要一段时间
    4. 运维大哥不怕每天维护,最怕出问题几个小时甚至几天都搞不定

    2018-05-26
    3
  • allen.huang
    PPT架构师,基本上是从网上找资料过来,没有根据业务中实际情况来进行验证,而确定了方案。是这样子吗?

    作者回复: 是的

    2018-12-25
    2
  • beiler
    请问备选设计方案和详细设计方案之间大概有多大的差别,是否有可参考案例

    作者回复: 第50篇的文档模板给了一个样例参考

    2018-09-06
    2
  • 平头哥
    ppt架构师就是挖好坑让小弟们跳,跳进去出不来了也没人救你,怪你能力有问题,太坑

    作者回复: 架构师这么爽呀😄

    2018-07-31
    2
  • 绿豆先生
    有个问题咨询下,选用ip_hash作负载均衡策略时,如果一台机器挂掉了,因为有对应ip机器上存储session的原因,如何保证整体的映射规则的平稳过渡呢

    作者回复: 如果保存在内存中,机器宕机就没法保证了,如果要保证,可以用缓存存储session

    2018-07-29
    2
  • 微leng
    看来ppt架构师还是很多的啊,应该推荐他们来看看老师的文章o(^o^)o
    2018-05-28
    2
收起评论
72
返回
顶部