林仕鼎谈架构设计与架构师

讲师秀之7:林仕鼎谈架构设计与架构师-CSDN.NEThtml

林仕鼎谈架构设计与架构师

架构师林仕鼎百度云计算大会第五届云计算大会讲师秀设计模式

摘要:他自称“西二旗跨界架构师”,官方身份是百度大数据首席架构师,他喜欢在微博和博客上讨论技术、诗歌和社会热点,他就是林仕鼎。他不断地对架构师这份工做作着总结。架构

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


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


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

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

若是要更正式点定义,架构就是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时代,架构可归结为三点:软件架构和开发过程支持快速迭代,系统架构与分布式架构支持大规模用户和数据分析,而后由数据分析驱动迭代。

第五届云计算大会上,林仕鼎将出席,欢迎到现场与他交流。(综合/    包研 审校/仲浩)

相关文章
相关标签/搜索