架构专栏特别放送 | “华仔，放学别走！” 第2期
何潇 & 李运华
该思维导图由 AI 生成，仅供参考
各位同学，晚上好，我是架构专栏的编辑 Shawn。今天又到周五啦，没错，我又出来送福利了[捂脸]。
“华仔，放学别走”第 1 期不知道你看了没有，华仔回答了关于知识分享、理论与实践、专栏学习方法、推荐的参考书等几个问题，希望你从中能够有所收获。今天是“华仔，放学别走”第 2 期，继续回答你所关注的问题，然后展示出 08 ~ 13 期被选中的精选留言，并给留言被选中的同学送出价值 68 元的专栏阅码。话不多说，开始今天的问答环节。
Shawn：有做公司架构 / 网站架构 /App 架构的同学，这个专栏能帮助到他们吗？
华仔：有的同学在学习了一段时间后跟我留言交流，说感觉专栏的内容好像比较适合做互联网后台架构，不太适合企业应用、客户端这类系统。其实这是一个误解，我之所以在前面花费很大篇幅来讲架构设计的目的、架构设计原则、架构设计流程等看起来比较偏理论的内容，而没有一上来就讲异地多活、高性能架构之类的怎么做，原因就在于这是一套完整的架构设计理论体系，不管是企业应用，还是客户端应用，都可以按照这个设计理论体系去操作。我以手机 App 为例，首先，我们分析一下 App 的复杂度主要来源是什么？通常情况下，App 的主要复杂度就是可扩展，因为要不断地开发新的需求；高性能和高可用也涉及，高性能主要和用户体验有关；高可用主要是减少崩溃。其次，再看 App 的架构需要遵循架构设计原则么？答案是肯定需要。刚开始为了业务快速开发，可能用“原生 +H5”混合架构；后来业务发展，功能更复杂了，H5 可能难以满足体验，架构又需要演进到“纯原生”；如果业务再发展，规模太庞大，则架构又可能需要演进到“组件化、容器化”。以上通过手机 App 的为例说明这套架构设计理论是通用的，有兴趣的同学可以按照这种方式分析一下企业应用，会发现这套理论也是适应的。
Shawn：讲讲你总结“架构设计三原则”的过程吧？
华仔：“架构设计三原则”是综合各方面的信息和思考得来的。首先是我自己的经验，包括成功的经验和失败的教训；其次是分析了很多业界的架构演讲和技术发展历史；第三是看了一些关于技术本质的书籍而受到的启发，例如《技术的本质》《系统之美》等。其实最初整理的架构设计原则有 10 多条，但我觉得 10 多条太多了，不聚焦也不利于理解，因此去芜存菁，最终得到了“架构设计三原则”，这三个原则是最重要也是最核心的。
如下是我原来整理的设计原则，可以看到一共有 14 条：
Shawn：“PPT 架构师”的口头禅是“细节不讨论”，一个优秀的架构师，需要对细节有多少考虑呢？
华仔：这是一个非常好的问题，也是很多同学困惑的问题，我分享一下我的做法，以我学习 Elasticsearch 为例，具体的做法是：
搭建一个单机伪集群，搭建完成后看看安装路径下的文件和目录，看看配置文件有哪些配置项，不同的配置项会有什么样的影响。
执行常用的操作，例如创建索引，插入、删除、查询文档，查看一下各种输出。
研究其基本原理，例如索引、分片、副本等，研究的时候要多思考，例如索引应该如何建，分片数量和副本数量对系统有什么影响等。
和其他类似系统对比，例如 Solr、Sphinx，研究其优点、缺点、适用场景。
模拟一个案例看看怎么应用。例如，假设我用 Elasticsearch 来存储淘宝的商品信息，我应该如何设计索引和分片。
查看业界使用的案例，思考一下别人为何这么用；看看别人测试的结果，大概了解性能范围。
如果某部分特别有兴趣或者很关键，可能去看源码，例如 Elasticsearch 的选举算法（我目前还没看 ^_^）。
如果确定要引入，会进行性能和可用性测试。
这样一套组合拳下来，基本上能够满足在架构设计时进行选型判断，而且花费的时间也不多。我并不建议拿到一个系统一开始就去读源码，效率太低，而且效果也不好。
Shawn：谈谈架构师沟通能力的重要性吧？
华仔：架构师是业务和技术之间的桥梁，同时通常情况下还会确定整体项目的步骤。因此，架构师的沟通能力非常重要，既要说得动老板，让老板支持自己的设计决定；又要镇得住技术人员，让技术人员信服自己的设计选择；同时还要能够理解业务，结合业务不同发展阶段设计合适的架构，所以也要参与产品和项目决策。由于架构设计过程中存在很多判断和选择，而且不一定都有明确量化的标准，因此不同的人有不同的看法是普遍情况。这种情况下架构师既需要专业能力过硬，又需要具备良好的沟通技巧，才能促使业务、项目、技术三方达成一致。
当然，架构师的核心能力还是技术能力，过硬的技术才是良好沟通的基础，否则单纯靠沟通技巧甚至花言巧语，一次两次可能奏效，但后面被打脸打多了，也就没人信任了。
Shawn：有同学留言说，给企业做项目，甲方会不顾业务需要，只要是业界流行的技术就要求在项目中采用，这种情况下怎样才能符合“架构设计三原则”？
华仔：首先，业务第一，先把订单签下来，才有后面的架构设计，如果硬要说甲方的要求不合理，不满足“架构设计三原则”，结果订单都拿不到，那是没有意义的。其次，这种情况我把它归为“架构约束”，即这不是架构师能够选择的，而是架构师必须遵守的，因此这里不需要使用“架构设计三原则”来判断。第三，这种情况下，架构师还是可以应用“架构设计三原则”来指导架构设计，比如说客户要求采用 Docker，Docker 的网络模式有 5 种，host 模式使用起来比 bridge 模式简单，那我们就用 host 模式；如果客户再要求需要对 Docker 进行统一管理，那我们是自己研发 Docker 管理平台，还是直接用 Kubernetes 呢？按照简单原则来说，肯定用 Kubernetes 了。
通过这个示例也可以看出，“架构设计三原则”主要是指架构师在选择和判断时采取的指导原则；但如果是架构的基本需求或者约束必须被满足时，架构师此时的选择是采取什么样的方案能够更好的满足这些需求和约束。
留言精选
华仔：有个懂技术的好老大是一件多么幸福的事情：）
华仔：有钱也不能任性，微软 95 年也不可能开发出 Windows 10 操作系统；业务量大了重构甚至重写那是自然而然的，不会浪费也不会导致错失产品机会，Windows、Android、淘宝、QQ 都是这么过来的。
华仔：终于明白了我一开始就提架构设计的核心目的的良苦用心了吧 ：）
华仔：实现起来细节较多，但没有想象的那么复杂，一般的公司如果有人力的话，做一个简单够用的消息队列不难，用 MySQL 做存储的话，不到 1 万行代码就可以搞定。
华仔：如有雷同，实属巧合，确认过眼神，我不是你们公司的人 ^_^
华仔：架构师确实需要在技术广度和技术深度两方面都要兼顾，但如何把握技术深度这个“度”，不同架构师有不同的理解，但千万不能说“细节不讨论”“你上网搜”，这样会没有技术公信力。
最后，再次恭喜@Tony、@Michael、@空档滑行、@bluefantasy、@东、@ant，也感谢写下留言的每位同学。欢迎你在这期“华仔，放学别走”留下你的问题，业务、职场、职业规划等不限主题，可以和华仔一起聊聊专栏以外的话题。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文是“华仔，放学别走！”系列的第2期，主要围绕架构设计和技术领域展开问答和讨论。华仔分享了关于架构设计对于公司架构、网站架构和App架构的适用性，以及架构设计三原则的总结过程。他还谈到了架构师对细节的考虑、沟通能力的重要性，以及如何在面对甲方要求采用业界流行技术时符合架构设计三原则。此外，文章还包括了一些留言精选，展示了读者对于华仔观点的反馈和讨论。整体而言，本文涵盖了架构设计的理论与实践，以及架构师在实际工作中所面临的挑战和应对策略，适合对技术架构感兴趣的读者阅读。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《从 0 开始学架构》，新⼈⾸单¥68
《从 0 开始学架构》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(15)
- 最新
- 精选
爱吃技术的🐱企业高速发展过程中，技术总是短期内被高估，长期被低估，一位15年IT老兵的切身感受！作者回复: 我理解是短期被牺牲，长期被低估😂😂
2018-06-0231
Sic Pavis老师好，我想咨询一个职业规划的问题。 先简单介绍下： 刚毕业的时候找的工作岗位比较闲，一两年下来没做多少事情。自己也不是个很自觉的人，有些荒废。现在一转眼毕业五年了，技术水平还是不高。 现在比较急于找到方向去努力，但是悟性有限。和团队里的资深人士交流后还是抓不住重点。现在做事情知道思考知道简单总结，但是不知道如何将这些量变积累成质变。希望老师有空指惑，谢谢！作者回复: 大部分人还不到拼悟性的时候，你觉得自己抓不住重点，主要还是积累不够，清点一下自己看过的书，做个的项目，研究过的系统，看看到底有多少。 另外可能是你的学习不系统，只知道点，不知道面和体，别人稍微扩散一下就把你卡住了
2018-08-22416
better想问下华哥，有没有技术方案相关的文章详解及文档模板呢，比如说现在有业务场景需要预研引入新技术，但是这种新技术在宽度上有其他同类型的，这种情况下，这种技术选型有哪些方面需要考虑，最终选定了其中一种后，预研的时候又该做什么，最终形成的预研文档需要呈现出哪些内容，想学习这方面的知识作者回复: 预研文档一般包括如下几部分内容： 1）方案本质：本质是指方案的核心原理，例如MySQL是OLTP、Clickhouse是OLAP、HBase是sorted map、Redis是 data structure store，本质决定了方案的基本原理和大概的实现方案，redis再怎么牛逼，都不能完全替代mysql，这就是本质决定的。 2）总体架构：技术方案由哪些部分组成，每部分的作用是什么，目的在于整体了解方案的复杂度、如何部署等 3）核心能力：核心能力决定了方案的应用场景，理解核心能力才能知道具体怎么应用。 4）优缺点：与已有方案对比的优缺点 5）典型场景测试：包括性能测试、可靠性测试、压力测试等，按照你自己的业务来设计场景。
2021-01-3028
飘然1.看得书多，加上实践，技术能力是不是就能不断提升。如果看了书过一段就忘了，或者看了一些书，技术能力还是感觉没有提升，这种情况怎么办，还是看书少的原因？ 2.技术人员，除了提升技术还需要提升哪些方面？ 3.对于工作8-9年，技术有些薄弱，未来3-5年，对于晋升和提升自己有什么常见的策略？作者回复: 多总结多实践
2019-04-076
Panda目前公司的项目并发量不大，项目比较复杂，逻辑复杂度高，多个项目耦合强，请老师分享一下这种情况下的架构 应该怎么做作者回复: 可扩展章节有讨论
2018-06-046
钱嗯，我勤奋有毅力，因为无知错过一些，现在我反应过来了，我相信自己会越来越好。作者回复: 加油
2019-09-044
undefined18的专栏21看 三年陈酿作者回复: 学习什么时候都不晚 ：）
2021-03-313
张国胜之前在公司遇到的问题是，拿演化当挡箭牌，导致根本没有架构就直接开干。演化优于过度设计，我的理解是，演化要站在上帝视角，能看到一定程度的将来，然后从多种设计方案中选择最基本的那一种，就像有了最小子集，这是后续演化的基石，最好不要推到重来，如果要重来也要尽早。而不能无设计作为起点。作者回复: 是的，演化优于过度设计不是说不要设计，而是不要过度设计
2018-06-293
刚见课程真好，打开了一个广阔的世界作者回复: 恭喜你学完了，继续加油
2021-06-211- Geek_b7f019老师我也在阿里，看的也多，但是缺少体系化，缺少总结沉淀，这个系列醍醐灌顶
作者回复: 我已经离开阿里了 ：）
2021-12-09
收起评论
