目的:
先建立基本的概念,这样以后项目开发时能想到用一下。具体内容开发时可以再详细了解。从而将复杂问题简单化,降低学习难度。
软件架构的种类
个人觉得下面这篇文章比较实用。软件开发,怎么自上而下,通过系统化的方式,将复杂的大问题逐步模块化、简单化。
在做软件架构设计时,根据不同的抽象层次可分为三种不同层次的模式:
架构模式(Architectural Pattern)
设计模式(Design Pattern)
代码模式(Coding Pattern)
架构模式是一个系统的高层次策略,涉及到大尺度的组件以及整体性质和力学。架构模式的好坏可以影响到总体布局和框架性结构。
设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。
代码模式(或成例)是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节,但不会影响到一个部件或子系统的中等尺度的结构,更不会影响到系统的总体布局和大尺度框架。
架构模式(Architectural Pattern)
一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些事先定义好的子系统,指定它们的责任,并给出把它们组织在一起的法则和指南。称之为系统模式。
•MVC模式,一个架构模式常常可以分解成很多个设计模式的联合使用。MVC模式常常包括调停者(Mediator)模式、策略(Strategy)模式、合成(Composite)模式、观察者(Observer)模式等。
•Layers(分层)模式,有时也称Tiers模式
•Blackboard(黑板)模式
•Broker(中介)模式
•Distributed Process(分散过程)模式
•Microkernel(微核)模式
架构模式常常划分成如下的几种:
一、 模块结构(From Mud to Structure)型。帮助架构师将系统合理划分,避免形成一个对象的海洋。包括Layers(分层)模式、Blackboard(黑板)模式、Pipes/Filters(管道/过滤器)模式等。
二、分散系统(Distributed Systems)型。为分散式系统提供完整的架构设计,包括像Broker(中介)模式等。
三、人机互动(Interactive Systems)型,支持包含有人机互动介面的系统的架构设计,例子包括MVC(Model-View-Controller)模式、PAC(Presentation-Abstraction-Control)模式等。
四、Adaptable Systems型,支持应用系统适应技术的变化、软件功能需求的变化。如Reflection(反射)模式、Microkernel(微核)模式等。
设计模式(Design Pattern)
一个设计模式提供一种提炼子系统或软件系统中的组件的,或者它们之间的关系的纲要设计。设计模式描述普遍存在的在相互通讯的组件中重复出现的结构,这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类,常见的种类有:
创建型设计模式,如工厂方法(Factory Method)模式、抽象工厂(Abstract Factory)模式、原型(Prototype)模式、单例(Singleton)模式,建造(Builder)模式等
结构型设计模式,如合成(Composite)模式、装饰(Decorator)模式、代理(Proxy)模式、享元(Flyweight)模式、门面(Facade)模式、桥梁(Bridge)模式等
行为型模式,如模版方法(Template Method)模式、观察者(Observer)模式、迭代子(Iterator)模式、责任链(Chain of Responsibility)模式、备忘录(Memento)模式、命令(Command)模式、状态(State)模式、访问者(Visitor)模式等等。
以上是三种经典类型,实际上还有很多其他的类型,比如Fundamental型、Partition型,Relation型等等。设计模式在特定的编程语言中实现的时候,常常会用到代码模式。比如单例(Singleton)模式的实现常常涉及到双检锁(Double-Check Locking)模式等。
代码模式(Coding Pattern)
代码模式(或成例)是较低层次的模式,并与编程语言密切相关。代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
较为著名的代码模式的例子包括双检锁(Double-Check Locking)模式等
《软件架构模式》Mark Richards 笔记
先了解一下,不需要去深入细节,先建立基本的概念,以后项目中如果有需要用到,再具体去了解。
http://colobu.com/2015/04/08/software-architecture-patterns/
分层架构 (Layered Architecture)
比如web中的SSH、SSM框架。一般不允许跨层访问。每一层只需要关注自己层的实现。
优点:开发容易。缺点:灵活性扩展度变低。
事件驱动架构 (Event-Driven Architecture)
客户端发送一个事件到事件队列(event queues)中,它用来将事件传送给event mediator。Event mediator收到初始的事件后,会发送额外的一些异步事件给event channels来执行处理的每个步骤。Event processors监听event channels,接收事件并处理一些业务逻辑。
例子:新浪微博改用异步推拉结合的模式,用户发表微博后系统将微博写入消息队列后立即返回,用户响应迅速,消息队列消费者任务将微博推送给所有当前在线粉丝的订阅列表中,非在线用户登录后再根据关注列表拉取微博订阅列表。
优点:灵活度高。缺点:开发难度大。
微内核架构 (Microkernel Architecture)
又称为插件架构模式。
微内核包含两个组件: core system 和 plug-in modules。其中core system提供最小功能集合以及插件生命周期管理。
优点:灵活度高。缺点:开发难度大。
微服务架构
没太看懂。个人理解是就是webservice访问服务,并且服务被细分为很多小的服务。
优点:灵活度高。缺点:性能低。
基于空间的架构 (Space-Based Architecture)
没太看懂。
十种常见的软件架构模式
分层模式
例如web中的ssm、ssh框架。
客户端-服务器模式
太经典了。
主从设备模式
在计算机系统中与总线连接的外围设备(主和从驱动器)。
管道-过滤器模式
构造生成和处理数据流的系统。每个处理步骤都封装在一个过滤器组件内。要处理的数据是通过管道传递的。
代理模式
客户端从代理请求服务,然后代理将客户端重定向到其注册中心的适当服务。
点对点模式
对等点可以充当客户端或服务器或两者的角色,并且可以随时间动态地更改其角色。类似p2p。
事件总线模式
通知服务
模型-视图-控制器模式
太经典了。无论是用WPF、QT,还是设计web界面,都会用到。
黑板模式
个人理解用于多个对象间通过读/写黑板上的数据,来达到共享信息的目的。
常用于语音识别、图像识别。
就好像多位不同的专家在同一黑板上交流思想,每个专家都可以获得别的专家写在黑板上的信息,同时也可以用自己的分析去更新黑板上的信息,从而影响其它专家。
在实际应用中常见的实现模式有:
A 利用数据库
利用数据库充当黑板,不同的应用共享数据库中信息,并且可以更新数据信息。这也是最常见的实现方式。
特点:
1 便于实现信息的查询,筛选和统计,这方面关系数据库提供了SQL 92的强大支持。
2 不能用于较高实时性要求的环境,这种实现是工作在“拉模式”下的,并且高频率的访问数据库会导致严重的系统性能问题。
B 利用发布—订阅模式
这种实现方式通常采用消息队列作为黑板,队列工作在主题模式(Topic),专家作为队列的订阅者,同时可以向队列发送消息,消息会被发送至所有订阅者。以上过程实现了专家间的信息交流。
特点:
1 可以有效应用于实时性要求较高的系统,这种实现工作在“推模式”下。
2 难于实现信息的统计分析,不像实现方式一那样可以通过SQL支持,这些工作必须开发者自己完成。
这里为了更好的理解黑板模式我又得打比方了。比如A观察了B、C、D、E、F这么多个对象,按照观察者模式,当B、C、D、E、F中某个对象状态改变时,通过初始化一个A对象然后利用A对象去调用operation操作。但是在黑板模式中是这样,B、C、D、E、F一旦状态改变,它会将其记录在一个类似黑板的统一中央数据中,然后A对象只需从黑板上关注自己的观察对象状态是否发生改变,一旦有改变则调用operation()操作。这两种方法中发生了一个微妙的改变,似乎黑板模式更好的解决了观察者与被观察者之间的耦合、依赖性。
解释器模式
数据库查询语言,比如SQL,也没太看懂
待续