讲师秀之7：林仕鼎谈架构设计与架构师

【CSDN综合】林仕鼎自称是个“喜欢厘清概念的人”，在他的博客、CSDN举行的TUP活动中以及QCon中一次一次进行了剖析。

林仕鼎在博客中写道，系统架构是一个工程和研究相结合的领域，既注重实践又依赖理论指导，入门容易但精通很难，有时候还要讲点悟性，很具有“伪科学”的特征。要在此领域进阶，除了要不断设计并搭建实际系统，也要注意方法论和设计理念的学习和提炼。对于工程师来说，到一定阶段后往往会遇到成长瓶颈。要突破此瓶颈，需要在所属技术领域更深入学习，了解本领域的问题本质、方法论与设计理念、发展历史等。

架构 (architecture) 这个概念确实不好定义。首先，它很虚，不像代码可以用源文件“自证”。其次，它很泛，好像跟什么都相关，开发、测试、部署甚至运营等各阶段都有其影子。然后，它好像还在变，在计算机发展的各个阶段（Mainframe/PC/Cloud）都感觉不太一样。而且，在不同的领域也都有不同的反映。

所以，一千个人心中有一千个哈姆雷特，一千个工程师眼里也能有一千种架构。以建筑为例，设计师想方案，建筑师出图纸，工人施工同时项目管理贯穿始终，那图纸就是架构。如果说到烤鸭，骨头和肉是代码，鸭架子就是架构，而过程管理将其变成烤鸭。

如果要更正式点定义，架构就是model和pattern，从而把code串成system。而其中最重要的就是design principles (设计原则），即为什么这个问题要用这个而非那个。更文艺点，再结合点美学，也可以叫作design philosophy (设计哲学或理念)。

然后我们来看什么是model和pattern，这两个具体的定义我还没想出来。先说一下比较，model偏宏观，而pattern偏微观；model重抽象描述，而pattern重具体实现。比如，你的系统有一个服务端和一个客户端，那么client/server就是model，而client与server之间的交互方式则是pattern，比如RPC/message、同步/异步，比如用滑动窗口来组织请求与应答等等。当然，这和系统的尺度有关。如果你zoom in到服务端，此时的model可能就是模块的组织关系，而pattern则是调用方式，比如用function call还是event等。

具体到领域上，我觉得主要有三类架构问题（不包括硬件）：

软件架构，其典型用例是企业级软件，通过合理的功能抽象，提取出公共组件和通用流程，进行最大化的功能复用 (reuse)。我称其为软件的可维护性问题。
系统架构，其巅峰是OS，重点是解决资源的分配与复用 (multiplexing)。
大规模分布式架构，主要应用在Cloud中，重点是大规模系统的资源整合、快速交付和运维问题。

那为什么架构会很泛又多变呢？这就牵扯到开发过程了。我们再引入一个方法论 (methodology) 的概念。传统软件工程那一套不必说了，互联网服务常用迭代式的开发方法 (现在又叫敏捷)，这就是方法论。我个人的做法通常有三种：divide and conquer，modeling and iterate，back-of-envelop calculation and simulation，按问题的规模、难易程度、熟悉程度、项目的组织方式等等选择不同做法。

存储和分布式

林仕鼎认为程序组织非常重要，对于存储这部分来说，它需要考虑包括结构、数据特点、访问模式、接口性质四大方面的问题。林仕鼎对这四大方面的问题作了详细阐述，指出每一个问题都面临若干选择，比如结构问题就有：File、Object、Table的选择，然后在同样一个结构中，还要面临是实时读写、批量写实时读之类的访问模式的选择，接下来不同访问模式对系统带来的影响，数据大小的分布、布局等。林仕鼎表示，正是因为有这么多因素的影响，导致开发者在设计系统时，必需要考虑很多方面。只有在全面掌握这些信息的情况下，才能设计出符合实际要求的系统。

存储带来的一些矛盾包括：延迟与吞吐、随机与顺序、规模与实时性。一般来说，系统的规模越大，实时性的保证难度也就越大。要化解矛盾，需要在包括B＋tree、Log-based两类模型建设的基础上做到弱化需求、发掘局部性、组合模型。

在谈到分布式时，林仕鼎表示其实分布式的目标很简单，只有两个：扩容和容错。要实现这些目标需要采用Partition和Replication两种方法，而协议设计、调试是难点。

服务架构和计算模型

在进行系统设计时，所有系统都会面临一个极限值，即在给定系统资源情况下，所能提供的最大请求数，这里需要做一个特别设计，以防请求数突破极限值。如果没有作特别设计，在极端情况下，吞吐量超过一个点，那整个系统将崩溃。

服务架构的目标包括系统的高吞吐能力和在极限压力下的稳定输出。要实现这两个目标离不开服务架构的两类模型：属于基本类型的threadpool + queue和属于复杂类型的event-driven。为了保证整个系统的稳定性，还需要注意：减小资源分配粒度并主动调度、Flow Control、负载反馈，Throttling和延迟截断这四个方面。

计算模型包含很多不同特点，一般来讲分为三类：数据密集型、计算密集型、通讯密集型（即传统HPC）。林仕鼎表示，首先要分析系统的特点，找到适合的模型。

架构师的三板斧

林仕鼎认为，在很多情况下，在怎么做系统、服务、数据仓库等问题上，开发者面临的具体问题都千差万别。此时，需要建立一些模型，或者有比较好的实践原则。作为一个架构师，首先是要非常深入地了解自己的业务，再根据业务特点运用一些现行做法。林仁鼎总结了“架构师三板斧”，作为本次演讲总结与各位分享。

架构师三板斧内容如下：

看清需求：Tradeoff、无法满足所有需求、无须同等对待所有需求、发现根本需求、抽象、降维、了解需求随时间的变化、选择方法、把握节奏。
选择方法：测算 -> 模拟 -> 实现、分解 vs 迭代、设计模式。
把握节奏：目标与可达路径、定期产出。

林仕鼎认为在Cloud时代，架构可归结为三点：软件架构和开发过程支持快速迭代，系统架构与分布式架构支持大规模用户和数据分析，然后由数据分析驱动迭代。

讲师秀之7：林仕鼎谈架构设计与架构师相关推荐

林仕鼎谈数据中心计算（一）：整体大于部分之和
<失控>中提到一个很普遍的现象,就是整体大于部分之和.比如,把5只蜜蜂加起来,仍然是5只蜜蜂:把10000只蜜蜂加起来,可就不仅仅是10000只蜜蜂了:它是一个蜂群,具备很多只有蜂群才有( ...
林仕鼎谈数据中心计算（三）：学术界与工业界，以及未来展望
在<林仕鼎谈数据中心计算>的第一部分,百度基础体系首席架构师林仕鼎先生提到要将数据中心当做逻辑上的一台机器来设计架构.在之后的对话中,林仕鼎具体介绍了对数据中心的存储资源做逻辑分层.物理映 ...
林仕鼎谈数据中心计算（二）：存储资源分层
在之前的对话中,百度基础体系首席架构师林仕鼎先生提到要将数据中心当做逻辑上的一台机器来设计架构.但是从物理的层面上,一台机器内部的几个CPU.几个硬盘,跟一个数据中心里面上万个CPU.上万块硬盘相比, ...
林仕鼎谈架构设计与架构师
摘要:他自称"西二旗跨界架构师",官方身份是百度大数据首席架构师,他喜欢在微博和博客上讨论技术.诗歌和社会热点,他就是林仕鼎.他不断地对架构师这份工作做着总结. [CSDN综合]林 ...
林仕鼎：架构设计的一些思考
林仕鼎在演讲中就系统架构中基本的存储.分布式技术.服务架构以及计算模型进行了分析,并分享了当架构师的经验.林仕鼎谈到的内容点包括: 高并发网站存储.分布式.服务架构.模型实例存储架构设计的四大注意事 ...
林仕鼎[百度云首席架构师]：架构设计的一些思考
林仕鼎在演讲中就系统架构中基本的存储.分布式技术.服务架构以及计算模型进行了分析,并分享了当架构师的经验.林仕鼎谈到的内容点包括: 高并发网站存储.分布式.服务架构.模型实例存储架构设计的四大注意事 ...
专访百度云首席架构师林仕鼎：如何突破瓶颈
专访百度云首席架构师林仕鼎:如何突破瓶颈在今年的百度开发者大会上,百度云战略高调发布,成为开发者们瞩目的焦点.一直以来在公共领域很低调的百度移动·云事业部的首席架构师,也在当天以百度云首席架构师的身 ...
林仕鼎：架构师成长之路----如何突破瓶颈
51CTO专访 http://os.51cto.com/art/201205/334675.htm 对于架构师的成长之路,林仕鼎先生有什么看法?近日,51CTO编辑对林仕鼎先生进行了一次采访,讨论这方 ...
林仕鼎：架构设计与架构师
发表于13小时前|340次阅读| 来源CSDN|0 条评论| 作者包研架构师林仕鼎百度云计算大会第五届云计算大会讲师秀摘要:他自称"西二旗跨界架构师",又戴上了百度基础体系首席 ...

讲师秀之7：林仕鼎谈架构设计与架构师

讲师秀之7：林仕鼎谈架构设计与架构师相关推荐

最新文章

热门文章