从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 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开始学架构
登录|注册

46 | 架构重构内功心法第二式:合纵连横

李运华 2018-08-11
上一期我给你讲了我的架构重构内功心法的第一式:有的放矢,需要架构师透过问题表象看到问题本质,找出真正需要通过架构重构解决的核心问题,而不是想着通过一次重构解决所有问题。
今天我来传授架构重构内功心法的第二式:合纵连横

合纵

架构重构是大动作,持续时间比较长,而且会占用一定的研发资源,包括开发和测试,因此不可避免地会影响业务功能的开发。因此,要想真正推动一个架构重构项目启动,需要花费大量的精力进行游说和沟通。注意这里不是指办公室政治,而是指要和利益相关方沟通好,让大家对于重构能够达成一致共识,避免重构过程中不必要的反复和争执。
一般的技术人员谈到架构重构时,就会搬出一大堆技术术语:可扩展性、可用性、性能、耦合、代码很乱……但从过往的实际经验来看,如果和非技术人员这样沟通,效果如同鸡同鸭讲,没有技术背景的人员很难理解,甚至有可能担心我们是在忽悠人。
例如:
技术人员说:我们系统现在的可扩展性太差了,改都改不动!
产品人员想:咦,可扩展性,和扩胸运动有关吗?扩展什么呢?怎么会改不动呢?不就是找个地方写代码嘛……
技术人员说:我们的可用性太差,现在才 3 个 9,业界都是 4 个 9!
项目经理想:什么是 3 个 9,三九感冒灵?4 个 9 和 3 个 9 不就是差个 9 嘛,和可用有什么关系……
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(21)

  • 李奋斗
    1 需求相对明确,周期明确,项目经理去沟通比较合适;架构重构,可深可浅,能宽能窄,亦长亦短,有很多不确定的东西,在沟通中又有很多技术专业性、细节性的东西,架构师去合适
    2 按时交付项目是项目经理的主要诉求,架构合理演进是架构师的主要诉求
    3 架构重构,有时候项目经理也在被游说的范围内

    作者回复: 非常正确,架构重构的很多事情技术性太强,只有架构师能够讲清楚

    2018-08-11
    29
  • 海滨
    首先项目经理是对项目整体进度负责的,从职责上来看项目经理大多是反对系统重构的,因为重构或多或少会影响项目进度;其次就算有少部分项目经理有较高的思想觉悟,由于对当前系统重构的必要性和痛点认知的不够深刻,也很难大力的去推进系统重构。对于系统重构感受最深,需求最强烈的是谁?是架构师,架构不合理开发痛苦,架构师就会被责难,因此架构师最有动力也最适合去推进系统重构。

    作者回复: 理解深刻,你是有故事的人吧😄

    2018-08-13
    9
  • Adun Ton
    李老师这两期讲重构方面的内功心法,非常经常和有收获。
    讲一下自己遇到的几个案例:
    1. 有一个健康的外部环境很重要,之前一家公司销售跟客户过度承诺,同时展开软件项目的客户又多,所有的研发资源都消耗在这些项目上,应付时间点和需求变更都很吃力,完全没有精力做重构,造成恶性循环,代码质量越来越差,随着人员流动产品里面谁都不知道干嘛的代码越来越多;
    2. 有一个懂技术的老大很幸运,之前另一家公司,产品做到一定规模需要安排时间做重构,跟老板和销售负责人沟通如果不做重构,后面新功能开发和架构改造容易产生问题,得到的答复是你们研发团队的工作就是做好开发工作,优化的这些事情要在周期内完成,完不成就加班做,让大家积极性受打击;
    3. 跟非技术部门沟通有时可能简单粗暴一些效果反而比较好。跟非技术部门沟通有时不容易,比如工程、销售团队。你问预期的访问量多少,答曰系统能支持的越高越好,你问希望交付的时间,答曰越快越好。后来索性做个表格,关键功能和性能参数后面直接关联对应的时间,你自己选,自动加出来一个包含一定缓冲的人日,低于这个时间实现不了,这样还能更简单的在这些方面达成一致。

    作者回复: 第2是关键,有了2,其它都好说,我们也遇到你说的情况,原话:技术优化是你们自己考虑的事情,我只管业务实现😂😂

    2018-08-12
    6
  • 刘畅
    感觉这章写的很好,现在也在慢慢体会到这个道理了,要以数据为导向,要给出明显的收益,不然做了也是瞎做。。。

    现在做方案设计的时候,都会阐述业务背景,分析现状的不足之处,给出多种方案选择,成本效率的折中,定下方案,给出预期收益~

    作者回复: 沟通就是要让人看得懂嘛😄

    2018-08-12
    5
  • 文竹
    之前有看到老师评论说架构师需要具有5项技能, 一下子找不到了,请问这5项是?

    由于架构重构是与纯技术相关的,项目经理很难理解技术,并将技术转换为通俗易懂的话。如果架构师负责转换技术为易懂话语,项目经理进行游说和推动,中间会有更大的沟通成本和信息不同步问题,交由架构师闭环处理为佳。

    作者回复: 应该是:沟通,判断,技术,管理,决策这几个吧😀

    2018-08-26
    3
  • krugle
    soa还有必要学习吗

    作者回复: 不建议,传统企业的技术也向互联网靠拢了

    2018-08-13
    3
  • 孙振超
    架构师是技术岗位,但想把新架构设想落地就需要工程师去实施,如果自己同时带团队并且只需要自己团队的工程师去参与就比较容易;如果自己只有建议权、还需要其他团队配合的情况下,就要发挥各种软实力了,合纵连横、见缝插针、各种布道游说,才能把架构落地,要不然空有一肚子才华无法开花结果。

    作者回复: 架构师要求高啊😄

    2018-10-08
    2
  • 小胖狗
    架构师的软技能篇。😁😁😁

    作者回复: 这只是架构重构用到的,软技能很多,有的读者建议我写另外一个专栏,但我不太会写这类软技能😀

    2018-08-13
    2
  • JasonZ
    李老师,最近遇到一个架构问题。我们是微服务架构。有一个配置中心A系统。现在所有的上层系统都是依赖这个A系统。导致A系统的压力加大,一旦A系统被某一个sql拖垮了,导致上游系统接口超时。影响全局。那应不应该把读DB的请求让上游的系统自己去捅库?还有应该全部调用A系统接口?

    作者回复: 配置中心可以做成读写分离的,因为配置不会经常边

    2019-01-13
    1
  • 拉欧
    项目经理只能站在项目的角度思考问题,许多技术难点他们既不懂也讲不明白,在对程序员说话时也会出现鸡同鸭讲的情况(我就遇到过);架构师的职责或者说牛逼在于一个问题,可以从技术角度搞定研发,也可以从业务角度搞定产品

    作者回复: 所以架构师工资高,哈哈😄

    2018-09-18
    1
  • 寒星
    看这情况,我这种既做过项目管理,又做架构设计的是不是更有优势了啊😄

    作者回复: 肯定的,做过项目管理的程序员才是好的架构师😄👍👍

    2018-08-13
    1
  • godtrue
    课后思考及问题

    架构师不是技术岗位吗,为何还要做这些事情,沟通和推动的事情让项目经理做就可以了!你怎么看这个观点?
    我所见的事实和华仔讲的恰恰相反,这可能和小组结构和角色定位相关。我们架构师,主要工作据我了解如下:
    第一代码评审,除页面外基本都让他看看写的是否OK
    第二疑难问题解决,各种奇怪问题可以找他一起看
    第三技术选型支持,提供方案供领导选择
    第四大促或者平时基础架构部推动的事情,他分配到各组执行
    第五人员面试,一面是高工,他主要负责二面
    第六对外撕技术方案提供,比如:部门间合作有些事让我们做,他需要判断具体方案是否可行
    第七技术探索,如果要用新技术他会先实验实验,调研一下,宣讲一下,然后交给具体人员实施

    我的观点是视情况而定,技术相关的事情架构可以推动沟通,不过其他的事情比如:啥时候联调,啥时候上线,需要项目经理来推动沟通了。
    合纵连横的合作技巧是通用的,不过具体是谁负责,是事环组过来决定的。

    1:本文核心观点
    老师你太逗啦!列举的场景能让我笑一个早上😊
    1-1:合纵——我的理解是,统一战线,将朋友搞得多多的,敌人弄得少少的,越多人支持一件事越容易搞定。
    沟通技巧——在沟通协调时,将技术语言转换为通俗语言,以事实说话,以数据说话,是沟通的关键!

    1-2:连横——我的理解,其实和合纵本质一样,区别在于结盟的对象不同。
    拉人技巧——换位思考、合作双赢、关注长期。

    作者回复: 项目经理搞不定技术判断和取舍

    2019-09-05
  • 微风
    我能说架构师就是个适配器吗?呃,其实一直认为架构师是个很神圣的岗位:军师。

    作者回复: 架构师就是系统的军师😂

    2018-09-29
  • petit_kayak
    同时作为架构师、设计师和项目经理(不同的项目),我很理解沟通中的对方,而且就像老师说的,架构师常常要做一些类似于项目经理或者产品经理的工作,因为架构其实就是一个组织内部“销售”的产品。
    2018-09-13
  • 波波安
    我感觉问题就在于,都想自己改动调整最少。

    作者回复: 确实如此😀😀这就需要架构师的推动能力了

    2018-09-05
  • 忠厚
    再牛逼的架构也得落地才能体现出架构师的价值,用嘴做架构只能是纸上谈兵,架构师自己不去推动,那架构就不能落地或者不能按自己的想法落地,那架构的价值何在,架构的价值也会大打折扣

    作者回复: 架构师应该是最明白价值的

    2018-08-24
  • W_T
    我对这篇文章的总结就是:站在对方的角度思考问题,挠他的痛点!
    2018-08-16
  • 云学
    技术驾驭到一定程度就开始驾驭人了,哈哈

    作者回复: 必须的,有人的地方就有江湖😄

    2018-08-13
  • feifei
    架构师关注的是整体的系统把控,沟通和推动在重构这件事情上需要架构师来协调,项目整体性重构项目经理未必能讲清楚,需要架构师来协调相关方,这些工作本身就是架构师的工作的一部分
    2018-08-13
  • zengjian
    快到尾声了,除了学到很多技术点,还学会了如何拍照选图,比如这期的小姐姐

    作者回复: 感谢编辑选图😄😄

    2018-08-11
收起评论
21
返回
顶部