网站icp备案号,重庆哪家网站,30几岁的人想学做网站,学院网站信息化建设大家好#xff0c;我是写代码的篮球球痴。今天我们看一看业界一些著名的编程模型。背景模型是对事物共性的抽象#xff0c;编程模型就是对编程的共性的抽象。什么是编程的共性呢#xff1f;最重要的共性就是#xff1a;程序设计时#xff0c;代码的抽象方式、组织方式或复… 大家好我是写代码的篮球球痴。今天我们看一看业界一些著名的编程模型。背景模型是对事物共性的抽象编程模型就是对编程的共性的抽象。什么是编程的共性呢最重要的共性就是程序设计时代码的抽象方式、组织方式或复用方式。编程模型主要是方法与思想。编程模型处于方法或思想性的层面在很多情况下也可称为编程方法、编程方式、编程模式或编程技术、编程范式。在这里就当做同一种说法。当面对一个新问题时通常的想法是通过分析不断的转化和转换得到本质相同的熟悉的、或抽象的、简单的一个问题这就是化归思想。把初始的问题或对象称为原型把化归后的相对定型的模拟化或理想化的对象称为模型。编程模型简单地可以理解它就是模板遇到相似问题就可以方便依模板解决,这样就简化了编程问题。不同的编程环境和不同的应用对象有不同的编程模型。事件驱动来源于《Software Architecture Patterns》事件驱动架构Event-Driven Architecture是一种用于设计应用的软件架构和模型程序的执行流由外部事件来决定它的特点是包含一个事件循环当外部事件发生时使用回调机制来触发相应的处理。主要包括 4 个基本组件事件队列event queue接收事件的入口存储待处理事件分发器event mediator将不同的事件分发到不同的业务逻辑单元事件通道event channel分发器与处理器之间的联系渠道事件处理器event processor实现业务逻辑处理完成后会发出事件触发下一步操作为什么采用事件驱动模型?事件驱动模型也就是我们常说的观察者或者发布-订阅模型理解它的几个关键点首先是一种对象间的一对多的关系最简单的如交通信号灯信号灯是目标一方行人注视着信号灯多方当目标发送改变发布观察者订阅者就可以接收到改变观察者如何处理如行人如何走是快走/慢走/不走目标不会管的目标无需干涉所以就松散耦合了它们之间的关系。许多现代应用设计都是由事件驱动的事件驱动应用可以用任何一种编程语言来创建因为事件驱动本身是一种编程方法而不是一种编程语言。松耦合——服务不需要(也不应该)知道或依赖于其他服务。在使用事件时服务独立运行不了解其他服务包括其实现细节和传输协议。事件模型下的服务可以独立地、更容易地更新、测试和部署。易扩展——通过高度独立和解耦的事件处理器自然地实现了可扩展性。每个事件处理器都可以单独扩展从而实现细粒度的可扩展性。恢复支持——带有队列的事件驱动架构可以通过“重播”过去的事件来恢复丢失的工作。当用户需要恢复时这对于防止数据丢失非常有用。事件驱动架构可以最大程度减少耦合度因此是现代化分布式应用架构的理想之选。深入理解事件驱动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.顺序性和原子化事件驱动的程序可以按照一定的顺序处理队列中的事件而这个顺序则是由事件的触发顺序决定的这一特性往往被用于保证某些过程的顺序性和原子化。事件驱动的缺点事件驱动架构就是通过引入中间层 来实现事件发布-订阅机制进行组件解耦看似能带来不少诱人的优点也必然会增加系统的复杂度间接增加开发难度和维护难度。事件驱动架构改变了编程思维将完整的功能过程拆解为了不同的异步事件处理也丧失了连贯的流程处理能力。如果事件数量众多就容易在“事件丛林”中迷了路比如中断风暴惊群效应等。常用的事件驱动框架selectpollepolllibev中断系统消息驱动消息驱动和事件驱动很类似都是先有一个事件然后产生一个相应的消息再把消息放入消息队列由需要的项目获取。他们只是一些细微区别一般都采用相同框架细微的区别消息驱动生产者A发送一个消息到消息队列消费者B收到该消息。生产者A很明确这个消息是发给消费者B的。通常是P2P模式。事件驱动生产者A发出一个事件消费者B或者消费者C收到这个事件或者没人收到这个事件生产者A只会产生一个事件不关心谁会处理这个事件 通常是发布-订阅模型。现代软件系统是跨多个端点运行并通过大型网络连接的分布式系统。例如考虑一位航空公司客户通过 Web 浏览器购买机票。该订单可能会通过API然后通过一系列返回结果的过程。这些来回通信的一个术语是消息传递。在消息驱动架构中这些 API 调用看起来非常像一个函数调用API 知道它在调用什么期待某个结果并等待该结果。消息驱动的优点开发难度低消息驱动类似经典的编程模型调用一个函数等待一个结果对结果做一些事情编程简单快速开发难度低。方便调试维护因为编程逻辑清晰简单流程清晰调试起来更加直接方便后期维护也容易。常用的消息驱动框架API网关gRPC微服务架构事件驱动vs消息驱动消息驱动的方法与事件驱动的方法一样有很多优点和缺点但每种方法都有自己最适合的情况。消息感觉很像经典的编程模型调用一个函数等待一个结果对结果做一些事情。除了为大多数程序员所熟悉之外这种结构还可以使调试更加直接。另一个优点是消息“阻塞”这意味着呼叫和响应的各个单元坐下来等待轮到接收者进行处理。事件驱动系统使单个事件易于隔离测试。然而这种与整个应用系统的分离也抑制了这些单元报告错误、重试调用程序甚至只是向用户确认进程已完成的能力。换句话说当事件驱动系统中发生错误时很难追踪到底是哪里出了问题。可观察性工具正在应对调试复杂事件链的挑战。但是添加到业务交易交叉点的每个工具都会为负责管理这些工作流的程序员带来另一层复杂性。如果通信通常以一对一的方式进行并且优先接收定期状态更新或确认那么您将倾向于使用基于消息的方法。但是如果系统之间的交互特别复杂并且确认和状态更新导致的延迟使得等待它们变得不切实际那么事件驱动的设计可能更合适。但是请记住大多数大型组织最终会采用混合策略一些面向客户/API 调用使用消息驱动而企业本身使用事件驱动。因此尽可能多地熟悉两者并没有什么坏处。数据驱动数据驱动核心出发点是相对于程序逻辑人类更擅长于处理数据。数据比程序逻辑更容易驾驭所以我们应该尽可能的将设计的复杂度从程序代码转移至数据。例子假设有一个程序需要处理其他程序发送的消息消息类型是字符串每个消息都需要一个函数进行处理。第一印象我们可能会这样处理上面的消息类型取自sip协议不完全相同sip协议借鉴了http协议消息类型可能还会增加。看着常常的流程可能有点累检测一下中间某个消息有没有处理也比较费劲而且每增加一个消息就要增加一个流程分支。按照数据驱动编程的思路可能会这样设计下面这种思路的优势1、可读性更强消息处理流程一目了然。2、更容易修改要增加新的消息只要修改数据即可不需要修改流程。3、重用第一种方案的很多的else if其实只是消息类型和处理函数不同但是逻辑是一样的。下面的这种方案就是将这种相同的逻辑提取出来而把容易发生变化的部分提到外面。隐含在背后的思想很多设计思路背后的原理其实都是相通的隐含在数据驱动编程背后的实现思想包括1、控制复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来从而达到控制复杂度的目标。2、隔离变化。像上面的例子每个消息处理的逻辑是不变的但是消息可能是变化的那就把容易变化的消息和不容易变化的逻辑分离。3、机制和策略的分离。和第二点很像本书中很多地方提到了机制和策略。上例中我的理解机制就是消息的处理逻辑策略就是不同的消息处理深入理解编程艺术之策略与机制相分离数据驱动编程可以用来做什么表驱动法(Table-Driven)消除重复代码考虑一个消息事件驱动的系统系统的某一模块需要和其他的几个模块进行通信。它收到消息后需要根据消息的发送方消息的类型自身的状态进行不同的处理。比较常见的一个做法是用三个级联的switch分支实现通过硬编码来实现switch(sendMode)
{
case:
}
switch(msgEvent)
{
case:
}
switch(myStatus)
{
case:
}这种方法的缺点可读性不高找一个消息的处理部分代码需要跳转多层代码。过多的switch分支这其实也是一种重复代码。他们都有共同的特性还 可以再进一步进行提炼。可扩展性差如果为程序增加一种新的模块的状态这可能要改变所有的 消息处理的函数非常的不方便而且过程容易出错。程序缺少核心主干缺少一个能够提纲挈领的主干程序的主干被淹没在 大量的代码逻辑之中。用表驱动法来实现根据定义的三个枚举模块类型消息类型自身模块状态定义一个函数跳转表typedef struct __EVENT_DRIVE
{MODE_TYPE mod;//消息的发送模块EVENT_TYPE event;//消息类型STATUS_TYPE status;//自身状态EVENT_FUN eventfun;//此状态下的处理函数指针
}EVENT_DRIVE;EVENT_DRIVE eventdriver[] //这就是一张表的定义不一定是数据库中的表。也可以使自己定义的一个结构体数组。
{{MODE_A, EVENT_a, STATUS_1, fun1}{MODE_A, EVENT_a, STATUS_2, fun2}{MODE_A, EVENT_a, STATUS_3, fun3}{MODE_A, EVENT_b, STATUS_1, fun4}{MODE_A, EVENT_b, STATUS_2, fun5}{MODE_B, EVENT_a, STATUS_1, fun6}{MODE_B, EVENT_a, STATUS_2, fun7}{MODE_B, EVENT_a, STATUS_3, fun8}{MODE_B, EVENT_b, STATUS_1, fun9}{MODE_B, EVENT_b, STATUS_2, fun10}
};int driversize sizeof(eventdriver) / sizeof(EVENT_DRIVE)//驱动表的大小EVENT_FUN GetFunFromDriver(MODE_TYPE mod, EVENT_TYPE event, STATUS_TYPE status)//驱动表查找函数
{
int i 0;
for (i 0; i driversize; i ){
if ((eventdriver[i].mod mod) (eventdriver[i].event event) (eventdriver[i].status status)){
return eventdriver[i].eventfun;}}
return NULL;
}这种方法的好处提高了程序的可读性。一个消息如何处理只要看一下驱动表就知道非常明显。减少了重复代码。这种方法的代码量肯定比第一种少。为什么因为它把一些重复的东西switch分支处理进行了抽象把其中公共的东西——根据三个元素查找处理方法抽象成了一个函数GetFunFromDriver外加一个驱动表。可扩展性。注意这个函数指针他的定义其实就是一种契约类似于java中的接口c中的纯虚函数只有满足这个条件入参返回值才可以作为一个事件的处理函数。这个有一点插件结构的味道你可以对这些插件进行方便替换新增删除从而改变程序的行为。而这种改变对事件处理函数的查找又是隔离的也可以叫做隔离了变化。、程序有一个明显的清晰主干。降低了复杂度。通过把程序逻辑的复杂度转移到人类更容易处理的数据中来从而达到控制复杂度的目标。 2. 基于数据模型编程基于Yang模型编程(DSLYANG是一种语言是用来建立数据模型的语言可以通过定义业务数据模型自动生成对应数据处理逻辑比如参数校验范围存储方式权限控制等典型的数据驱动编程Linux内核DTS设备树模型删除大量hardcode精简内核驱动代码。基于xmlprotobuf数据模型编程界面显示web配置逻辑RPC微服务等数据驱动思考它不是一个全新的编程模型它只是一种设计思路而且历史悠久在unix/linux社区应用很多它不同于面向对象设计中的数据“数据驱动编程中数据不但表示了某个对象的状态实际上还定义了程序的流程OO看重的是封装而数据驱动编程看重的是编写尽可能少的代码。”数据压倒一切。如果选择了正确的数据结构并把一切组织的井井有条正确的算法就不言自明。编程的核心是数据结构而不是算法。——Rob Pike程序员束手无策只有跳脱代码直起腰仔细思考数据才是最好的行动。表达式编程的精髓。——Fred Brooks数据比程序逻辑更易驾驭。尽可能把设计的复杂度从代码转移至数据是个好实践。——《unix编程艺术》作者。总结设计模式古典主要针对OOP领域编程设计方法的抽象。这里的编程模型主要是针对业务编程框架的抽象。消息驱动和事件驱动本身有很多相似地方消息驱动主要代表是经典跨进程通信架构让消息处理和函数调用一样逻辑依然可以保持清晰简单。而事件驱动采取异步处理方式最大化解耦让程序耦合更低框架更易扩展两种编程模型都有各自优缺点只有根据具体的场景找到一种合适使用方法。数据驱动是一种新的编程思考坚持data as program准则把处理逻辑数据化这样可以通过不同数据配置来实现不同的逻辑让核心代码更精炼简单框架更易扩展。参考和扩展阅读《unix编程艺术》《Software Architecture Patterns》 https://blog.csdn.net/chgaowei/article/details/6966857深入理解Linux高性能网络架构的那些事- END -推荐阅读专辑|Linux文章汇总专辑|程序人生专辑|C语言我的知识小密圈关注公众号后台回复「1024」获取学习资料网盘链接。欢迎点赞关注转发在看您的每一次鼓励我都将铭记于心~
