架构是系统设计的一部分，它突出了某些细节，并通过抽象省略掉了另一些细节。软件系统的架构包括行为上的和结构上的。外部行为描述展示了软件如何与用户、其他设备和外部设备进行交互，也就是需求。结构描述展示了软件如何被划分为多个部分，以及这些部分的关系。

  架构的设计受到许多因素的制约，架构是好是坏并没有统一的标准。这取决于人们对软件的需求、软件被构建和运行的环境，以及软件团队本身的特点等等因素。评价软件好坏有很多指标，例如性能、安全、可伸展性等等。一般来说，这些指标是很难全部满足的，试图改进其中一个往往会对其他指标产生负面影响。所以从某种意义上来说，软件架构是折中的游戏。对于一组功能需求和品质需求，没有唯一的正确架构。

  《架构之美》没有太多空洞的概念和论述，而是抛砖引玉地展示多个实际的项目。通过对它们架构利弊的分析，以及相关的思考，给读者提供了有益的启发。

  一、架构设计目标

  架构设计目标即另外一个需求，对其他开发者部署出一个简单的编程模型，程序员可以将系统视为一个单机开发环境。隐藏分布式和并发需要一种严格限制的编程模型。

典型的游戏服务器开发模型：反应式客户端（游戏机）（生成事件）服务端的事件监听器（监听事件，并生成任务），此任务可与多个客户端进行交互或者是服务端自己周期性生成任务。

这是一种典型的胖客户端机制，适用于游戏和虚拟世界，也适用于J2EE和Web服务的应用。区别另外一种经典的企业级架构：瘦客户端->胖客户端->更胖的数据库服务器。服务器保存客户端的绝大部分信息，绝大多数真正的工作在服务器上完成。

  游戏架构要求用户体验好，大的延迟不被接受，甚至牺牲吞吐量换取少的延迟。而企业环境的架构重在吞吐量，管理业务。有一点延迟可以接受。一般情况下，处理拥塞的解决方案：

  （1）基于地理位置来实现

  游戏设计包含不同的游戏区域，每个虚拟区域运行一台服务器，每个区域拥有自我限制功能，当人数过多时，服务拥塞，游戏变慢，趣味性下降，用户就转向更有趣的区域，响应时间就会得到改进。（对于棋牌类游戏，每个房间或区域有人数限制，满的房间可以限制进入）

这种开发方法的问题：游戏设计时，需要决定哪些区域放在一台服务器上，而添加新的区域时比较容易，若改动原来的区域，可能需要改动代码，这些都是开发的工作量。

  （2）分区sharding

  一个分区是一个区域的副本，运行在自己的服务器上，独立于其他分区，不同的玩家进入同一个区域的不同副本（分区）。这样的缺点时，不允许不同副本的玩家彼此进行交互。

书中介绍了什么样的的架构才算是美丽的架构，美丽的架构在开始时，要关注其实用性，好的架构应该是每天被很多人使用的；使用架构之前，我们还要考虑它必须要能够被构建（可构建性）；接下来就是关注架构的可持久性，好的架构应该能够经得起时间的考验，能够考虑到未来的变更，允许期望的修改；最后，要寻找一些能让人高兴的架构（开发人员、测试人员、用户等），这就要求架构必须满足概念完整性，这样的架构才易懂，易用，才会做到简单而又不过于简单。几个比较常见的美丽架构的例子有：A-7E舰载飞行处理器的架构；朗讯5ESS电话交换机软件架构；万维网；UNIX系统。

  在后来的章节中，又介绍了“混乱大都市”和“设计之城”两个项目，将两种比较，形象的说出了好的架构与差的架构的一些特性。“混乱大都市”的最大问题是重复，它没有考虑好软件设计中最关键的品质，内聚和耦合。它的失败经验很值得我们借鉴：缺乏预见性和对架构的整体思考。版本的发布周期过于漫长；系统没有弹性，可扩展性差；代码问题很严重，没有统一的命名规则和命名结构，导致新员工面对复杂的代码结构，感觉压力比较大，从而又造成了员工的跳槽和士气低等问题；团队的内部政治问题严重，没有团结精神，缺少凝聚力。

  相比之下，“设计之城”的成功就是吸取了它的经验教训，从一开始，项目的目标就很明确，在以后的开发过程中的代码必须支持所设定的要完成的功能，这样就形成了一个通用的目标的代码集，在以后的使用过程中可以适用于很多产品的配置。开发团队动态的遵守架构设计，开发人员们密切合作，共同创建一组干净、一致、密切合作的软件。如何Conway法则中所说的，团队的组织方式也如同软件的组织方式；坚持保持品质的信念；