You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

93 lines
8.8 KiB
Markdown

2 years ago
# 架构专栏特别放送 | “华仔,放学别走!” 第2期
各位同学晚上好我是架构专栏的编辑Shawn。今天又到周五啦没错我又出来送福利了\[捂脸\]。
[“华仔放学别走”第1期](http://time.geekbang.org/column/article/7647)不知道你看了没有华仔回答了关于知识分享、理论与实践、专栏学习方法、推荐的参考书等几个问题希望你从中能够有所收获。今天是“华仔放学别走”第2期继续回答你所关注的问题然后展示出08 ~ 13期被选中的精选留言并给留言被选中的同学送出价值68元的专栏阅码。话不多说开始今天的问答环节。
Shawn有做公司架构/网站架构/App架构的同学这个专栏能帮助到他们吗
华仔:有的同学在学习了一段时间后跟我留言交流,说感觉专栏的内容好像比较适合做互联网后台架构,不太适合企业应用、客户端这类系统。其实这是一个误解,我之所以在前面花费很大篇幅来讲架构设计的目的、架构设计原则、架构设计流程等看起来比较偏理论的内容,而没有一上来就讲异地多活、高性能架构之类的怎么做,原因就在于**这是一套完整的架构设计理论体系**不管是企业应用还是客户端应用都可以按照这个设计理论体系去操作。我以手机App为例首先我们分析一下App的复杂度主要来源是什么通常情况下App的主要复杂度就是可扩展因为要不断地开发新的需求高性能和高可用也涉及高性能主要和用户体验有关高可用主要是减少崩溃。其次再看App的架构需要遵循架构设计原则么答案是肯定需要。刚开始为了业务快速开发可能用“原生+H5”混合架构后来业务发展功能更复杂了H5可能难以满足体验架构又需要演进到“纯原生”如果业务再发展规模太庞大则架构又可能需要演进到“组件化、容器化”。以上通过手机App的为例说明这套架构设计理论是通用的有兴趣的同学可以按照这种方式分析一下企业应用会发现这套理论也是适应的。
Shawn讲讲你总结“架构设计三原则”的过程吧
华仔“架构设计三原则”是综合各方面的信息和思考得来的。首先是我自己的经验包括成功的经验和失败的教训其次是分析了很多业界的架构演讲和技术发展历史第三是看了一些关于技术本质的书籍而受到的启发例如《技术的本质》《系统之美》等。其实最初整理的架构设计原则有10多条但我觉得10多条太多了不聚焦也不利于理解因此去芜存菁最终得到了“架构设计三原则”这三个原则是最重要也是最核心的。
如下是我原来整理的设计原则可以看到一共有14条
![](https://static001.geekbang.org/resource/image/3b/52/3b9c59fa4b921f6d62530cfe3eb74f52.jpg)
Shawn“PPT架构师”的口头禅是“细节不讨论”一个优秀的架构师需要对细节有多少考虑呢
华仔这是一个非常好的问题也是很多同学困惑的问题我分享一下我的做法以我学习Elasticsearch为例具体的做法是
1. 搭建一个单机伪集群,搭建完成后看看安装路径下的文件和目录,看看配置文件有哪些配置项,不同的配置项会有什么样的影响。
2. 执行常用的操作,例如创建索引,插入、删除、查询文档,查看一下各种输出。
3. 研究其**基本原理**,例如索引、分片、副本等,研究的时候要多思考,例如索引应该如何建,分片数量和副本数量对系统有什么影响等。
4. 和其他类似系统对比例如Solr、Sphinx研究其**优点、缺点、适用场景**。
5. 模拟一个案例看看怎么应用。例如假设我用Elasticsearch来存储淘宝的商品信息我应该如何设计索引和分片。
6. 查看业界使用的案例,思考一下别人为何这么用;看看别人测试的结果,大概了解性能范围。
7. 如果某部分特别有兴趣或者很关键可能去看源码例如Elasticsearch的选举算法我目前还没看^\_^)。
8. 如果确定要引入,会进行性能和可用性测试。
这样一套组合拳下来,基本上能够满足在架构设计时进行选型判断,而且花费的时间也不多。我并不建议拿到一个系统一开始就去读源码,效率太低,而且效果也不好。
Shawn谈谈架构师沟通能力的重要性吧
华仔:架构师是业务和技术之间的桥梁,同时通常情况下还会确定整体项目的步骤。因此,架构师的沟通能力非常重要,既要说得动老板,让老板支持自己的设计决定;又要镇得住技术人员,让技术人员信服自己的设计选择;同时还要能够理解业务,结合业务不同发展阶段设计合适的架构,所以也要参与产品和项目决策。由于架构设计过程中存在很多判断和选择,而且不一定都有明确量化的标准,因此不同的人有不同的看法是普遍情况。这种情况下架构师既需要专业能力过硬,又需要具备良好的沟通技巧,才能促使业务、项目、技术三方达成一致。
当然,**架构师的核心能力还是技术能力,过硬的技术才是良好沟通的基础**,否则单纯靠沟通技巧甚至花言巧语,一次两次可能奏效,但后面被打脸打多了,也就没人信任了。
Shawn有同学留言说给企业做项目甲方会不顾业务需要只要是业界流行的技术就要求在项目中采用这种情况下怎样才能符合“架构设计三原则”
华仔首先业务第一先把订单签下来才有后面的架构设计如果硬要说甲方的要求不合理不满足“架构设计三原则”结果订单都拿不到那是没有意义的。其次这种情况我把它归为“架构约束”即这不是架构师能够选择的而是架构师必须遵守的因此这里不需要使用“架构设计三原则”来判断。第三这种情况下架构师还是可以应用“架构设计三原则”来指导架构设计比如说客户要求采用DockerDocker的网络模式有5种host模式使用起来比bridge模式简单那我们就用host模式如果客户再要求需要对Docker进行统一管理那我们是自己研发Docker管理平台还是直接用Kubernetes呢按照简单原则来说肯定用Kubernetes了。
通过这个示例也可以看出,“架构设计三原则”主要是指架构师在选择和判断时采取的指导原则;但如果是架构的基本需求或者约束必须被满足时,架构师此时的选择是采取什么样的方案能够更好的满足这些需求和约束。
## 留言精选
![](https://static001.geekbang.org/resource/image/4b/a3/4b3f1ab66a7c470970c67da62ec99da3.jpeg)
华仔:有个懂技术的好老大是一件多么幸福的事情:)
* * *
![](https://static001.geekbang.org/resource/image/7c/9c/7ce774f26c16292a596ac4489c60369c.jpeg)
华仔有钱也不能任性微软95年也不可能开发出Windows 10操作系统业务量大了重构甚至重写那是自然而然的不会浪费也不会导致错失产品机会Windows、Android、淘宝、QQ都是这么过来的。
* * *
![](https://static001.geekbang.org/resource/image/40/8c/402a833915524ab1b572da8ddc34ab8c.jpeg)
华仔:终于明白了我一开始就提架构设计的核心目的的良苦用心了吧
* * *
![](https://static001.geekbang.org/resource/image/06/bf/06fa4a874cda142e768f64260087a4bf.jpeg)
华仔实现起来细节较多但没有想象的那么复杂一般的公司如果有人力的话做一个简单够用的消息队列不难用MySQL做存储的话不到1万行代码就可以搞定。
* * *
![](https://static001.geekbang.org/resource/image/48/d7/48e3036370c23ad5cd84b5aeb7a48fd7.jpeg)
华仔:如有雷同,实属巧合,确认过眼神,我不是你们公司的人 ^\_^
* * *
![](https://static001.geekbang.org/resource/image/9a/6e/9ad8b84a03ab5f9679e0596216f4f56e.jpeg)
华仔:架构师确实需要在技术广度和技术深度两方面都要兼顾,但如何把握技术深度这个“度”,不同架构师有不同的理解,但千万不能说“细节不讨论”“你上网搜”,这样会没有技术公信力。
* * *
最后,再次恭喜@Tony、@Michael、@空档滑行、@bluefantasy、@东、@ant也感谢写下留言的每位同学。欢迎你在这期“华仔放学别走”留下你的问题业务、职场、职业规划等不限主题可以和华仔一起聊聊专栏以外的话题。