那么贵的技术会议,真的能学到东西吗?

百家 作者:聊聊架构 2018-01-08 10:37:30
作者 | 周明耀
编辑 | 雨多田光
写在前面

前阵子作为旁听嘉宾参加了极客邦主办的全球架构师大会,才知道原来极客邦已经坚持了 10 年,正如优秀的架构师依靠坚持逐渐积累能力的成长方式,极客邦也是这么在践行的。

我认为架构师一般都是喜欢思考的人,既然喜欢思考,那一定有东西可以拿出来分享,不知道你有没有去参加这场架构师大会,有的话可以写出自己的思考,让大家看看你对于演讲嘉宾发言的理解,或者你自己的想法。

既然请大家讲讲看法,那就从我自己开始吧,结合现场的演讲主题、内容,我讲讲我感兴趣的话题。先声明,由于我的工作仅覆盖软件领域,所以本文仅针对软件领域技术进行描述,没有覆盖本次大会重要主题之一的 AI(人工智能),请谅解。

关于深度思考

霍泰稳的开场演讲里提到了现在比较流行的知识分享主题,提到了深度学习是一种方法,它是构建认知体系的一种方法。王坚博士更是认为当今已经没有讲师了,但是你可以从别人身上学习到很多。

我谈谈自己对于深度思考的理解和践行。我觉得技术能力是可以培养的,而且可能可以快速培养,只要这个人具备深度思考的能力,因为知识体系的建立一定是基于思考之上的,而不会是填鸭式的。

多年来我养成了一种习惯,或者说不得不养成这样的习惯,就是在夜深人静的时候,静静地思考一天下来的经历。白天,大部分时间是在异常忙乱中度过的,没有时间思考;夜色下来,一切归于宁静,望着窗外闪烁的路灯,可以静静地思考自己和世界,思考在自己从事的工作中发生的各种各样或大或小的事情,从中找出有意义的东西,做一点小小的思想享受。这种思考,对人是有益的。一个人做多了自己的职业活动,如果不调整,就会变得单一,思想也慢慢定向,没有开放式的思维方式。所以要在紧张的大脑和肢体活动之余,发现思维的新空间。

作为一名软件工程师,我的大部分时间都用在了这个领域,我也发现,生活上的几乎所有细节也可以在软件工程这个领域里找到对应点或面。此外,程序员也需要从产品、运营方面思考技术,这样才能不断开阔自己的思考方式。我之所以愿意把这些思想“沉淀”积累起来,不是因为它们有特别的价值,而是因为它们是在宁静的外界和宁静的内心状态下形成的,宁静致远,对于拥有技术愿景的程序员来说,这是一个值得追求的境界。

关于架构
什么是架构

既然是架构师大会,主题当然不能少了架构。霍泰稳先生认为架构师大会的参与者都是有多年经验的架构师,架构师如何提高自己的认识,需要理论上和实践上的积累、思考,以及沉淀,最后还是需要实践。

王坚博士说不要再用建筑描述软件行业的架构了。我觉得并不是因为建筑行业的架构设计和软件行业的架构设计没有关联,而是被引用了太多次,大家听得没有了感觉。此外,建筑行业的架构设计所需要解决的问题相对简单,没有太多针对人行为的描述方式,倒不如举一些人类生活中实际的例子。以人类社会体制为例,它本身是由法制、社会伦理双方面约束组成的,一个健壮的社会制度,本身具有自身扩展能力、容错能力,并且是不断向前发展的,软件的系统架构也是类似的。

回到会场,对于架构的精辟描述有以下这些:

  • 架构是系统的灵魂

  • 一个好的架构是包容所有好技术的基础

  • 架构特点,云计算是为了解决数据问题,因此架构是为了解决数据问题

  • 云计算首先需要解决计算效率问题,再去解决计算能力问题

  • 阿里飞天当初在做分布式数据中心,没有好的架构,不会发展

  • 架构是规则,让 AI 帮助我们,而不是毁灭人类

谈谈我对于架构的理解。是不是只有软件才有架构?我觉得不是的,以 Java9 来看,我觉得它就是针对 Java 语言的一次架构重构。Java9 的模块化系统有两大目标:

  • 1、模块化 JDK 本身;

  • 2、为应用程序的使用提供模块化系统。

模块化系统为 Java 语言和运行时环境引入了本地模块化概念,提供了强有力的封装。

在 Java9 之后,每一个 JAR 包都变成了一个模块,包括到其它模块的显式依赖。从下面这张图图可以看出,Application 调用了 JDK 的 java.sql 包。Java9 与之前的各个版本相比,是对自身的一次全方面重构,而不是语言方面的某一些特性升级。

微服务架构

微服务架构是当前的热门话题,本次大会当然也少不了它。

我认为,微服务的出现可以说是行业发展到一定阶段的必然产物。确切地说,微服务并不是一门技术,而是一种架构风格。你可以使用任何一门开发语言、任务一种框架来实现一个微服务。微服务容易开发、理解和维护,可以独立部署、独立伸缩,非常灵活。通过将单体应用分解成微服务,解决了复杂性问题。每个微服务负责处理单一的任务,微服务之间通过定义好的接口相互通信,最后组成一个庞大的微服务生态系统。

看似我们绕了一个大圈子,其实则不然。每个微服务就是一个独立运行的应用,分别由专门的团队负责开发,开发人员可以自由选择他们熟悉的技术,也可以采用最新的技术,而且可以快速做出变更。所以对于开发人员来说,微服务给他们带来了极大的自由度,同时极大地提升了开发速度。

每个微服务可以独立开发、独立部署,而不像单体应用那样牵一发而动全身。每个微服务可以独立演化,在快速做出变更后进行部署,如果有必要,每天可以进行多次部署,因为微服务体积小,所以构建时间短,部署起来也非常方便。

每个微服务都可以独立伸缩,可以根据具体情况为每个微服务部署不同数量的实例,也可以为不同的微服务选择不同的硬件。比如,对于不是很关键的微服务可以使用便宜的硬件,对于负载不是很高的微服务就可以少部署几个实例。而对于高负载的关键微服务则多部署一些实例,并使用更好的硬件。

不过,采用微服务架构的门槛其实是很高的。Martin Fowler 认为,一个公司要采用微服务,必须满足三个基本前提条件,即快速配置能力、基本的监控能力和快速部署能力。而除此之外,要成功实施微服务,还有其它很多重要的因素需要考虑。

对于微服务的实践,我的理解是小公司一般没有符合要求的基础设施来运行微服务,哪怕是很小规模的微服务。好的微服务架构需要稳定的基础设施,这样的基础设施一般都很复杂,需要专门的团队来负责运维。只有在面临伸缩性挑战并决定要转向微服务架构的公司才会为组建这些团队所要耗费的成本买单,一般的小公司没有足够的能力来维护这样的一个微服务生态系统。

况且,在公司发展的早期阶段,很难对系统的关键性功能进行组件化,因为新公司的应用一般不会有太多功能特性,也没有太多的功能需要被拆分成微服务。

回到会场现场。美团境内交易系统的融合实践中介绍交易系统的特点是大量依赖外部、被大量外部依赖,长事务处理,高可用、X 分钟不可用、故障,数据一致性要求高、客诉,数据量大、历史交易累积。进一步结合实际业务需求,分享了微服务架构的优化细节,微服务架构设计后把插件放入平台内部,变成本地调用架构方式,解决了服务之间的 RPC 交互问题。

大规模任务调度机制

腾讯嘉宾在分享大规模任务调度机制时提到了 Google 发布的 Borg、Omega 等论文,此外也提到了自己遇到的核心挑战包括异构性带来的挑战、宿主机和虚拟机分别带来的挑战。

我这里聊聊自己对于论文的理解。Borg 是什么?Borg 是一个集群管理器,它负责对来自于几千个应用程序所提交的 job 进行接收、调试、启动、停止、重启和监控,这些 job 将用于不同的服务,运行在不同数量的集群中,每个集群各自都可包含最多几万台服务器。Borg 的目的是让开发者能够不必操心资源管理的问题,让他们专注于自己的工作,并且做到跨多个数据中心的资源利用率最大化,如下图所示是 Borg 的总体架构。

Borg 系统的使用者将向系统提交包含了一个或多个任务的 job,这些任务将共享同样的二进制代码,并在一个单元中进行执行,每个 Borg 单元由多台机器组成。在这些单元中,Borg 会组合两种类型的活动:一种是例如 Gmail、GDocs、BigTable 之类的长期运行服务,这些服务的响应延迟很短,最多几百毫秒。另一种是批量处理的 job,它们无须对请求进行即时响应,运行的时间也可能会很长,甚至是几天。第一种类型的 job 被称为 prod job(即生产 job),它们相对于批量 job 来说优先级更高,后者被认为是非生产环境中的 job。生产 job 能够获得一个单元的 CPU 资源中的 70%,并且占用所有 CPU 数量的大约 60%,它们还能够分配到 55% 的内存,并占用其中的大约 85%。

可以说因为有了 Borg,才会有了现在的 Kubernetes。对属于同一服务的 job 的操控能力、一台机器多个 IP 地址、使用某种简化的 job 配置机制、使用 pods(其作用与分配额相同)、负载均衡、深度反思为用户提供调试数据的方式,这些都是 Borg 和 Omega(另一套机制)遇到的问题所对应的解决方案,在 Kubernetes 上都体现解决方案了。

分布式数据库

来自中兴的嘉宾分享了对于分布式数据库的架构设计,对于分布式数据库的要求他给出了下面这张图:

开始我的遐想了。假设请您设计一款去中心化的分布式系统,您觉得应该怎么来设计?

我如果收到这样的无中心设计需求,首先第一步是明确什么是无中心化?我认为,无中心化需求应该可以被分解为数据存储无中心化和读 / 写操作无中心化两个需求。

如果想要我们设计的系统同时支持这两个无中心化需求,我们设计的系统应该满足以下条件:

  • 数据需要均匀分布在集群内的每一个节点上;

  • 同一份数据需要支持在集群内多个不同的节点内存在;

  • 不存在固定的中心节点,也不存在仅保存在中心节点的集群元数据;

  • 集群内的通信架构是按照整个集群思维设计的,而不是按照中心化思维设计;

  • 通信消息需要某种机制确保互相之间知道最新的状态;

  • 需要有某种机制确保客户端请求读取的数据副本是最新版本的。

Cassandra 是无中心化的,每一个节点都可能担任协调者角色,也可能担任数据备份角色,这也意味着所有节点没有差异,也不会存在差异,因为所有行为都是按照规则约束的随机行为,因此可以认为所有节点本质上是没有差异的。

那么它是怎么做到的呢?首先通过 Gossip 协议让内部节点之间的消息传送方式实现同质化,即所有节点都被相同对待,互相交换信息,而不是将信息汇总于某一个或某几个特点的节点。其次通过 Snitch 机制解决了多个节点上数据副本的版本比较,确保在最短读取路径前提下返回最新版本的数据给客户端调用方。再者通过协调者机制可以动态确定一个节点作为数据链路的临时大脑,由它来发起、组织、汇总元数据的计算结果,并将真正的处理请求发送给明确的节点,所有节点理论上都可以作为协调者,所以也就实现了节点无差异需求。

最后通过环形数据分布、令牌机制、虚拟节点、数据分区以及数据复制策略等实现了数据的均匀分布,为无中心化实现提供了基础。从 Cassandra 的无中心化设计分析中可看出,没有哪一个设计可以通过单一功能实现,都是基于若干个复杂特性互相帮助的基础上实现的。

技术管理

技术管理主题也是每次架构师大会必然包含的内容,我讲两点我认为比较重要的,一是技术选型,二是 CTO 的工作职责。

技术选型

对于一名热爱技术的工程师来说,很容易出现非常热衷于使用新技术的情况,记得有一次和一位做平台应用的同事闲聊,他问我最近在搞什么,我说在研究 Hadoop,正在用 MapReduce 处理海量图片的智能分析,他一脸羡慕:“能搞新技术,真好!”。

作为一名工程师,我可以理解大家的心情,我们都是热爱尝试新技术、抛弃过时技术的人。但是首先得明确,到底技术是不是过时的,还是仅仅是你认为它过时了。

选择一个技术的最低标准是,技术的生命周期必须显著长于项目的生命周期。为什么需要确保所选择的技术不断前进?因为这个世界是发展的,科技发展更是非常快速,你可以看看,所有的成功的科技公司都是因为跑在了别人前面,而不是慢悠悠的工作态度,这就是科技界的残酷,也正是为什么 FaceBook 办公室里贴着:“要么做到最好,要么死亡”。

技术的前进不仅仅取决于它本身,而是和大环境发展、上下游用户也密切相关。比如 AI,60 年代其实就已经提出了相应概念,为什么直到今年才进入发展元年?因为芯片的计算效率、数据样本规模没有达到要求。而 Functional Language 为什么这么多年一直默默无闻,而从前几年开始逐渐盛行?因为机器学习来了,AI 来了,它们有了用武之地。

总的来说,你需要使用你所选择的软件技术,快速地实现应用程序的构建。记住一句话:好的技术栈永远跑在用户需求前面。

CTO 工作职责

CTO 需要能够利用手中的技术手段,更好地为企业的业务服务,解决实际的问题,推动企业的技术、产品落地。一位我认识的高管曾经这样说过:“没有落地,别谈技术梦想”。

Amazon 的 CTO Vogels 博士是一位杰出的 CTO,他在最近的一次采访里介绍了 Amazon 在机器学习领域的技术布局。据他介绍,在过去的 20 年间,已经有多达数千位软件工程师在 Amazon 参与了机器学习项目。他认为 Amazon 是一家在业务领域使用人工智能和机器学习技术的前沿公司,也正是因为不断地创新,才会让业务发展不断突破瓶颈。

多说一句,光有敏锐的商业眼光还不够,你还需要了解技术前进所需要的外部环境。CTO 只有具备了产品经理的思维方式,才能更多地从业务角度思考技术落脚点和时机,听着很容易,其实很难做到,一名优秀的产品经理本身就是可遇不可求的了,需要环境、经历的历练,更别说敏锐的商业头脑,这更是需要大量的积累、思考,也许还需要一些失败,才能逐渐让技术人员具有这些能力,进而成为优秀的 CTO。

试想,一名优秀的中场指挥官,没有开阔的视野和敏锐的反应,怎么能够承担起整支球队的战术指挥官和实践者职责呢。

写在后面

创新是人类的自信。年轻人了不起的地方是明知道干不成,依然会去干。挑战永远都是留给年轻人的,未来才会离我们更近。

——王坚 2017 年 12 月 ArchSummit 大会

转换到架构师角色,我的理解是:架构师做的工作本身就是人类自信的体现,为什么呢?因为它很难,并且一直在不断地逼迫着架构师学习、实践。架构师了不起的地方是明知道这么设计会很难实现,也可能会承担很大的风险和责任,但是依然会去挑战,因为他们知道,只有挑战,才有未来。挑战永远是留给优秀的架构师的,未来的道路是由架构师自己走出来的,谨以此文献给所有在路上的架构师们。

作者介绍

周明耀,工学硕士,13 年软件研发经验,近 10 年技术团队管理经验,4 年分布式计算、大数据技术经验。出版书籍包括《大话 Java 性能优化》、《深入理解 JVM&G1 GC》、《技术领导力 - 码农如何才能带团队》。个人微信号 michael_tec,个人公众号“麦克叔叔每晚 10 点说”。

More

聊聊架构2017下半年精选文章

其它

随着互联网业务的飞速发展,系统动辄要支持亿级流量压力,架构设计不断面临新的挑战。海量系统设计、容灾、健壮性,架构师要考虑多方面的需求做出权衡。不如来听听国内外知名互联网公司的架构师分享架构设计背后的挑战与问题解决之道。

QCon 北京 2018 目前 8 折报名中,立减 1360 元,有任何问题欢迎咨询购票经理 Hanna,电话:15110019061,微信:qcon-0410。


关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接