大家好,我是写代码的篮球球痴。今天我们看一看业界一些著名的编程模型。背景模型是对事物共性的抽象,编程模型就是对编程的共性的抽象。 什么是编程的共性呢? 最重要的共性就是:程序设计时,代码的抽象方式、组织方式或复用方式。编程模型主要是方法与思想。编程模型处于方法或思想性的层面,在很多情况下,也可称为编程方法、编程方式、编程模式或编程技术、编程范式。在这里就当做同一种说法。 当面对一个新问题时,通常的想法是通过分析,不断的转化和转换,得到本质相同的熟悉的、或抽象的、简单的一个问题,这就是化归思想。把初始的问题或对象称为原型,把化归后的相对定型的模拟化或理想化的对象称为模型。编程模型,简单地可以理解它就是模板,遇到相似问题就可以方便依模板解决,这样就简化了编程问题。不同的编程环境和不同的应用对象有不同的编程模型。 事件驱动来源于《Software Architecture Patterns》 事件驱动架构(Event-Driven Architecture)是一种用于设计应用的软件架构和模型,程序的执行流由外部事件来决定,它的特点是包含一个事件循环,当外部事件发生时使用回调机制来触发相应的处理。主要包括 4 个基本组件:
为什么采用事件驱动模型?事件驱动模型也就是我们常说的观察者,或者发布-订阅模型; 理解它的几个关键点:
许多现代应用设计都是由事件驱动的,事件驱动应用可以用任何一种编程语言来创建,因为事件驱动本身是一种编程方法,而不是一种编程语言。
事件驱动架构可以最大程度减少耦合度,因此是现代化分布式应用架构的理想之选。 深入理解事件驱动 1.异步处理和主动轮训,要理解事件驱动和程序,就需要与非事件驱动的程序进行比较。实际上,现代的程序大多是事件驱动的,比如多线程的程序,肯定是事件驱动的。早期则存在许多非事件驱动的程序,这样的程序,在需要等待某个条件触发时,会不断地检查这个条件,直到条件满足,这是很浪费cpu时间的。而事件驱动的程序,则有机会释放cpu从而进入睡眠态(注意是有机会,当然程序也可自行决定不释放cpu),当事件触发时被操作系统唤醒,这样就能更加有效地使用cpu。 2.IO模型,事件驱动框架一般是采用Reactor模式或者Proactor模式的IO模型。 Reactor模式其中非常重要的一环就是调用函数来完成数据拷贝,这部分是应用程序自己完成的,内核只负责通知监控的事件到来了,所以本质上Reactor模式属于非阻塞同步IO。 来自:深入理解Linux高性能网络架构的那些事 Proactor模式,借助于系统本身的异步IO特性,由操作系统进行数据拷贝,在完成之后来通知应用程序来取就可以,效率更高一些,但是底层需要借助于内核的异步IO机制来实现,可能借助于DMA和Zero-Copy技术来实现,理论上性能更高。 当前Windows系统通过IOCP实现了真正的异步I/O,而在Linux 系统的异步I/O还不完善,比如Linux中的boost.asio模块就是异步IO的支持,但是目前Linux系统还是以基于Reactor模式的非阻塞同步IO为主。 3.事件队列,事件驱动的程序必定会直接或者间接拥有一个事件队列,用于存储未能及时处理的事件,这个事件队列,可以采用消息队列。 4.事件串联,事件驱动的程序的行为,完全受外部输入的事件控制,所以事件驱动框架中,存在大量处理程序逻辑,可以通过事件把各个处理流程关联起来。 5.顺序性和原子化,事件驱动的程序可以按照一定的顺序处理队列中的事件,而这个顺序则是由事件的触发顺序决定的,这一特性往往被用于保证某些过程的顺序性和原子化。 事件驱动的缺点
常用的事件驱动框架
消息驱动消息驱动和事件驱动很类似,都是先有一个事件,然后产生一个相应的消息,再把消息放入消息队列,由需要的项目获取。他们只是一些细微区别,一般都采用相同框架,细微的区别: 消息驱动:生产者A发送一个消息到消息队列,消费者B收到该消息。生产者A很明确这个消息是发给消费者B的。通常是P2P模式。 事件驱动:生产者A发出一个事件,消费者B或者消费者C收到这个事件,或者没人收到这个事件,生产者A只会产生一个事件,不关心谁会处理这个事件 ,通常是发布-订阅模型。 现代软件系统是跨多个端点运行并通过大型网络连接的分布式系统。例如,考虑一位航空公司客户通过 Web 浏览器购买机票。该订单可能会通过API,然后通过一系列返回结果的过程。这些来回通信的一个术语是消息传递。在消息驱动架构中,这些 API 调用看起来非常像一个函数调用:API 知道它在调用什么,期待某个结果并等待该结果。 消息驱动的优点
常用的消息驱动框架
事件驱动vs消息驱动消息驱动的方法与事件驱动的方法一样有很多优点和缺点,但每种方法都有自己最适合的情况。 消息感觉很像经典的编程模型:调用一个函数,等待一个结果,对结果做一些事情。除了为大多数程序员所熟悉之外,这种结构还可以使调试更加直接。另一个优点是消息“阻塞”,这意味着呼叫和响应的各个单元坐下来等待轮到接收者进行处理。 事件驱动系统使单个事件易于隔离测试。然而,这种与整个应用系统的分离也抑制了这些单元报告错误、重试调用程序甚至只是向用户确认进程已完成的能力。换句话说:当事件驱动系统中发生错误时,很难追踪到底是哪里出了问题。可观察性工具正在应对调试复杂事件链的挑战。但是,添加到业务交易交叉点的每个工具都会为负责管理这些工作流的程序员带来另一层复杂性。 如果通信通常以一对一的方式进行,并且优先接收定期状态更新或确认,那么您将倾向于使用基于消息的方法。但是,如果系统之间的交互特别复杂,并且确认和状态更新导致的延迟使得等待它们变得不切实际,那么事件驱动的设计可能更合适。但是请记住,大多数大型组织最终会采用混合策略,一些面向客户/API 调用使用消息驱动,而企业本身使用事件驱动。因此,尽可能多地熟悉两者并没有什么坏处。 数据驱动数据驱动核心出发点是相对于程序逻辑,人类更擅长于处理数据。数据比程序逻辑更容易驾驭,所以我们应该尽可能的将设计的复杂度从程序代码转移至数据。 例子 假设有一个程序,需要处理其他程序发送的消息,消息类型是字符串,每个消息都需要一个函数进行处理。第一印象,我们可能会这样处理: 上面的消息类型取自sip协议(不完全相同,sip协议借鉴了http协议),消息类型可能还会增加。看着常常的流程可能有点累,检测一下中间某个消息有没有处理也比较费劲,而且,每增加一个消息,就要增加一个流程分支。 下面这种思路的优势: 1、可读性更强,消息处理流程一目了然。 2、更容易修改,要增加新的消息,只要修改数据即可,不需要修改流程。 3、重用,第一种方案的很多的else if其实只是消息类型和处理函数不同,但是逻辑是一样的。下面的这种方案就是将这种相同的逻辑提取出来,而把容易发生变化的部分提到外面。 隐含在背后的思想 很多设计思路背后的原理其实都是相通的,隐含在数据驱动编程背后的实现思想包括: 1、控制复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来,从而达到控制复杂度的目标。 2、隔离变化。像上面的例子,每个消息处理的逻辑是不变的,但是消息可能是变化的,那就把容易变化的消息和不容易变化的逻辑分离。 3、机制和策略的分离。和第二点很像,本书中很多地方提到了机制和策略。上例中,我的理解,机制就是消息的处理逻辑,策略就是不同的消息处理: 深入理解编程艺术之策略与机制相分离 数据驱动编程可以用来做什么
这种方法的缺点:
用表驱动法来实现 根据定义的三个枚举:模块类型,消息类型,自身模块状态,定义一个函数跳转表:
这种方法的好处:
2. 基于数据模型编程
数据驱动思考
总结设计模式(古典)主要针对OOP领域编程设计方法的抽象。这里的编程模型,主要是针对业务编程框架的抽象。 消息驱动和事件驱动,本身有很多相似地方,消息驱动主要代表是经典跨进程通信架构,让消息处理和函数调用一样,逻辑依然可以保持清晰简单。而事件驱动采取异步处理方式,最大化解耦,让程序耦合更低,框架更易扩展,两种编程模型都有各自优缺点,只有根据具体的场景找到一种合适使用方法。 数据驱动是一种新的编程思考,坚持'data as program'准则,把处理逻辑数据化,这样可以通过不同数据配置来实现不同的逻辑,让核心代码更精炼简单,框架更易扩展。 |
|