软件架构模式
缺少规范架构的程序通常会变得紧耦合、脆弱、难以更改，缺少清晰的发展方向和愿景。这本小书用50多页介绍了常用的5种常见架构模式，相信不管是大牛还是萌新都会有所收获，特别是对我这种偏爱系统设计、架构、模式的人。当然，此书也只是高层的讨论，能够起到归纳总结、理顺思路的作用。如果想实际应用，还是需要从代码入手，站在架构模式的角度分析优秀的项目源码。
分层架构(Layered/N-tier Architecture)
分层架构的组件按垂直模式组织成多层，每一层表现为程序的一种角色。分层架构大概是最普遍的架构了，写过java web的人大概都规规范范地写过那什么dao、service、controller之类的包，每一层都是围绕一种功能的抽象，各负其责，有利于系统开发、测试、管理和维护。分层架构图如下：
一般来说，请求从上到下，下一层为上一层提供服务。这样做得好处是起到了解耦和封装的好处。然而有时候我们确实需要跨层访问，于是乎可以做一些退步，让某些层open。当然，这也是对结构的一种破坏。这种架构的一种典型反模式是，在某一层中只用少量的逻辑就到了下一层。解决办法是使用二八定律，如果大约20%的请求很简单的穿过该层，80%还是有些必要的逻辑，那么还是可以接受的，如果差距得大的话就得考虑将该层改为open。分层架构虽然简单但很实用，很多优秀的程序都多多少少用到这种模式。
事件驱动架构（Event-Driven Architecture）
事件驱动架构是使用高解耦、单一用途的事件处理组件来异步接收和处理事件的架构。事件驱动也是十分流行的架构，特别是在分布式、异步系统中。这种架构模式有两种拓扑结构，mediator和broker。mediator结构通常用在需要对一个事件组合多个步骤处理的情况，通过一个中心mediator来实现。broker结构通常用在需要将事件串在一起，并不通过中心化的mediator的情况。
Mediator结构
如下为mediator结构：
mediator结构包括4类组件：event queues， event mediator，event channels和event processors。事件首先到达event queue，通过event mediator接收的事件称为init event，然后经过编排组合，生成process event并异步地发送到event channels中。event processors将从event channels中取出事件并进行响应。event queue组件可以是消息队列、web服务端点等。需要注意的是，event mediator并不执行业务逻辑来编排process event，它只是知道处理init event的步骤，然后将每一步的执行事件异步发送到event channels。event mediator通常使用开源工具来实现（Spring Integration、Apache Camel或Mule ESB等）。event processor通常只处理单一的业务逻辑，并相互独立。
Broker结构
如下为broker结构：
broker结构与mediator结构的不同之处是没有event mediator组件。消息像一条链一样通过轻量级的message broker被分发。当你需要简单的事件处理流程，而不想使用事件编排中心的话，这是一个很好的选择。该结构包含两类主要组件：broker和event processors。broker包含了所有的event channels。与mediator结构不同，事件被一个event processor处理后会重新发布一个新的事件给broker，然后其他感兴趣的processor就会进行处理。
事件驱动模型由于其天然的异步性，是一种相对复杂的模式。由于其异步性，很难保证事务的原子性。如果你的业务逻辑中很少有原子性的事务则可以选择它。除此之外，事件驱动架构的代码编写、维护、管理都相对困难。尽管事件驱动有如此多麻烦问题（编程要求高），但是其异步特性和事件处理的机制是很多程序的首选。
微内核架构(Microkernel Architecture)
微内核架构又称为插件架构，它能够像添加插件一样添加系统特性。想想众多IDE可以安装插件就知道它的好用了。图示如下：
它包含两类组件：core system和plug-in components。core system包含程序的最小化、最基本的系统功能。plug-in component是独立的插件，用来扩充系统功能的。core system需要知道如何获取到plug-in，并知道如何使用它们，一类通用的方式是一种plug-in注册表的方式，其中包含plug-in的基本信息，如何控制，数据格式等等。core system和plug-in component之间要有某种contract，这样core system就不要编写特定的代码来适配。
微内核架构可以作为一种嵌入式的或者说作为其他架构模式一部分的架构模式，如果你不能一次性实现整个系统架构，那么微内核架构模式可以作为你的设计的一部分。
微服务架构(Microservices Architecture)
微服务体系结构的每个组件都可以作为一个单独的单元进行部署，允许通过有效且精简的交付管道更容易地进行部署。微服务架构由于其实用性，成为代替单体架构、面向服务架构的选择，并获得了广泛的关注。图示如下：
service component包含了一到多个模块来实现单一的功能，设计service component的粒度是设计微服务架构的挑战之一。微服务将应用分离成多个部署单元，使每一个单元都可以单独开发、部署、测试等，极大提高了开发效率、可测试性、可维护性等，可能这也是众厂商追捧的原因。微服务是由面向服务(SOA)发展而来的，但是相比之下微服务通过简化服务概念、减少服务编排需求、简化服务接入等方法让其更轻量。作者根据3种不同的使用场景又将微服务划分为API REST-based topology、application REST-based topology、centralized messaging topology三种结构。但是总体架构还是上图的样子。
基于空间的架构(Space-Based Architecture)
基于空间的架构模式也叫云架构模式(cloud architecture pattern)，是设计用来解决扩展性和并发性问题的。在互联网应用中，可以简单分为web server、application server和database server三类，请求从前到后经过三类服务器，当流量剧增时，三类服务器都可能遇到瓶颈，特别是database，最难扩展，且决定了并发量。此模式性通过去掉中心化database server，使用可复制的内存数据网格来实现高扩展性。程序数据都存储在内存中，在活动的process units中相互复制。process units可以在流量激增时动态启动来应对高负荷。架构图如下：
这种模式有两类主要组件：process unit和virtula Middleware。process unit中包含了应用程序的组件，小的web应用可能将所有内容塞到一个unit中，大的web应用可能将功能分开部署到不同的unit中。通常来说，process unit中包含了应用组件、内存数据网格和用于失效备援的异步的持久化存储组件。同时也包括一个复制引擎（replication engine）被virtual middleware使用来与其他unit交换数据。virtual middleware用于管理和通讯，包括了数据同步和请求处理的相关组件，有messaging grid、data grid、process grid和deploy manager。这些组件可以自己编码实现，也可以购买三方产品。
- messaging grid：管理输入请求和会话（session）信息。该组件决定请求分发到那个unit中。
- data grid：此模式中最重要且起决定性作用的组件。当数据更新时，该组件与unit中的replication engine交互。由于messaging grid可能将请求分发到任意一个unit中，所以unit中的数据必须时一致的，在实际中，数据的交互是并行的异步的，并且速度非常快（当然，即便很快，也需要解决一致性问题）。
- processing grid：如果unit是中存放了程序的一部分内容，那么由该组件来选择转发到不同类型的unit。
deployment manager：管理unit的动态启动和关闭，该组件监视流量情况，动态执行操作。该组件是实现可变扩展性的决定性组件。
总结
最后，是一个架构模型的总结表，在程序设计中可以根据实际需求来选择不同的软件架构模式。
