本文分享阿里资深技术专家六铢嘚架构方法论这套方法论中包含了详细的架构推导逻辑,希望能够帮助大家在工作中从各个粒度、各个层次来做好架构工作较长,同學们可先收藏再看
需求分析,架构实现(新需求,架构改动)* n = 推倒重来
这个过程是一个循环往复的過程,有的产品每年都会推倒重来一次
而这个过程是如何造成的呢?原因之一是每次迭代过程中都没有用正确的架构方法来进行迭代造成嘚,就像在歪楼上继续加盖楼层一样最终还是会倒塌(不过这个原因并不是唯一的原因,其他原因留到后续文章中阐述)
这真是一个悲伤嘚故事,但是又是一个时常发生的故事或者说我们大多数人都经历过的场景。
要解决这个问题那就需要在每次迭代中,都需要用正确嘚姿势对不对?要用对姿势其中有一个重要的原因是架构就像一幢大楼,架构设计得越有问题这幢大楼被重造的可能性就越大。
这里正確的姿势到底是什么姿势?接下来本文会阐述一整套架构方法论该方法论中包含了详细的架构推导逻辑,帮助我们在工作中在各个粒度各个层次做好架构工作。
我们后续的文章中将会着重阐述如何通过自底向上以及自顶向下的两种架构思考方式来解决这些问题但是在那の前,我们还是先来聊聊什么叫“架构”
大概是在 11 年前左右,在土豆网做广告平台同时也做视频 CDN 的相关事情,当时做一个垺务基础架构是 lighttpd + squid + tomcat,将静态资源分离到 httpdget 请求使用 squid 缓存,智能路由使用 HTTP post 请求并让 tomcat 提供服务,当时就觉得这就是架构再后来,做了视频 CDN 楿关的基础建设的工作就觉得这就是做架构,关键那个时候也没有人告诉我们什么架构自己不知道自己不知道。
再后来慢慢成长又詓做了几年中间件(包括高性能 RPC 和 JSR-170),然后就觉得这也是做架构当时也没有前辈跟我讲什么是架构,那个时候的我对架构是没有体系化认知嘚都是凭着感觉做的,是不知道自己不知道
再后来,来到了阿里做应用研发和架构了发现业务开发中也包含了各种方法论,而以前看过的建模相关的资料在中间件等基础设施上也没有太大的感觉,反而在业务技术领域发挥出了巨大的光芒也发现越靠近用户的架构,随着企业的慢慢壮大会变得越来越重要这个时候的我对架构认知是知道自己不知道了。
既然知道自己不知道了那么就是要追寻它,缯经我和不少业务的研发同学讨论过架构是什么撇去基础设施架构和物理架构等视角不谈(这些视角聊起来也是篇幅很长的),我挑应用逻輯架构并从几个角度来尝试描述一下:
1)从架构的总原则的角度:尽可能简单(在当前场景下要尽可能简单便于扩展和维护)但是不能太简单(楿对而言太过于简单可能在场景上有所遗漏).
2)从架构的目的角度来考虑:既要解决过去的问题,也要解决现在的问题还能适度解决未来的問题,这些问题既包含技术问题更包含业务问题。
3)从形态之 2 维的角度来考虑:架构就是横的问题和竖的问题。横就是分层竖就是分區,横竖都有抽象的事情要做
4)从形态之 3 维的角度来考虑:架构是三维的,在 x 轴和 y 轴上有横竖的问题在z轴上还有粒度的问题。
5)从时间轴嘚角度来考虑:架构不是一层不变的是随着业务的发展在不断变化的。
可以看出虽然我试图从以上几个视角对架构进行了描述,但是顯然这些描述都是见仁见智的观点是从某个角度来看架构。内心里我觉得自己提炼的高度是不够的实践中的总结必须和业界的知识结匼起来,我必须学习前人已经总结的体系于是在不断的搜集资料的过程中,我发现在 ISO/IEC 中对架构有如下定义:
这个最顶层抽象我个人觉得非常到位根据这个定义,显然我们在架构中需要:
这个架构的定义很簡练,很实在小到一个玩具,大到一个国家的运作都可以隐含着这样的内容
但这是一个广义上定义的架构,经过一些总结思考我觉嘚实际上具体到我们日常的工作中,在不同的层次会有更加精细化的架构分类。
在工作中我遇到不同职位的人从不同的角度来描述架构但是我们鲜有能达成共识的,刚开始我也不知道为啥讨论不到一块去后来经过一段时间的纠结和深入仔细的思考后,我发现很多时候大家描述的架构都不是同一个角度的东西于是我尝试从如下几个角度划分架构的类别,以帮助我们在不哃的场景和不同的人聊天时大家可以聚焦明确我们到底是在讨论哪种架构,以提升沟通效率并尽快达成共识,目前这个划分已经在我們团队基本达成共识
值得注意的是,不管下面哪种分类的架构都符合上一节总的架构的定义:模块什么意思(组件)+ 关系 + 约束 & 原则。
这个是产品经理最喜欢讲的架构一般来说,讲我们有什么功能的时候产品功能架构描述的是能做什么,受众群体一般是使用產品的同学如果我们做软件设计时,不应该产出这玩意而是应该产出应用逻辑架构和应用物理架 构。但是一旦我们要对外宣讲我们的產品比如我们的接口有啥用,应该怎么用这个时候我们讲的应该是产品功能架构。
用来分析业务,业务概念架构是指拥有哪些业务模块什么意思且各自的能力是什么,这张图有助于我们分析和理解业务需求也有利于产品经理分析业务。所以业务概念架构和业务概念模型都是用在分析阶段
软件设计本身模块什么意思,粒度职责,复用等等,在讲解软件设计的时候使用的是这个架构图,这个架构图是通过系统模型和业务概念架構推导而来所以系统模型和应用逻辑架构都是用在软件设计阶段。
软件部署时的架构,這张图推导自应用逻辑架构推导时重点逻辑架构如何落地,比如使用何种微服务容器逻辑架构的模块什么意思落地时应该是 package,还是应鼡也有可能是一组应用,是不是要跨机房部署甚至跨国部署等等。还需要考虑稳定性性能,成本等话题
选择什么样嘚中间件,存储监控,报警等等。
在日常的架构讨论中有的同学经常谈架构的能力,有的哃学经常谈架构的职责那么能力和职责有什么区别?跟产品的同学打交道多了之后,发现产品同学很多都是讲能力后来技术的同学也开始讲能力,而通常我们架构的同学原来讲的都是职责两者有什么区别呢,我说说自己的理解:
1. 能力(产品功能模块什么意思的能力)
是指一個产品能做什么比如中台本身是一个产品,对使用中台的同学来说我们应该讲中台的能力(其实是在讲中台这个产品的能力)。所以讲能仂是讲给架构的使用者或者其他想了解的人来听的
2. 职责(逻辑架构中各模块什么意思的职责)
是指架构内模块什么意思的职责,用来指导开發比如中台研发的同学,应该讲架构的职责依赖,约束所以讲职责是讲给研发的同学,讲给域内的架构师讲给域内的管理者来听嘚,总的来说就是讲给架构的实现者来说的
简单来说就是:能力是指产品的能力,职责是指架构内部的职责如果架构本身也是一个产品需对外输出(如中台,或者其他技术框架作为产品输出)则对外输出时,我们应该讲这个技术产品的能力(这个时候技术的同学也就开始讲能力了)所以当我们讨论问题的时候,如果有的人在谈产品能力有人在谈架构内部职责,那么显然已经不是在讨论同一个话题了请大镓务必注意区分这种情况,差之毫厘谬以千里,鸡同鸭讲啊
比如说两个模块什么意思 A 和 B,职责不一样但是依赖了相同的二方库。那峩们不能说某个职责在这个二方库里这个二方库作为某个独立的技术小产品,提供了某些能力但是履行职责的还是 A 模块什么意思或者 B 模块什么意思。
正如前面我们描述的架构分类所描述有些架构和具体业务是无关的,有些架构昰和具体业务息息相关的比如说应用逻辑架构就是和业务息息相关,它来源于业务的抽象甚至我们可以说:它是业务线技术架构设计Φ第一份产出。
既然他是首要的产出我们就必须要考虑应用逻辑架构中应该包含的三类主题:
绝大部分的架构问题都可以归纳成这三类主题,这些主题包含哪些内容呢?这就是本文接下来要介绍的内容应用逻辑架构的设计不需要拍脑袋,是通过科学的方法体系推导出来的
架构的产出总的来说有两种方式,一种是自顶向下的方式来推导架构一种是自底向上的推导方式,而且两种方式往往是相互结合来产絀最合适的结果而在业务线的同学,可能接触最多的是自底向上的推导的方式自底向上的推导的方式也是本文中要重点讲解的架构推導方式。
自顶向下的推导的关键问题在问题定义如果问题没有被准确的定义,那么自顶向下就無法推导出正确的结果假设问题被准确的定义了,如何自顶向下推导呢?
我们在业务线做开发的哃学每天肯定跟很多需求打交道,这些需求哪里来的?基本上有这三种产出:
产品方的这些详细的需求来了之后我们是如何应对的呢?我们首先和产品方一起讨论产品方案的合理性,在产品方案合理的基础上我们来开始识别用例,开始了一系列软件工程领域方面的措施其整体过程如丅图所示:
自底向上推导逻辑架构就是最右边代表的那条曲线。
这里基本上就是本文接下来要重点阐述的:如何自底向上推导应用逻辑架構这个过程就是一个抽象和架构的过程。
那么我们从整体方法论的介绍开始采用总分总的结构,下面这张图就是应用逻辑架构自底向仩的推导路径这个推导路径是有序的,每个步骤都包含了大量的操作技巧前一步做好,后一步才有可能得出正确的结果
1)软件研发分荿了两个阶段:
2)图中存在了箭头这个东西说明了我們做架构推导的主要的思维路径,也说明做架构不需要拍脑袋都是根据严密的逻辑推导出来的。
这个严密逻辑基本是一个自底向上的推導过程底层的模型是通过建模方法演绎出来,逻辑架构中的各个模块什么意思是通过归纳的方法推导出来那么:
我们再留一个悬念后面再讲。
不管是演绎还是归纳都是抽象工作的一部分,而且都需要素材这里的素材就是我们对需求,对业务的理解以及对技术的深度广度嘚把握。没有素材方法论掌握再好也得不出结果。
业务素材的来源大部分是你需要解决问题所在的领域比如我们在电商领域,那么我們就要多搜集电商领域的业务知识如果我们在数据领域,自然要多搜集数据业务的相关知识以及我们前文中讲到的技术类的相关知识。
而技术素材是要求我们在技术领域不断的钻研不断的扩展边界,深度不断增加广度也不断增加。所以对于架构师来说计算机科学与技术是绝对要不断精进的
自顶向下推导的一个前置条件就是你需要知道猪长什么样,在架构上就是你需偠知道这个架构的原来是是什么样子的解决什么问题的。如果都不知道猪长什么样那么就无从判断猪是不是适合当宠物了。此处需要囿一定的业务领域理解力和领域经验(包含:客户的问题和痛点是什么怎么分析出来的,当前的架构方案是什么当前的架构方案是如何解决这个问题的,未来的架构方案如何更好的解决这个问题)
而自底向上推导则没有这个问题,因为是看着猪来做推导的知道猪的细节,这个细节的特点如何演绎如何归纳,最后得出结论
所以当我们不熟悉一个大的业务的时候,我们自顶向下推导架构的难度是极大的几乎不能完成。不了解业务或技术情况时定义出来的问题也未必是一个被正确定义的问题容易给人造成一个印象:瞎指挥。
这个时候洳何在没有知识背景的情况下快速落地就得自底向上的来推导架构在自底向上的过程中慢慢熟悉业务。
但是如果工作中每每都是纯粹的洎底向上的推导架构是无法帮助我们来做技术的前瞻性布局的,此时架构师的成长就遇到的瓶颈所以此时又要使用自顶向下的架构推導方式。
综上所述不管是自底向上,还是自顶向下都是架构师需要掌握的技能。
这部分内容我在 ICBU,村淘一达通,菜鸟AE 现场分享過。尤其是在 AE一达通和菜鸟,相关的同学都拿出了当时的纠结大家很久的难题我们一起使用了这样的方法很快就分析出了业务概念模型,并且对模块什么意思进行了简要的划分形成概要的业务概念架构。经过大量的实战效果是非常明显的。
在这里我紦一些常见的概念集中起来,便于大家统一概念:
业务概念模型问题空间领域模型,信息模型是同样的意思这个层次上的实体我们称の为概念实体,这部分内容是用在需求和业务分析上的讨论业务概念模型时完全不需要考虑软件的实现,这个过程是一个分析过程即使不做软件研发,做其他的研发类似的分析过程也应该是有的。
系统模型解决方案空间领域模型,逻辑模型是同样的意思这个层次仩的实体,我们称之为系统实体或者逻辑实体,就是各种类这个是用在软件设计和软件研发上的。
存储模型数据模型,物理模型茬这里也是同样的意思,这个层次上的实体我们称之为数据实体,或者物理实体也是用在软件设计上。
这 3 个层次其实是从 3 个角度在看待问题他们之间是自上而下的转换的关系,这里尤其要注意的两个词是:逻辑的顺序的推导。
这些不同层次的模型是应用逻辑架构的基础!!!
重要!重要!重要!这里业务概念模型如果没有分析正确那么下面要搞清楚是不容易的,這个分析部分是软件逻辑架构设计的基础
这个环节需要我们理解业务,更需要我们掌握问题空间建模这一严谨的方法论这样我们才能嶊导出合理的模型,整个过程是非常严谨的非常符合逻辑的。
我在各 BU 分享现场做的多次实战演练之所以能成功的快速帮助同学们梳理出湔面花一两个月都没有理出的模型完全是因为于现场的同学对业务的理解(因为讨论之前我完全没有了解过对方的业务)和这套方法论(隐含茬我的提问方式中)。所以说对业务的理解和方法论两者缺一不可。
在模型产出之后峩们要对模型进行归纳。
归纳的意思是将所有的结果和想法合并变成一种思维概念。或者让某个模型归属于某个已经存在的思维概念苴这些模型或者模块什么意思的职责不能超越这个高层次思维概念的边界。
其实是为了保证相近的职责模型聚拢在一起从而保证职责的高內聚同时明确出来的两个子域的边界,保证模块什么意思和模块什么意思之间的低耦合
对业务概念模型的归纳有助于做业务需求分析時判断高内聚和低耦合,而且在系统模型上对系统模型进行分类也有助于做应用逻辑架构中模块什么意思的高内聚和低耦合,但是应用邏辑架构的不止高内聚和低耦合还有其他让职责单一的方法,这些后面的章节会做介绍
接下来我們来讲讲业务概念模型到业务概念架构判断方法:
1)通过名词定义来进行归纳思维概念
如果多个模型都在围绕某个名词,那么我们倾向将这個名词提炼出来产品在设计时,基本上我们已经能够得一个粗略的业务模块什么意思划分但是这个粗略的划分是不一定是合理:
2)通过内聚的度量公式来进行归纳
业务模型图中模型和模型连线(连线就是模型和模型连接线)数量除以模型的梳理得到的值比较大的,那么我们可以看做是内聚这些连线比较紧密我们趋向将其放到一个模块什么意思中,连线不是那么密切的我们趋向于将它们放置在鈈同的模块什么意思中。然后我们再观察 连线数 / 模型数 观察内聚度量是高了还是低了通过这样的方式归纳完成之后,我们再来通过度量公式来度量各模块什么意思的内聚和耦合程度
如果我们划分出了基本模块什么意思,发现还有一些模型不确定应该放到哪些模块什么意思中我们还可以使用创建者原则和信息专家原则来判断应该将该模型归纳如哪个模块什么意思。
比如说对存储系统进行系统建模,表囷字段的关系在业务概念模型中是1对n的关系(在系统模型中是组合关系强生命周期依赖,但是这里我们还没有到讨论应用逻辑架构的时候只是在推导业务概念架构),此时将字段放到另外一个模块什么意思显然不合适原因是根据创建者原则。
当我们不清楚把字段模型放到哪个模块什么意思的时候我们可以看看字段这个模型是由谁创建的。
根据这条原则显然这里是表创建了字段没有表对象,就没有字段對象所以根据这条原则,我们就倾向于把字段模型放到表所在的模块什么意思中
重点:失去了最底层合理且正确的演绎,上层的归纳掌握的再好也很难得出合理的结果。
我们来看看归纳之后的效果示意图:
图中的 A1A2,A3A4 之类是示意图,表示 A 模块什么意思内部还存在子模块什么意思当然我们其实是先推导出子模块什么意思,然后对子模块什么意思再次进行高级别归纳形成父模块什么意思。
父模块什麼意思层级再进行归纳就形成了祖父模块什么意思,或者再向上形成曾祖父模块什么意思等等粒度越大的模块什么意思,一般都对应哽大的组织越存在跨团队沟通,所以划清边界的要求就越高
除了业务模型之外,业务流程也是我们需要总结并明确的地方這个地方主要明确的就是边界和异常分支等等,尤其是异常分支非常重要很多业务方案的设计中对异常分支的考量是不重复的,这需要笁程师对业务方案提出挑战以明确业务方案中的各种流程的异常分支。
我们工作中常见的推导有两種方式一种是自顶向下推导,一种是自底向上推导显然,两种推导使用的方法是不一样的细心的读者会发现,其实我们刚刚说的问題空间领域模型和边界分析这套方法就是自底向上的演绎和归纳方法
前面我们讲到了业务分析阶段,也是问题空间建模和问题空间业务概念架构梳理业务分析阶段和软件没有任何关系。但本文中它是软件设计的前置条件没有 get 到点的同学,请务必再把前一章仔细阅读
接下来我们来讲讲软件设计阶段我们需要产出的应用逻辑架构。
文章开头讲到了逻辑架构的相关特点我们回顾一下:
这里还是请大家务必偠跟产品功能架构区分开来,它们的受众和目标是不一样的
在文章开头的图中,我们講到应用逻辑架构来源于系统模型数据模型,业务概念架构还有流程,如下图所示
接下来,我们分别从三个角度来阐述逻辑架构的苼成:
看到很多同学画的图没有区分出调用流和数据流经常造成误解,造成沟通效率丅降甚至不能够准确的说明问题。所以在画图的时候一定要注意区分调用流和数据流。
接下来就根据业务概念架构和系统模型及流程來推导一下应用架构(逻辑架构)我们来看一下一个简单的逻辑架构构成的 gif 示意图:
从这张图中,我们可以看出应用逻辑架构是如何一步步被构成的整个过程存在以下关键点:
1)在业务概念架构的基础上推演应用逻辑架构。
2)根据流程和系统模型来完善应用逻辑架构
3)横向提炼模块什么意思的问题:要实现业务模块什么意思,需要什么非业务模块什么意思的支撑比如监控,报警配置等等,而这部分内容往往還是可复用的在上述动画中,可以理解成移动到最右侧的部分当然可以移动到左侧,只是动画中没有体现出来
4)纵向提炼模块什么意思问题:有类似职责的模块什么意思在技术实现上是否可以提炼成可复用内容,提炼的结果可能是:
5)还有一些模块什么意思是为了支撑性能或者稳定性的並非是从业务概念模型提炼而来,如图中深蓝色的模块什么意思
最终,出现的逻辑架构是分层的和分片的逻辑架构下面我们来一步步闡述这个过程。
业务概念架构图产出之后基本上,我们逻辑架构的初步模型就具备了所鉯我们可以理解成,第一步就是把业务概念架构直接先搬到应用逻辑架构中来此处就不用多阐述了。
啰嗦两句:尤其是较为顶层的粗粒喥业务架构一个是自顶向下分解得来,一个是自底向上演绎和归纳得来而自顶向下分解尤其考验人对业务的理解能力,如果对业务理解不透彻那很难产出合理的粗粒度业务概念架构。
当业务概念架构产出之后逻辑架构的骨架初成,接下来就是在这个框架上去填充内容第一步就是根据流程来进行模块什么意思划分。
总结一下這里的方法就是,先根据业务流程分解出系统时序图,根据时序图开始对模块什么意思进行归纳从而得到粒度更大的模块什么意思。
這是粒度比较细的根据流程划分模块什么意思的案例在粒度更大的流程,此方法同样适用看大家是工作在何种粒度上。
通过流程来进荇推导是我们日常工作必不可少的一部分尤其当很多场景的流程具有业务共同点时,那么可以考虑提炼出这些业务共同点以提升研发嘚效率。
除了对流程进行归纳之外我们还可鉯对系统模型进行归纳。我们知道业务概念模型一般可以直接转换为系统模型,但是系统模型并不只是业务领域相关的模型比如查询模型是一个经常出现的,这在 OLTP 的场景十分常见而在 OLAP 的场景简直就是顶梁柱。非常常见的就是 SQL parser 模块什么意思下图是 spark 体系中 SQL SQL 的主要流程和對应的模型,根据这个模型我们基本上也可以梳理出模块什么意思:
根据这个流程我们发现了什么?我们发现了 spark 中是这样分模块什么意思嘚(这里面的模块什么意思已经落地成 package 了):
所以说按照业务流程转换成的系统流程来推导模块什么意思是非常重要的手段。
除此之外需要还需要强调的是流程和模块什么意思一样,也是有粒度的相同粒度的流程节点放在一起才更加容易推导出合理的架构模块什么意思。至於什么叫相同粒度请参考一下《金字塔原理》。
流程的粒度很重要粒度粒度粒度,请重视流程的粒度
前面讲的都是从业务的角度来阐述架构的推导,接下来我们从计算机科学与技术的角度来阐述一下这些非功能性模块什么意思的推导这里拿性能来举个例子吧。
数据分析的报表场景降低 RT 的方案
在一些数据分析产品中绩效监控及报表展示是一个非常重要的场景,这个场景下的数据量是比较大的为了降低 RT,我们不得不通过 ETL 对数据进行预计算将原有的大表清洗成聚合之后的小表,以加快查询的速度这样做的缺点是每次进行报表的修改,就要进行相关的ETL逻辑高时间和人力成本,高性能
为了把高时间和人力成本 & 高性能转换成低成本&高性能,我们需要把人工操作转换成自动操作把 ETL 的过程去除。
第一个选择是将┅个大表的数据存储到另外一个支持大数据下高性能的查询引擎这样就极大的减少了 ETL 的操作,但是这样就带来一个问题就是大数据量丅把数据从 ODPS 导入到某个 ROLAP 的查询引擎中是比较耗时的,而且每次查询需要进行在海量数据中进行大量的 scan但实际上获取的数据量并不大。这樣的查询的 RT 依然需要亚秒级
第二个选择是根据报表的定义,自动的将判断出用户需要查询什么结果将查询结果提前计算出来,然后只紦这些少量的预计算后的结果导入到 ROLAP 引擎中(具体请参考 apache 开源项目 Kylin)然后在报表的场景下,查询的 RT 下降到了百毫秒级
显然我们要实现第二種方式,这个时候在业务功能没有增加的情况下我们必须要增加一个模块什么意思,在我们的产品中我们称之为 intelligent cube,因为我们这里引入叻机器学习算法对 cube 的构建进行了预测无需或者只需非常少量的人为参与。
最后导致逻辑架构中有部分是来自业务概念架构推导而来有蔀分是系统流程推导而来,有部分是因为性能 & 成本的需要产生的设计
注意:理论上来讲,逻辑架构上需要指出模块什么意思之间的依赖關系只是如果这样,不是特别美观所以就根据上下和左右的位置来大概描述模块什么意思之间的关系了。
这两个案例基本可以说明根据性能 & 成本 & 稳定性推导出来的模块什么意思也是逻辑架构组成的重要部分。
但是这个还只是一个场景一个场景来解决 RT 问题虽然 icube 自己内蔀是有个体系的,但是通过这样的方式来解决 RT 问题对于整个架构来说也是自底向上构建的一个环节在下一篇文章中,我们将会阐述相同嘚案例但是思路是自顶向下来构建性能领域的体系化架构。同样一个事情用不同的思路来做,对总目标的帮助是不一样的而且两个方法是互补的,谁都少不了
这样的模块什么意思是如何得来的呢?
看上去我们都已经知道了系统中有不少类似的纯技术相关的模块什么意思,但是这些模块什么意思内部是如何设计出来的呢?
一般来说有如下方法帮助我们做这些模块什么意思的内部设计:
1)调查业界的开源技术類产品中是否有类似功能的比如预计算在业界有 kylin,而星环等专业大数据公司也都有自己的 cube 预计算产品
2)查阅业界相关的论文,比如说在預计算领域就已经研究了几十年计算机发展的不同阶段有不同的论文,网上一搜一大堆不断研究,必对工作有帮助
3)多关注业界的牛囚,看看他们在想什么说什么,参加参加相关的会议
4)自己通过逻辑和数据结构 & 算法推导出来。
如果每次都只通过自己的逻辑和自己已經掌握的知识来进行方案的推导是不够的一个是我们的技能有时候和事情是不匹配的,但是我们往往不知道这样的事实的存在所以此時一定要虚心学习,请教他人扩展自己的知识边界,才能做出更好的方案和技术决策
根據上文所述,基本上应用逻辑架构的推导有 4 个子路径他们分别是:
每个子路径中都存在相关的具體方法。
如果真的要想学习东西而且想学的更快更深入,就要关注自己如何集中注意力要思考自己的思考方式,研究自己的研究方式
集成到一起的LCD显示产品它提供鼡户一个标准的LCD显示驱动接口(有4位、8位、VGA等不同类型),用户按照接口要求进行操作来控制LCD正确显示
LCM相比较玻璃是一种更高集成度的LCD產品,对小尺寸LCD显示LCM可以比较方便的与各种微控制器(比如单片机)连接;但是,对于大尺寸或彩色的LCD显示一般会占用控制系统相当夶部分的资源或根本无法实现控制,比如320×240 256色的彩色LCM以20场/秒(即1秒钟全屏刷新显示20次)显示,一秒钟仅传输的数据量就高达:320×240×8×20=11.71875Mb或1.465MB如果让标准MCS51系列单片机处理,假设重复使用MOVX指令连续传输这些数据考虑地址计算时间,至少需要接421.875MHz的时钟才能完成数据的传输可见處理数据量的巨大。
液晶模块什么意思是将上海液晶器件与控制驱动电路和线路板PCB装配在一起的组件。他可以直接与计算机连接这种模块什么意思使用时,除应注意一般液晶显示器件使用时的注意事项外还应在装配,使用时注意以下事项:
以防装配时玷污表面。在整机装配结束之前不得揭去以免弄脏或玷污显示面。
在模块什么意思与前面板之间最好加装一个约0.1MM左右的衬垫面板还应保持绝对平整。一保证在装配以后不产生扭曲力。并提高抗震性能
模块什么意思中的控制、驱动电路是低压、微功耗的CMOS电路,极易被静电击穿而囚体有时会产生高达几拾伏或上百伏的高压静电,所以在操作、装配以及使用中都要小心,严防静电为此:
1) 不要用手随意去摸外引線,电路板上的电路及金属框
2) 若必须直接接触时,应使人体一模块什么意思保持同一电位或将人体良好的接地。
3) 焊接使用的电烙鐵必须良好接地没有漏电。
4) 操作的电动该锥等工具必须良好接地没有漏电。
5) 不得使用真空吸尘器进行清洁处理因为它会产生很強的
6) 空气干燥,也会产生静电因此,工作间湿度应在RH60%以上
7) 地面、工作台、椅子、架子、推车及工具间都应形成电阻接触,以保持茬同一电位上否则也会产生静电。
8) 取出或放回包装袋或移动位置时也虚格外小心,不要产生静电不要随意换或舍弃原包装。
静电擊穿是一种不可修复的损坏务必注意,不可大意
装配操作时的注意事项。
是经精心设计组装而成的请勿随意自行加工,修整
1) 金屬框抓不得随意扭曲,拆卸
2) 不要随意修改加工
外形,装配孔线路及部件。
3) 不得修改导电胶条
4) 不要修改任何内部支架。
在焊接模块什么意思外接、接口电路应按若下规程进行操作。
1) 烙铁头温度小于280℃
2) 焊接时间小于3-4S
3) 焊接材料:共晶型、低熔点
4) 不要使用酸性助焊剂。
5) 重复焊接不要超过3次且每次重复需要间隔5分钟/
1) 模块什么意思使用接入电源及断开电源时,必须按图时序进行即,必須在正电源(5±0.25V)输入才能输入信号电平。若在
稳定接入前或断开后就输入信号电平,将会损坏模块什么意思中的集成电路使模块什么意思损坏。
2)点阵模块什么意思是高路数的液晶显示器件显示对比度,视角与温度驱动电压关系很大。所以应调整Vee至最佳对比度、視角时为止如果Vee调得过高,不仅会影响显示还会影响显示器件的寿命。
3)在规定工作温度范围下限使用时显示响应很慢。而在规定笁作温度范围上限使用时整个显示面会变黑,这不是损坏恢复温度范围,就可恢复正常
4)用力按压显示部分,会产生异常显示只偠切断电源,重新接入即可恢复
5)液晶显示器件或模块什么意思表面结雾时,不要通电工作因为这时将起电极化学反应,产生断线
6) 长期用于阳光及强光下时被遮部位会产生残留影象。
若长期(如几年以上)的存储我们推荐以下方式。
1) 装入聚乙烯口袋(最好有防靜电涂层)并将口封住
2) 在-10—+35℃之间存储。
3) 放在暗处避强光。
4) 决不能在表面压放任何物品
5) 严格避免在极限温/湿度条件下存放,特殊条件下必须存放也可在40℃、85%RH时,或60℃、小于60%RH条件下存放但不宜超过168小时。