《架构之美》阅读笔记02

第二部分(企业级应用架构):

       第3章【伸缩性架构设计】:

       从本部分开始,本书就开始介绍不同的架构设计。本章介绍的是伸缩型架构设计,使用的是Darkstar项目来举例。Darkstar是一个游戏虚拟项目,根据本类通常的实际情况,数据服务器通常需要拥有伸缩性,由于人数、时间、热度等多方面的影响,游戏的负载会实时变化,游戏的服务器的数量、连接方式也就需要根据此来变化,以应对不同的需要。游戏的性能最本质的原因来自于架构及其实现,优化整体架构是实现高性能不可获取的关键步骤。通过多线程和多机器来提高整体效率,经过各个方面的提高,是整个项目得到品质上的飞跃。伸缩型架构设计在这里被发挥的淋漓尽致。

       第4章【记忆留存】:

       这一章,作者引用了2005年与LPS的开发者一起工作,开发系统来将电子转化成墨水原子和纸张的例子来为我们讲解第二种架构。有两个方面会影响到系统的架构:功能和约束,解决这两方面的问题,也就确定了问题空间。这就需要我们了解事实、发掘问题、提炼出问题的关注点。了解事实,也就是了解到系统运行的背景,即工作流。找出所需架构结构,保持关注点分离,坚持量增式设计和开发,最终,作者的Creation Center令人满意地平衡了各方面的需求,达到了最终的要求。

       第5章【面向资源的架构,在Web中】:

       在这一章,我了解到了企业中的聚焦信息的架构展示了和Web一样的特点:伸缩性、弹性、架构迁移策略、信息驱动与访问控制。多数组织机构内部数据的交流与使用常常有这样或那样的问题,而不能像Web一样,简单方面的获取到大量的信息,我们也可以从Web获得启发,更好的管控内部数据。经过对Web结构的分析,我们可以获取到面向资源的架构方法,不同的超链接指向不同的资源,统一资源可以经由多种方式到达。他成功地包装并复用已有的代码、服务和基础设施,为他们提供逻辑命名接口,对所有形式的交互都不透露实现细节。我们可以自由地调整服务器端的技术而不会影响到原有的客户端。我们应从以软件为中心的架构中走出来,学着去关注信息及其流动,面向资源的方法可以真正的提高效率和业务价值,让我们实现更美的架构。

 

       第6章【数据增长,Facebook的架构】:

       随着时代的发展,数据相比较于算法而言,获得了更大的重视,原因显而易见。本章使用Facebook作为例子为我们讲述了数据增长的架构。Facebook是个典型的围绕数据建立架构的例子,无论是功能还是内容,每个人的数据给这一网站带来了价值。通过用户不断增多,数据不断庞大,开发者意识到了对数据的架构极为重要,需要创建一些技术来弥补Facebook的体验。Web服务、数据查询服务和FBML等技术来实现协调不断扩展的数据访问方法和容器网站的预期,通过数据访问模式,网站的性能不断优化升级。

时间: 2024-10-13 11:33:25

《架构之美》阅读笔记02的相关文章

《构建之法》阅读笔记02

<架构之美>阅读笔记02 今天,我读了<架构之美>第三.四章,第三章主要讲伸缩性架构设计,书中说设计系统架构时,要确保系统在伸缩时的弹性,根据书中的介绍我对系统伸缩性的理解是每个网站在不同时期都会有不同的访问量,有时会很多,有时会较少,当较多的人访问你的系统时,你可能需要数量较多的设备来满足用户与系统的交互,但当访问的用户越来越少时,系统伸缩性如果不够好,很多设备就会被浪费,不能够与系统分离,这对于软件开发者是不可取的.Darkstar项目就是由Sun公司实验室承担的一个将在架构的

《用户故事与敏捷开发》阅读笔记02

 <用户故事与敏捷开发>阅读笔记02       这周读了<用户故事与敏捷开发>的第四至七章,第四章讲述的是如何搜集故事,也就是如何正确的去找到用户需求.作者明确指出"引用"和"捕捉"是不合用的.所谓"引用"和"捕捉",我想是通过用户对功能的表述,开发人员从中获取需求信息吧.如果是这种方法来获取需求,正如作者所说,用户不会知道所有的需求,所以只靠着这方法是远远不够的.对于故事编写的数量以及程度,作者认为

ijkplayer阅读笔记02

ijkplayer阅读笔记02 1.在这一章主要介绍音视频解码和显示线程的创建和启动,直接贴代码如下: IjkMediaPlayer_prepareAsync{ ijkmp_prepare_async_l{ ijkmp_change_state_l(mp, MP_STATE_ASYNC_PREPARING); msg_queue_start(&mp->ffplayer->msg_queue); SDL_CreateThreadEx(&mp->_msg_thread, mp

《需求分析与系统设计》阅读笔记02

在对于<需求分析与系统设计>第一章的阅读中我知道一个项目的成型的大致流程,一个软件的生命周期以及在不同的阶段我们应该采用什么样的方法.在不同的生命周期阶段当中我们应该做些什么,应该注意什么.对于一个软件的开发的方法. 对于第二.三章的精读之后了解到学习对象技术的主要困难在于缺乏明确的出发点和清晰的研究途径.没有像我们曾经了解的自顶向下或自底向上的一种学习方法.学习面向对象技术是一种“从中间出发”的方法.对于一个对象,我们首先要先确认实例对象,并且区分实例对象和类对象.那么关于对象呢,我们需要掌

《构建之法阅读笔记02》

这次主要对<构建之法>的第四章“两人合作”作一次阅读笔记. 首先是代码规范问题. 我过去对于代码规范问题并没有做到注意.在编程中,许多变量和函数的命名都非常的简单而没有实际的意义.而且编程时不注意对齐缩进.很多时候也不加注释,导致对这些简单的变量名称不熟悉. 这样做会使得很多人读代码费劲,甚至是自己都要花时间再次阅读懂自己的代码.而且很多没必要的注释也会使得注释失去意义.当自己再次在原基础上编程时,可能要重新编程等问题. 因此,通过阅读“代码规范”,我找到一些解决方法.代码的风格要简明.易读.

&lt;&lt;需求分析与系统设计&gt;&gt;读书笔记之一

<<需求分析与系统设计>>这本书论述了软件分析和设计的迭代增量式过程,讨论软件分析与设计的原理,方法和技术,并特别关注了设计阶段,对软件体系结构的内容进行了很大的扩充.本书强调对象技术与统一建模语言UML在企业信息系统开发中的应用,并讨论了使用web技术和数据库技术进行开发的方法.这本书集中在面向对象软件开发上,统一建模语言用于捕捉建模的人工制品,主要论述用逐步细化的方式进行开发,并且在整个开发生命周期中都是用UML这种建模语言.系统分析师,设计师和程序员使用同一种语言和工具,但有

&lt;&lt;需求分析与系统设计&gt;&gt;读书笔记之三

终于把<需求分析与系统设计>读完了,感受很多,虽然理解还不是透彻,但还是学到了不少知识.在软件需求规格说明中,需要用图形和其他形式化模型来说明需求,为了完整地说明一个系统,有必要采取多种模型.UML提供了许多集成化的建模技术来辅助系统分析师来完成这项工作.规格说明的过程是迭代增量式的.对成功的建模来说,使用case工具是必须的.需求规格说明产生三种模型:状态模型,行为模型,状态变化模型.需求规格说明涉及需求确定期定义的客户需求进行严格的建模,重点放在那些系统将要提供的所期望的服务上.在规格说明

《UML大战需求分析》阅读笔记02

软件应能真正的对客户的工作提供帮助,只有客户使用并真正对其有用才能说我们做的软件成功了.客户从开始提出需求时到后期的工作过程中,需求总是不停变化的,所以这就需要需求人员对需求领先于客户.所以活用UML进行结构和行为建模,帮助我们更好的认识客户业务和做好业务流程再造工作.UML进行需求分析的过程: 搞清楚系统的目标和范围 找出该系统的所有关键涉众列出他们要解决的问题 分析业务,确认问题,发掘真正问题 针对问题,提出系统的特性 针对特性,提出系统的用例细化功能需求非功能需求 类图是用的最多的UML图

代码大全阅读笔记02

继续阅读代码大全这本书,感觉是好厚好难啃啊.刚刚开始读不久到了作者说把主要精力集中于构建活动,可以大大提高程序员的生产率.我想就一个项目来说,思路和设计是站着主导的地位的,你如果不能把思路理清,可能随时都有可能卡在那里,而一旦灵感来了,你就会想泉涌一样的来思路,我们也算是做了一个小的项目的了,虽然很low吧,但是好歹也算有点体会.我们总是在设计的时候会走投无路,不知所措,以至于每一次开始时都是没有思路起手都只能积压在那里,实在是不知道该怎么做.我觉得 P28 的那个食物链的例子更有说服力,健康的

人月神话阅读笔记02

贵族专制.民主政治和系统设计 本章主要是围绕着: 1.如何得到概念的完整性. 2.这样的观点是否要有一位杰出的精英,或者说是结构设计师的贵族专制,和一群创造性天分和构思被压制的平民编实现人员? 3.如何避免结构设计师产出无法实现.或者是代价高昂的技术规格说明,使大家陷入困境? 4.如何才能实现与实现人员就技术说明的琐碎细节充分沟通,以确保设计整备正确的理解并精确的整合到产品中? 就第一个问题文章是介绍的编程系统的目的是使计算机更加容易使用.对于功能,能够用最简洁的方式来指明事情的系统是最好的,对