以前年少无知的我总觉得软件架构是非常虚的东西，随着工作经验的逐渐增加，慢慢地意识到，一个没有经过合理设计的软件，完全是在给自己埋坑。当我们开始觉得软件迭代困难，埋怨bug越来越多的时候，多想想为什么，有可能就是我们没有采用合理的软件架构模式。在阅读完《软件架构模式》以后，特整理书摘在此。
软件架构模式
分层架构
概念
- 基本上算是我们最常见的架构了，例如MVC等。
- 建议在Model之上增加DAO或者MANAGER层，统一数据库读写
缺点
- 容易掉入污水池反模式(architecture sinkhole anti-pattern)，请求流只是简单地穿过层次，中间不做任何处理。
- 数据必须经过每一层传递才能最终得到结果，性能不高，难以扩展。
事件驱动架构
概念
- 该模式是一种主流的异步分发事件架构模式，常用于设计高度可拓展的应用。异步性能非常高，解耦程度高，伸缩性抢。
- 包含两种拓扑结构:
中介(mediator)拓扑结构: 通常在需要在事件内使用一个核心中介分配、协调多个步骤间的关系、执行顺序时使用
代理(brorker)拓扑结构: 在想要不通过一个核心中介将多个事件串联在一起时使用。思想就是将对事件流的处理转换为对事件链的业务功能处理。类似于常用的消息中间件的拓扑结构 - github的webhooks也算是一种事件的触发
缺点
- 远程操作功能的可用性
- 缺少权限控制
- 代理或中介处理事件失败时的错误处理和重试逻辑
- 事务的粒度划分难抉择
微内核架构
概念
- 一个微内核，提供良好的插件模式。例如常用的IDE就是一个微内核，其上面可以搭配各种插件，这种模式，常用语软件而不是web。灵活性高，也易于部署。
- 能够被嵌入或者作为另一种架构的一部分
缺点
- 伸缩性不高而且不易于开发，内核必须做到足够的强大。
微服务架构
概念
- 是一个分布式的架构，意味着架构中的所有组件之间是完全解耦的，并通过某种远程访问协议(JMS/AMQP,REST,SOAP,RMI等)进行访问。
- 三种拓扑结构:
基于REST API的拓扑结构: 适用于网站通过某些API对外提供小型的、自包含的服务。
基于REST的应用拓扑结构: 与REST API不同，它通过传统的基于web或胖客户端业务应用来接收客户端请求，而不是通过一个简单的API层。
集中式消息拓扑结构：使用一个轻量级的集中式消息处理(ActiveMQ/HornetQ等) - 其实就是相当于把以前的一整个大应用，分割成独立的模块，使得维护性、可用性和分布式性增强。
缺点
- 服务间通信，可能导致组件之间产生耦合，但可以通过共享数据库解决。例如，若一个服务组件处理网络订单而需要用户信息时，它可以去数据库检索必要的数据，而不是调用客户服务组件的功能。
- 为了保持服务组件独立和部署分离，为服务架构模式实现中会存在一小部分由重复的业务逻辑而造成的冗余。
- 和分层模式差不多，依然可能存在调用多个微服务引发的性能问题。
基于空间的架构
概念
- 对于用户数量不可预测且数量级经常变化的情况同样适用，在架构级别来解决这个伸缩性问题通常是比增加服务器数量或者提高缓存技术更好的解决办法。
- 旨在减少限制应用伸缩的因素。高伸缩性是通过去除中心数据库的限制，并使用从内存中复制的数据框架来获得的。保存在内存的应用数据被复制给所有运行的进程。进程可以动态的随着用户数量增减而启动或结束，以此来解决伸缩性问题。这样因为没有了中心数据库，数据库瓶颈就此解决，此后可以近乎无限制的扩展了。
- 根据我的理解，就相当于去除中间服务器，可以将关键数据放在redis，然后复制多份。
缺点
- 测试性低而且开发困难
扩展阅读
如何少写PHP”烂”代码: 更好的MVC分层实践
