架构之美-第16章-数据增长：FACEBOOK平台架构(5)
摘要：
阅读全文
posted @ 2012-07-04 11:42
随笔分类 - 架构之美
架构师必看-架构之美第14章-两个系统的故事：设计之城(一)
摘要：形式永远服从功能。 —Louis Henry Sullivan “设计之城”软件项目表面上与“混乱大都市”非常相似。它也是用C++写的消费音频产品，运行在Linux操作系统上。但是，它的构建方式有很大不同，所以内部结构也非常不同。 我从一开始就参加了“设计之城”项目。我们用有能力的开发者组成了一个全新的团队，从头开始构建这个产品。团队很小（开始有4名程序员），像“大都市”项目一样，团队的结构是扁平的。幸运的是，没有出现“大都市”项目中的个人对抗，在团队中也没有出现任何争权夺利的事。在此之前，团...
阅读全文
posted @ 2012-06-30 14:12
架构师必看-架构之美第14章-两个系统的故事：混乱大都市(一)
摘要：你们修筑、修筑，预备道路，将绊脚石从我百姓的路中除掉。 —《以赛亚书》第57章14节 我们要看的第一个软件系统名为“混乱大都市”。它是我喜欢回顾的一个系统—既不是因为它很好，也不是因为它让参与开发的人感到舒服，而是因为当我第一次参与它的开发时，它教给了我有价值的软件开发经验。 我第一次接触“混乱大都市”，是在我加入了创建它的公司时。初看上去这是一份有前途的工作。我将加入一个团队，参与基于Linux的、“现代”的C++代码集开发，已有的代码集已经开发几年了。如果你像我一样拥有特殊的技术崇拜，就会觉得很兴奋。 ...
阅读全文
posted @ 2012-06-30 11:22
架构师必看-架构之美第14章-两个系统的故事：现代软件神话(一)
摘要：架构是一种很浪费空间的艺术。 —Philip Johnson 软件系统就像一座由建筑和后面的路构成的城市—由公路和旅馆构成的错综复杂的网络。在繁忙的城市里发生着许多事情，控制流不断产生，它们的生命在城市中交织在一起，然后死亡。丰富的数据积聚在一起、存储起来，然后销毁。有各式各样的建筑：有的高大美丽，有的低矮实用，还有的坍塌破损。随着数据围绕着它们流动，形成了交通堵塞和追尾、高峰时段和道路维护。软件之城的品质直接与其中包含多少城市规划有关。某些软件系统很幸运，创建时由有经验的架构师进行了深思熟虑的设计，在构建时体现出了优雅和平衡，有很好的地图，便于导航。...
阅读全文
posted @ 2012-06-30 10:37
架构之美第十三章-美丽的架构
摘要：所有前面的方法都有助于我们判断一个架构是否“足够好”—也就是说，是否有可能指导开发者和测试者构建一个系统，并满足系统的利益相关人的功能和质量关注点。在我们每天使用的系统中存在着许多好的架构。 但是，超越足够好的架构是怎样的呢？如果有一个“软件架构名人堂”，那会怎样？哪些架构会陈列在这个艺术馆的墙上？这个想法可能没有你想象的那么遥远—在软件产品线领域，这样的“名人堂”的确存在。（注1）进入“软件产品线名人堂”的条件包括获得商业上的成功、影响其他产品线的架构（其他产品线可能“借用、复制、窃取”这个架构）、拥有足够的文档从而让其他人“不必通过道听途说”就能够理解该架构。我们将为更一般的“...
阅读全文
posted @ 2012-06-29 10:33
架构之美第十二章-好的架构
摘要：我们曾提到，架构师玩的是折中的游戏。对于一组给定的功能需求和品质需求，没有唯一的正确架构和唯一的“正确答案”。我们从经验中得知，应该对架构进行评估，确定它是否满足其需求，然后再投入资金来构建、测试和部署这个系统。评估试图回答前面小节中讨论的一个或多个一般关注点问题，或回答特定系统的具体关注问题。 架构评估有两种常见的方式（Clements、Kazman和Klein 2002）。第一种评估方式是确定架构的属性，通常通过建模或模拟系统的一个或多个方面。例如，通过性能建模来评估吞吐量和伸缩性，通过失效树模型来评估可靠性和可访问性。其他类型的模型包括复杂性和耦合指标，用于评估可变性和可维护...
阅读全文
posted @ 2012-06-29 10:07
架构之美第十一章-架构结构
摘要：那么，好的架构师如何来处理这些关注点？我们曾经提到过，需要将系统组织成一些结构，每种结构都定义了特定类型的组件之间的具体关系。架构师的主要关注点就是对系统进行组织，让每种结构有助于解答一个关注点所定义的问题。关键的结构决定将产品划分为组件，并定义了这些组件之间的关系（Bass、Clements和Kazman 2003; Booch、Rumbaugh和Jacobson 1999; IEEE 2000; Garlan和Perry 1995）。对于任何产品，都有许多结构需要设计。每种结构都必须单独设计，这样它就表现为一个独立的关注点。在接下来的几节中我们会讨论一些结构，你可以利用它们来考虑前...
阅读全文
posted @ 2012-06-29 09:55
架构之美第十章-创建软件架构
摘要：到目前为止，我们已经讨论了一般意义上的架构，并分析了软件架构与其他领域的架构之间有何相似与差异。接下来我们将注意力转到“如何”设计软件架构。当架构师创建软件系统的架构时，她应该关注什么？ 软件架构师的首要关注点不是系统的功能。 这是正确的—软件架构师的首要关注点不是系统的功能。 例如，如果我们请你来设计一个“基于Web的应用”，你首先问我们页面布局和导航树，还是问下面这些问题：• 谁提供应用主机托管？托管的环境有什么技术限制吗？• 你想运行在Windows服务器上还是在LAMP栈上？• 你想支持多少并发用户？• 应用需要怎样的安全性？有需要保护的数据吗？应用将运行在公网...
阅读全文
posted @ 2012-06-28 09:55
架构之美第九章-架构与设计
摘要：架构是系统设计的一部分，它突出了某些细节，并通过抽象省略掉另一些细节。所以，架构是设计的一个子集。关注实现系统组件的开发者可能不会特别关心所有组件如何装配在一起，而是主要关注少数组件的设计和开发，包括他们必须遵守的架构约束和可以应用的规则。因此，开发者和架构师面对的是系统设计的不同方面。 如果说架构关注的是组件之间的关系和系统组件外部可见的属性，那么设计还要关注这些组件的内部结构。例如，如果一组组件包含了一些信息隐藏的模块，那么这些外部可见的属性就构成了这些组件的接口，内部的结构与模块内的数据结构和控制流一同考虑（Hoffman和Weiss 2000，第7章和第16章）。
阅读全文
posted @ 2012-06-28 09:09
架构之美第八章-软件架构的含义
摘要：如果认为“架构”是一个简单的实体，能够用一份文档或一张图纸来描述，那就错了。架构师必须做出许多设计决定。要想有用，这些决定必须用文档记录下来，这样就能够进行复审、讨论、修改和批准，然后作为后续决定和构建时的约束。对于软件系统，这些设计决定包括行为上的和结构上的。 外部行为描述展示了产品如何与它的用户、其他系统和外部设备进行交互，这应该表现为需求。结构描述展示了产品如何划分为多个部分，以及这些部分之间的关系。我们还需要内部行为描述，用于描述组件之间的交互接口。结构上的描述常常展示相同部分的一些不同视图，因为不可能把所有信息以有意义的方式组织到一张图纸或一份文档中。一个视图中的组件，...
阅读全文
posted @ 2012-06-28 09:04
