精华内容
下载资源
问答
  • 微内核架构

    千次阅读 2019-01-23 01:28:07
    微内核架构(Microkernel Architecture),也被成为插件化架构(Plug-in Architecture),是一种面向功能进行拆分的可扩展性架构,通常用于实现基于产品(原文为product-based,指存在多个版本,需要下载安装才能使用...

    微内核架构(Microkernel Architecture),也被成为插件化架构(Plug-in Architecture),是一种面向功能进行拆分的可扩展性架构,通常用于实现基于产品(原文为product-based,指存在多个版本,需要下载安装才能使用,与web-based想对应)的应用。例如Eclipse这类IDE软件、UNIX这类操作系统、淘宝App这类客户端软件等,也有一些企业将自己的业务系统设计成微内核的架构,例如保险公司的保险核算逻辑系统,不同的保险品种可以将逻辑封装成插件。

    基本架构

    微内核架构包含两类组件:核心系统(core system)和插件模块(plug-in modules)。核心系统负责和具体业务功能无关的通用功能,例如模块加载、模块间通信等;插件模块负责实现具体的业务逻辑
    在这里插入图片描述
    上面这张图中核心系统Core System功能比较稳定,不会因为业务功能扩展而不断修改,插件模块可以根据业务功能的需要不断扩展。微内核架构的本质就是将变化封装在插件里面,从而达到快速灵活扩展的目的,而又不影响整体系统的稳定。

    设计关键点

    微内核的核心系统设计的关键技术有:插件管理,插件连接和插件通信

    1、插件管理

    插件系统需要知道当前有哪些插件可用,如何加载这些插件,什么时候加载插件,常见的实现方法是插件注册表机制。
    核心系统提供插件注册表(可以是配置文件,也可以是代码,还可以是数据库),插件注册表含有每个插件模块的信息,包括它的名字、位置、加载时机(启动就加载,还是按需加载等)

    2、插件连接

    插件连接指插件如何连接到核心系统。通常来说,核心系统必须制定插件和核心系统的连接规范,然后插件按照规范实现,核心系统按照规范加载即可。
    常见的连接机制有OSGi(Eclipse使用)、消息模式、依赖注入(Spring使用),甚至使用分布式的协议都是可以的,比如RPC或者HTTP Web的方式。

    3、插件通信

    通信必须经过核心系统,因此核心系统需要提供插件通信机制。这种情况和计算机类似,计算机的CPU、硬盘、内存、网卡是独立设计的配件,但计算机运行过程中,CPU和内存,内存和硬盘肯定是有通信的,计算机通过主板的总线提供了这些组件之间的通信功能。微内核的核心系统也必须提供类似的通信机制,各个插件之间才能正常的通信。

    OSGi架构简介

    OSGi的全称是Open Services Gateway intiative,本身其实是指OSGi Alliance。这个联盟是Sun Microsystems、IBM、爱立信等公司于1999年3月成立的开放的标准化组织,最初名为Connected Alliance。它是一个非盈利的国际组织,旨在建立一个开放的服务规范,为通过网络向设备提供服务建立开放的标准,这个标准就是OSGi specification。现在我们谈到OSGi,如果没有特别说明,一般是指OSGi的规范。
    OSGi联盟的初始目标是构建一个在广域网和局域网或设备上展开业务的基础平台,所以OSGi的最初设计也是针对嵌入式应用的,诸如机顶盒、服务网关、手机
    、汽车等都是其应用的主要环境。然而,无心插柳柳成荫,由于OSGi具备动态化、热插拔、高可复用性、高效性、扩展方便等优点,它被应用到了PC上的应用开发。尤其是Eclipse这个流行软件采用OSGi标准后,OSGi更是成为了首选的插件化标准。现在我们谈OSGi已经和嵌入式应用关系不大了,更多是将OSGi当做一个微内核的架构模式。
    Eclipse3.0开始,抛弃了自己实现的插件化框架,改用OSGi插件化框架。需要注意的是OSGi是一个插件化的标准,而不是一个可运行的框架,Eclipse采用的OSGi框架为Equinox,类似的实现还有Apache的Felix、Spring的Spring DM。
    OSGi框架的逻辑架构图如下:
    在这里插入图片描述

    1、模块层(module层)

    模块层实现插件管理功能。OSGi中,插件被称为Bundle,每个Bundle是一个java的jar文件,每个Bundle里面都包含一个元数据文件MANIFEST.MF,这个文件包含了Bundle的基本信息。例如,Bundle的名称、描述、开发商、classpath,以及需要导入的包和输出的包等,OSGi核心系统会将这些信息加载到系统中用于后续使用。
    一个简单的MANIFEST.MF样例如下:

    Manifest-Version: 1.0
    Archiver-Version: Plexus Archiver
    Built-By: liuzhe
    Created-By: Apache Maven 3.5.3
    Build-Jdk: 1.8.0_162
    

    2、声明周期层

    声明周期层实现插件连接功能,提供了执行时模块管理、模块对底层OSGi框架的访问。生命周期层精确的定义了Bundle生命周期的操作(安装、更新、启动、停止、卸载),Bundle必须按照规范实现各个操作,例如:

    public class NettyBundleActivator implements BundleActivator {
        private OsgiLoggerFactory loggerFactory;
    
        public NettyBundleActivator() {
        }
    
        public void start(BundleContext ctx) throws Exception {
            this.loggerFactory = new OsgiLoggerFactory(ctx);
            InternalLoggerFactory.setDefaultFactory(this.loggerFactory);
        }
    
        public void stop(BundleContext ctx) throws Exception {
            if (this.loggerFactory != null) {
                InternalLoggerFactory.setDefaultFactory(this.loggerFactory.getFallback());
                this.loggerFactory.destroy();
                this.loggerFactory = null;
            }
    
        }
    }
    

    3、服务层(service层)

    服务层实现插件通信的功能。OSGi提供了一个服务注册的功能,用于各个插件将自己提供的服务注册到OSGi核心的注册中心,如果某个服务想用其他服务,则直接在服务注册中心搜索可用中心即可。

    规则引擎架构简析

    规则引擎从结构上来看也属于微内核架构的一种具体体现,其中执行引擎可以看做是微内核,执行引擎解析配置好的业务流,执行其中的条件和规则,通过这种方式来支持业务的灵活多变。
    规则引擎在计费、保险、促销等领域应用较多。例如电商促销,常见的促销规则有:

    • 3件8折
    • 第三件免费
    • 跨店满200减100
    • 新用户立减50

    • 以上仅仅列出来常见的几种,实际上完整列下来可能有几十上百种,再加上排列组合,促销方案,可能有几百上千种,这样的业务如果靠代码来实现,开发效率完全跟不上业务的变化速度,而规则引擎却能很灵活的应对这种需求,主要原因在于:

    1、可扩展

    通过引入规则引擎,业务逻辑实现与业务系统分离,可以在不改动业务系统的情况下扩展新的业务功能

    2、易理解

    规则通过自然语言描述,业务人员易于理解和操作,而不像代码那样只有程序员才能理解和开发。

    3、高效率

    规则引擎系统一般提供可视化的规则定制、审批、查询及管理,方便业务人员快速配置新的业务。
    规则引擎基本架构如下:
    在这里插入图片描述

    • 开发人员将业务功能分解提炼为多个规则,将规则保存在规则库中
    • 业务人员根据业务需要,通过将规则排列组合,配置成业务流程,保存在业务库中
    • 规则引擎执行业务流程,实现业务功能
      对照微内核架构的设计关键点,看看规则引擎是如何实现的

    1、插件管理

    规则引擎中的规则就是微内核架构中的插件,引擎就是微内核架构的内核。规则可以被引擎加载和执行。规则引擎架构中,规则一般保存在规则库中,使用数据库来存储。

    2、插件连接

    业务人员需要基于规则语言来编写规则文件,然后有规则引擎加载执行规则文件来直线业务功能。因为规则引擎的插件连接实现机制,其实就是规则语言。

    3、插件通信

    单个规则并不需要依赖其他规则,因此规则之间没有主动的通信,规则只需要输出数据或者事件。

    展开全文
  • 微内核架构设计

    2020-12-15 22:02:26
    简介:作为一名Java程序员,相信同学们都听说过微内核架构设计,也有自己的理解。那么微内核是如何被提出来的?微内核在操作系统内核的设计中又有什么作用?本文从插件化(Plug-in)架构的角度来诠释微内核架构设计,...

    简介:作为一名Java程序员,相信同学们都听说过微内核架构设计,也有自己的理解。那么微内核是如何被提出来的?微内核在操作系统内核的设计中又有什么作用?本文从插件化(Plug-in)架构的角度来诠释微内核架构设计,通过微内核架构和微服务架构的对比,分享其对微服务设计的参考意义。

    image.png

    关于微内核架构设计现在比较热,听起来好像是操作系统内核相关的,作为Java程序员,操作系统内核那么遥远的事情,好像和我们没有什么关系。但是如果我说微内核其实就是插件化(Plug-in)架构,你一定会一脸疑惑,“你居然向Java程序员解释什么是插件化架构?我每天都在用啊,Eclipse、IntelliJ IDEA、OSGi、Spring Plugin、SPI等,哪个不是插件化架构。我的一些项目也是采用插件化设计的,如使用插件实现流程控制定制等等”。但是别着急,即便是我们每天都在使用的技术,而且大多数人也都知道,如果我们能将其阐述得更清楚,并且能从中发现一些问题,做出一些优化有助于以后的架构设计,那么大多数人在日常的设计和开发中都能受益,岂不是更好。现在我们就来聊一聊微内核架构设计。

    一 微内核设计之操作系统内核

    微内核设计其实就是插件体系。我们都知道,操作系统内核诞生得比较早,所以插件化最早被用在内核设计上,于是就有了微内核设计这一称呼。

    微内核是这样一种内核:它只完成内核不得不完成的功能,包括时钟中断、进程创建与销毁、进程调度、进程间通信,而其他的诸如文件系统、内存管理、设备驱动等都被作为系统进程放到了用户态空间。说白了,微内核是相对于宏内核而言的,像Linux就是典型的宏内核,它除了时钟中断、进程创建与销毁、进程调度、进程间通信外,其他的文件系统、内存管理、输入输出、设备驱动管理都需要内核完成。

    也就是说,微内核是相对宏内核而言的,宏内核是一个包含非常多功能的底层程序,也就是我们现在讲的Monolith。它干的事情非常多,而且不是可插拔的,修改一些小的功能,都会涉及到整个程序的重新编译等,比如一个功能出现了一个小bug,可能导致整个内核都出问题。这也是很多人将Linux称为monolithic OS的原因。而微内核只负责最核心的功能,其他功能都是通过用户态独立进程以插件方式加入进来,然后微内核负责进程的管理、调度和进程之间通讯,从而完成整个内核需要的功能。基本一个功能出现问题,但是该功能是以独立进程方式存在的,不会对其他进程有什么影响从而导致内核不可用,最多就是内核某一功能现在不可用而已。

    微内核就是一个运行在最高级别的程序片段,它能完成用户态程序不能完成的一些功能。微内核通过进程间通信来协调各个系统进程间的合作,这就需要系统调用,而系统调用需要切换堆栈以及保护进程现场,比较耗费时间;而宏内核则是通过简单的函数调用来完成各个模块之间的合作,所以理论上宏内核效率要比微内核高。这个和微服务的架构设计一样,我们将Monolith应用划分为多个小应用后,系统的设计就变得比较复杂了,之前都是应用内部函数调用,现在要涉及网络通讯、超时等问题,同时响应时间会被拉长。

    聊到这里,相信大家对微内核和宏内核已经有了一个大致的了解,看起来各有千秋。但是宏内核有一个最大的问题就是定制和维护陈本。现在的移动设备和IoT设备越来越多,如果要把一个庞大复杂的内核适配到某一设备上,是一件非常复杂的事情,如果很简单的话,那么把Linux内核适配到Android内核,甚至到Tesla等车载系统,基本上人人都可以做了。

    因此我们更需要一个微内核的架构设计,方便定制,而且非常小,可以实现功能的热替换或者在线更新等,这就是微内核被提出来的核心需求。但是微内核有一个运行的效率问题,所以在微内核和宏内核之间,又有了Hybrid内核,主要是想拥有微内核的灵活性,同时在关键点上有宏内核的性能。微内核设计在理论上确实有效率问题,但是随着芯片设计、硬件性能提升等,这方面或许已经有了非常大的提升,已经不再是最关键的问题。

    总体下来,内核设计有三个形式,如下:

    image.png

    二 插件化(Plug-in)架构设计

    上面聊了微内核在操作系统内核设计中的作用,接下来我们就开始讨论更通用的插件化架构设计,毕竟这个词大家都明白。

    插件化架构非常简单,就两个核心组件:系统核心(Core System)和插件化组件(Plug-in component)。Core System负责管理各种插件,当然Core System也会包含一些重要功能,如插件注册管理、插件生命周期管理、插件之间的通讯、插件动态替换等。整体结构如下:

    image.png
    插件化架构对微服务架构设计帮助非常大,考虑到隔离性,插件可能是以独立进程方式运行的,那么这些进程如果扩展到网络上,分布在众多的服务器上,这个就是微服务架构的原型,所以了解微内核的同学都不屑于和你讨论微服务架构,相信你也明白了,除了IT传统的鄙视链因素,原理上确实就是这么回事。

    回到微服务架构设计场景,我们将Plug-in component重新命名为服务(Service),这个和微内核设计中的服务也差不多,这个时候微服务和微内核就差不多了,都涉及到服务注册、管理和服务之间的通讯等。那我们看一下微内核是如何解决服务之间的通讯问题的?以下摘自维基百科:

    因为所有服务行程都各自在不同地址空间运行,因此在微核心架构下,不能像宏内核一样直接进行函数调用。在微核心架构下,要创建一个进程间通信机制,通过消息传递的机制来让服务进程间相互交换消息,调用彼此的服务,以及完成同步。采用主从式架构,使得它在分布式系统中有特别的优势,因为远程系统与本地进程间,可以采用同一套进程间通信机制。

    也就是说,采取的是基于消息的进程间通讯机制。消息最简单,就两个接口:send和receive,消息发送出去,然后等着收消息,处理后再发消息就可以了,这里大家应该也知道了,这个是异步的。回到插件化架构设计中,Plug-in组件设计包含交互规范,也就是和外界相互通讯的接口,如果是基于消息通讯的话,就是send和receive接口,可以说是非常简单的。

    但是这里还有一个问题,那就是进程间通讯。你可能会问,这个有什么好疑问的,就是两个进程之间相互发消息呗。但是这里有一个最大的疑问,那就是进程间通讯是否有第三者介入?如下图:

    image.png

    当然在操作系统的内核设计中,一定是通过内核进行转发的,就是我们理解的总线架构,内核负责协调各个进程间的通讯。这个大家也能理解,如果进程A直接发给另外一个进程B,必然要了解对应的内存地址,微内核中的服务是可以被随时替换的,如果服务不可用或者被替换,这个时候要通知和其通讯的其他进程,是不是太复杂?刚才已经提到,只有send和receive接口,没有其他通知下线、服务不可用的接口。在微内核的设计中,一定是通过总线结构,进程向Kernel发送消息,然后kernel再发送给对应的进程,这样的一个总线设计。实际上很多应用内部在做Plug-in组件解耦时,都会使用EventBus的结构,其实就是总线的设计机制。

    为何婆婆妈妈说这些?因为非常关键。分布式的进程通讯是微服务的核心,我们理解的服务到服务的通讯,就是服务A启动监听端口,服务B会和服务A建立连接,然后两者通讯即可。这个方式和微内核设计中内核负责消息接收和转发的总线架构设计是不一样的。如采用HTTP,HSF等通讯协议时,相当于kernel告知通讯的双方各自的地址,然后它们之间就可以通讯了。然后就没有Kernel什么事情了,也不会用到什么总线的结构设计,这个就是传统的服务发现机制。

    但是还有一种模式,就是完全透明的插件化通讯机制,如下图:

    image.png

    Plug-in组件,也就是微服务架构中的服务,是不能直接通讯的,而是需要Core System进行转发。这样做的好处和微内核架构一样,插件相互之间无直接联系,彼此之间非常透明,例如服务A下线后,完全不需要通知其他服务;服务A被替换,也不需要通知其他服务;服务A从数据中心1到数据中心2,也不用通知其他服务;即便服务N和服务A之间网络不互通,两者之间也能通讯。

    这里有个问题:性能问题。我们都知道,两点之间,直线段最短。为何要多绕一下到Core System呢?这就是微内核和宏内核之间的争论之处,使用函数调用非常快,而进程间的消息通讯则是非常慢的,但是这种通过中介进行通讯机制的好处也是非常明显的。那么如何提升这种基于总线的通讯性能呢?当然有,比如选择高性能的二进制协议,HTTP 1.1这种文本协议就不需要了;采用Zero Copy机制,可以快速进行网络包转发;好的网络硬件,如RDMA;好的协议,如基于UDP的QUIC等。总结下来,和微内核一样,这种微服务通讯的性能是可以提升的。当然如果实在受不了这种性能,在关键场景,你可以采用Hybrid模式,混入一些服务之间直接通讯的设计,但只能在性能极致的场景中使用。

    此外,插件化架构中的插件组件是各种各样的,通讯的机制也各不一样,一些是RPC的,一些是Pub/Sub的,一些是无需ACK的(如Beacon接口),还有一些是双向通讯的等等。当然你可以选择不同的通讯协议,但是这里有一个问题,就是Core System需要理解这个协议,然后才能进行消息路由。这个时候Core System需要编写大量的Adapter来解析这些协议,例如Envoy包含各种filter来支持不同的协议,如HTTP、MySQL、ZooKeeper等,但是因此Core System就会变得非常复杂且不稳定。

    另外可以选一种通用的协议,Core System只支持这一种协议,各个插件之间都基于该协议通讯,至于服务和其他外部系统如何通讯,如数据库、github集成等,这些Core System并不关心,那只是Service内部的事情。目前比较通用的协议是gRPC,如K8s内部都会采用该协议,另外Dapr也采用gRPC协议做服务集成,因为gRPC提供的通讯模型基本可以满足大多数的通讯场景。当然另外一个就是RSocket,提供更丰富的通讯模型,也适用于Core System这种服务间通讯场景。对比gRPC,RSocket可以运行在各种传输层上,如TCP、UDP、WebSocket、RDMA等,相反的,gRPC目前只能运行在HTTP 2之上。

    三 服务通讯的延伸

    前面说到,最好由插件化架构设计的Core System作为服务之间消息通讯的路由,如果是这样的话,就会产生一种Broker模式,当然也有可能是Agent。这里大家一定会想到Service Mesh,没错。当然你可以选择Agent Sidecar模式,也可以选择中心化的Broker模式,这两者的功能都是一样的,只是处理的方式不一样而已。Agent基于服务注册和发现机制,然后找到对方服务的Agent,再进行两个Agent之间的通讯,只是省掉服务之间的调用的开销。但是Broker是集中式的,大家都向Broker发送和接收消息,不涉及服务注册发现机制,不涉及服务元信息推送,就是总线结构。

    我现在做的就是基于这种Broker的总线的架构设计,在RSocket Broker中,也是采用微内核架构设计,当然未必做得最好 。RSocket Broker核心就是管理注册的服务、路由管理、数据采集等,而不会添加过多的功能,和Core System的设计理念一样,只添加必须的功能。如果你要扩展整个系统更多的功能,如发短信、发邮件、对接云存储服务等,需要编写一个Service ,然后和Broker对接一下,再从broker那里收消息(receive),处理完毕后再发送(send)给Broker就可以了。总体结构如下:

    image.png

    有不少同学会问,当服务实例的负载太高的时候,Broker如何实现动态扩容呢?Broker会给你提供数据,如一个服务实例QPS,至于是否扩展,你只需要写一个服务,从Broker上采集数据,分析后,调用K8s API进行扩容即可,Broker并不负载这些业务功能,它只会添加非常必要的功能,这个和Core System设计是一样的。

    回到插件化架构的灵活性上,如果系统中有一个KV存储的插件,你只要遵循消息格式或者通讯接口,就可以保存KV数据。但是你并不太关心是Redis存储的,还是Tair存储的,或者是云端的KV服务,这就为服务标准化和可替换性提供了很好的基础,这对应用上云或云原生化帮助非常大,整个系统有非常大的灵活性。

    四 总结

    其实有非常多的书有关于微内核的介绍,操作系统的图书就不用说了,另外两本书也非常不错,对通用架构设计帮助也非常大,尤其是微服务的场景,我也是参考这两本书写这篇文章的。

    image.png

    微内核架构设计对微服务设计有非常好的参考意义,但是微服务有一个非常大的问题就是服务边界的划分,对比操作系统,已经发展几十年,而且非常稳定,功能划分非常容易。而微服务架构是为业务服务的,虽然面对的业务可能已经存在上百年,但是软件化、数字化和流程化并没有多少年,加上现实业务的复杂性,还有各种妥协,个人认为微服务架构会更复杂一些。

    原文链接:https://developer.aliyun.com/article/779572?

    展开全文
  • 什么是微内核架构

    2021-03-09 00:28:12
    什么是微内核架构相信大家都听说过微内核架构,也或多或少做过一些类似于微内核架构的设计,为了可以更好的设计出微内核的架构,我们了解下什么是微内核架构。说到微内核架构,大家首先会想到的是Ecl...

    什么是微内核架构

    相信大家都听说过微内核架构,也或多或少做过一些类似于微内核架构的设计,为了可以更好的设计出微内核的架构,我们了解下什么是微内核架构。

    说到微内核架构,大家首先会想到的是Eclips、IDEA、OSGI、Spring Plugin、SPI等,这些都是我们熟知的微内核架构。有了微内核架构,我们可以更好的定制和控制流程,所以微内核架构的设计思想经常在做配置化中台项目的方案中出现的。

    微内核架构实现主要是插件化思想(Plug-in),是一套插件体系,最早的插件化方法是应用在操作系统之上,久而久之就有了微内核设计这一思想。

    了解微内核,需要先了解这个“内核”。

    在操作系统中,内核围绕于操作系统的核心功能,比如时钟中断、进程创建与销毁、进程调度、进程间通信等内核态的动作。而文件系统、内存管理、设备驱动等都被视为非内核能力,这部分会被放在用户态空间。

    微内核是相对于宏内核而言,宏内核包含了很多的底层程序功能,做的事情非常多,而且不是可拔插的,修改任意一个功能点,都需要整个程序联动,而且有可能引入一个bug,导致整个内核不可用,类似于一个功能复杂的单体系统,每次变更和交付成本都非常高,风险也非常大。

    而微内核只围绕于核心功能设计,他的功能实现都是相互独立的,其他非核心功能是通过用户态的独立进程以插件的方式加入进来的,微内核引擎负责管理进程、调度进程、进程之间通信。某一个功能出现问题时,由于其是独立的进程,不会对其他进程产生影响,也不会导致内核不可用。

    微内核中,多个进程协调通信,需要进行系统调用,系统调用需要切换堆栈及保护进程现场,过程比较耗时。宏内核(也就是用户态)中,是通过函数调用完成各个模块之间合作,所以宏内核较微内核效率更高。

    通过操作系统微内核概念,可以类比到业务系统。一个系统,特别是经过微服务拆分之后的系统,都会服务于某个“内核”,多个核心功能通过微服务的方式拆分,服务之间通过通信交换数据。通过微内核解决了快速交付问题,实现了代码隔离,控制风险点的目的。

    而考虑到扩展性,我们需要定义出内核的骨架,并开放出plugin,以实现个性化扩展。这样的微内核架构,我们可以便于定制,改动小,进而实现热更新,这也是微内核架构的主要价值。

    微内核架构设计

    在微内核架构中有两个核心组件:系统内核、插件化组件。

    系统内核:主要解决的是内核的核心功能,比如插件的注册与管理、插件生命周期管理、插件之间通信、插件的热加载与替换。

    结构如下:

    基于微内核的插件化设计,我们可以实现组件隔离,每个插件可以以独立jar包或独立进程运行,这些插件组件进程可以独立部署在分布式网络上,实现水平扩展,某种程度就像我们的微服务治理体系,有独立部署的微服务进程,也有中心治理的注册中心与配置中心。

    在操作系统中,微内核与宏内核通信方式上有如下区别:

    微内核架构下,组件之间的通信也是基于消息的,比如每个组件对于消息处理有两个能力:收(receive)、发(send)。

    那两个进程之间通信,是否需要一个三方中介呢?比如这样:

    在操作系统中,消息的通信是基于内核转发的,也就是我们经常听说的消息总线架构,内核负责协调各个进程的通信,比如进程A想要发送消息给进程B,需要知道B对应的内存地址。进程向内核发送消息,内核再将消息发送给对应的接收进程,这就是一个总线通信过程。

    在很多微内核架构设计实现上,组件之间都可以通过EventBus实现Plug-in之间的解耦,也就是借鉴了总线的设计。

    在微服务架构的通信实现上,在SOA时代,有类似于消息总线的概念。但微服务是进程之间的直接调用,没有了这个所谓的总线。

    但是如果引入了一个中心化的服务注册与发现中心,就可能也会有个所谓的内核中转:

    在插件化系统中,组件之间不直接通信,而是借助于一个中心化的内核系统进行转发。这种设计思想非常类似于操作系统的内核转发实现,插件之间隔离、透明。某个组件下线或替换,其他组件不需要感知。

    这样的架构会存在于一些其他的问题。首先,这个中心化的转发中介变成了单点,其可用性严重影响了整个系统的可用性。当中心化系统变成单点转发,就存在对应的性能问题。

    对于远程进程调用的性能优化,我们可以想到这几点:

    1. 采用高性能的二进制协议代替http1.x协议,因为http1.1的文本协议性能较差;

    2. 采用类似于零拷贝机制,实现快速网络包转发,而不需要做内核态与用户态的转换;

    3. 引入好的网络硬件,比如RDMA;好的协议,如UDP、QUIC等;

    4. 选择不同的通信方式,比如RPC的、Pub/Sub的、无序ACK的、单工/双工通信的等;

    为了处理这么多协议的转发,内核系统需要具备Adapter以实现对于众多协议的解析与转发,比如引入多个filter来支持不同的协议,但是他将变得越来越复杂。

    还有一种思路是,内核服务只支持一种协议,各个插件之间也基于这个协议通信,协议的适配与转换由各个组件自己做就可以。

    其实很多人会想到,这个中心化的内核组件的消息转发不就是类似于一个MQ系统的Broker吗?而那种独立处理通信协议的组件不就类似于Mesh设计吗?

    没错,前一种类似于类似于broker,后一种类似于service mesh或agent思想。功能上是一样的,只是处理逻辑上有些差异。

    broker是集中式的,所有组件通过broker进行消息的收发,涉及到注册与发现机制。mesh是基于服务的注册与发现,消息发送需要找到对方的agent,再实现两个agent之间的通信。

    broker方案设计核心在于,broker需要管理注册的服务、路由的管理、数据的采集等这些核心功能,类似于微内核的内核本身理念一样。如果要扩展整个微内核架构能力,需要编写独立的service,之后和broker对接,在broker接收消息,处理完毕后发送消息。

    那中心的broker负载太高如何扩容呢?因为broker本身具有服务调用的数据采集能力,所以可以从这里采集,作为扩缩容的参考,经过分析后,可以调用k8s的api实现pod的扩缩容了。

    我们可以发现,这套围绕于内核的核心设计以及扩展service的思想非常的云原生,比如上层业务系统想要调用存储服务,微内核系统可以对外提供一个消息存储的api,而这套api可以按需扩展是基于redis、还是tair或是其他kv,为服务标准化和可替代性提供了很好的基础,对上云操作非常友好,也就体现了云原生的灵活性。

    中心化转发和点对点发送,两个方案各有优缺点,架构就是一个取舍的过程,我们需要结合自己系统的特点和体量决定选择合适的方案。

    总结

    微内核架构对于我们做微服务设计,或是偏中台、平台系统设计提供了非常好的参考建议,比如对于微服务边界的划分,我们完全可以参考操作系统的设计,经过几十年的发展,其设计之精妙已经被验证了,非常稳定,功能划分也非常合理。

    展开全文
  • 从鸿蒙OS谈谈微内核架构

    万次阅读 多人点赞 2019-08-09 22:11:43
    从华为鸿蒙OS谈谈微内核架构 微内核架构简介

        今天最耀眼的莫过于华为鸿蒙OS!
    在这里插入图片描述
        贸易战至今,更深层次是一次高新科技自主创新的较量,是美国少有的几次技术垄断保卫战。表面看是中美两国的较量,实则给几乎所有国家敲响一次警钟 – 任何一个国家,科技强国战略处于不可动摇地位!信息化时代,科技制裁几乎可以决定一个民族的命运!
      美帝洋洋自得的正在于此,仰仗着自己科技实力、军事实力老大哥的地位,动辄招惹其他国家,随心所欲的薅羊毛,但这次或许难以梦想成真。华为鸿蒙OS的诞生,着实给美帝当头一棒,或许这个世界真的需要两套系统,我想世界人民的愿望大都如此吧?

        如图中所示,鸿蒙OS是一款基于微内核的全场景分布式操作系统,那么你的疑问来了?

    1. 什么是微内核?
    2. 目前已经存在的系统都不是微内核架构吗?

    微内核
        在软件开发领域,微内核是一种架构原则,其同时也被称为插件化架构。此种架构最大的优势是允许第三方开发者添加额外的插件化应用,前提是该插件应用需要遵从下文所述的开发规范。采用微内核架构的软件随处可见,如IDE软件Eclipse、企业ERP软件,这类软件自身具备丰富功能,同时支持第三方应用的即插即用。而且,第三方插件化程序的安装、运行、卸载以及故障不会对原有系统造成任何影响。

    • 架构图
      在这里插入图片描述
          微内核架构包含两类组件:核心系统和插件系统。核心系统的功能稳定,很少变更,其只拥有能使应用运行的最小功能逻辑,这些通用逻辑(例如插件模块的注册、加载、卸载,以及插件模块之间的相互通信等)不涉及任何特定业务;插件系统则具备良好的扩展性,其负责实现特定的业务逻辑,可根据特定业务需求而变更。
          显而易见,微内核架构本质上其实是将一个软件系统中的变化部分封装在插件中,从而实现不同业务之间的隔离性,达到系统快速灵活扩展的目的,同时所有特定业务相关逻辑的变更不会影响整体系统的稳定性。

    • 设计要点
      微内核架构设计有以下三个关键点:插件管理、插件链接和插件通信。

    1. 插件管理
          核心系统需要知道当前系统中共有多少个插件,哪些插件处于可用状态,什么时候加载一个插件,如何加载一个插件等。
          实现上述功能的一个常用机制是插件注册表:核心系统提供一个服务来响应插件的注册请求,最终将当前系统的所有插件信息(插件标识,类别,启动方式等)保存起来。存储方式可以选择配置文件存储或者数据表存储等。
      在这里插入图片描述
    2. 插件链接
          插件链接制定了一个插件与核心系统的通信方式,也就是链接规范,故任何一个可用插件都务必遵从核心系统中该类别插件所制定的链接规范。
          常见的链接规范有OSGI(Eclipse),消息队列,依赖注入(Spring),RPC等。
    3. 插件通信
          插件模块的设计是为了达到低耦合目的,也符合这一原则。但一个业务请求往往需要几个插件模块共同协作来实现,这就需要插件之间可以实现相互通信。插件之间的通信则需要通过中央处理器(核心系统)来作为桥梁,故核心系统除去提供上文提及的注册表机制之外,还需要提供类似操作系统总线之类的通信机制。
    • 深入探讨
    1. OSGI(Open Service Gateway Initiative)架构
          OSGI是一个插件化的标准而非一个可运行框架,当前遵循该标准的软件有:Eclipse, Apache Felix, Spring DM。其具备热插拔、扩展性、可复用性、高效性、稳定性的优点。请参看下面的逻辑架构图:
      在这里插入图片描述
          Module Layer:模块层主要涉及Jar包及共享的代码;
          Lifecycle Layer:生命周期层主要涉及组件的运行时生命周期管理;
          Service Layer:服务层主要涉及模块之间的交互和通信。
    2. 规则引擎架构
          规则引擎其实是微内核架构的一中具体实现,其执行引擎可以看作是微内核架构中的核心系统,执行引擎解析配置好的业务流规则,进而执行其中的条件和规则,以此来支撑业务层面的灵活性和扩展性。
          规则引擎常用于计费、保险、促销等业务领域,其存在以下几个优点:
      a. 便于扩展
          利用规则引擎,业务逻辑实现与业务系统分离,可以在不改动业务系统的情况下,灵活扩展业务共功能。
      b. 便于理解
          规则通过自然语言描述,业务人员更容易理解和操作。
      c. 可视化
          规则引擎一般情况下,会提供可视化的规则定制、审批、查询、管理及示例规则,便于业务人员快速配置,满足业务发展需求。
      在这里插入图片描述
      对上图的简要介绍如下:
          开发人员将业务功能分解提炼为多个规则,将规则保存在规则库中;
          业务人员根据业务需要从规则库中拉取规则,并将规则排列组合,配置成业务流程,并保存在业务库中;
          规则引擎同时从规则库和业务库中拉取规则,解析业务人员配置的业务流程,最终实现业务功能。

             感兴趣的同学可以了解下当前主流的开源规则引擎 JBoss Drools


    Linux是否是微内核架构
        查阅了一些资料,目前说法不太一致,故暂且不更新该章节!

    展开全文
  • 5.36微内核架构详解

    2020-05-15 17:02:51
    date comments categories tags permalink title 2020/4/12 true 软件架构 架构 微内核 5.36 微内核架构详解 ...微内核架构(Microkernel Architect...
  • 《分析微内核架构操作系统优缺点》由会员分享,可在线阅读,更多相关《分析微内核架构操作系统优缺点(2页珍藏版)》请在人人文库网上搜索。1、分析微内核架构操作系统优缺点一 优点:1.1 提高了可扩展性由于微内核OS...
  • 架构师修炼系列【微内核架构

    千次阅读 2020-09-19 23:58:44
    微内核架构也被称为插件化架构,它是一种面向功能进行拆分的可扩展性架构,通常用于实现基于产品的应用(product-based与web-based相对),微内核架构包含两类组建:核心系统和插件模块,核心系统负责和具体业务无关...
  • 什么是微内核架构设计?.pdf
  • 基于微内核架构的实时虚拟化技术的研究
  • Qt 微内核架构实践

    2021-07-15 22:41:45
    微内核架构的核⼼心系统⼀一般情况下只包含⼀一个能够使系统运作起来的最⼩小化模块。很多操作系统的实现就是使⽤用微内核架构,因此这也是该架构名字的由来。从商业应⽤用的⾓角度看,核⼼心系统通常是为特定的使⽤...
  • 寄居架构和裸金属架构是虚拟机软件常采用的两种技术模式,其中裸金属模式虚拟机又分为微内核和单内核 两种技术架构,与单内核架构相比,微内核具有更高的安全性,Hyper-V采用的是微内核架构。在对微内核架构技术详 细...
  • 什么是微内核架构设计?

    千次阅读 热门讨论 2020-12-04 13:05:14
    简介:作为一名Java程序员,相信同学们都听说过微内核架构设计,也有自己的理解。那么微内核是如何被提出来的?微内核在操作系统内核的设计中又有什么作用?本文从插件化(Plug-in)架构的角度来诠释微内核架构设计,...
  • 微内核架构(Microkernel Architecture),也被称为插件化架构(Plug-inArchitecture),是一种面向功能进行拆分的可扩展性架构,通常用于实现基于产品(原文为 product-based,指存在多个版本、需要下载安装才能...
  • 微内核架构因其有效的模块隔离性而成为操作系统方面研究的热点,多线程机制是微内核架构需要解决的关键性能问题。有不少的工作对微内核架构多线程机制进行了研究,但存在频繁的系统地址空间切换和实现复杂度高的问题...
  • 一、微内核架构简介1. 1 微内核的概念微内核架构(Microkernel Architecture),有时也被称为插件化架构(Plug-in Architecture),是一种面向功能...
  • 微内核架构模式

    2012-12-07 12:48:36
    写本篇主要是用来后面写一篇可扩展性软件设计打好基础。 [b]微内核定义:[/b] 微内核是内核的一种精简形式。将通常与内核集成在一起的...微内核架构模式来源于操作系统,本文主要讲解微内核模式在应用软件中的...
  • 微内核架构在 Dubbo 的应用
  • 我们通过Soul网关插件的执行流程可以发现,soul网关的设计特别像微内核架构中的规则引擎,今天我们就来看看微内核架构,以及Soul里面使用它的影子; 什么是微内核架构微内核架构,也被称为插件化架构,是一种面向...
  • MicroKernel是一个客户端微内核架构。从另一个角度来看,MicroKernel提供了最佳实践,也就是说,MicroKernel也是实现了其架构思想的框架。
  • 操作系统微内核架构研究

    千次阅读 2020-11-18 17:02:46
    1. 简介 微内核是操作系统内核的一种,在工控系统、嵌入式系统、实时系统等领域发挥着重要作用。本文较为全面地研究了微内核技术的各个方面,包括微内核的定义...从内核架构来划分,操作系统内核可分为微内核(Micro K
  • 微内核架构模式(也称为插件化应用架构)对于基于产品的应用程序来说是一个很自然的选择。基于产品的应用是指一个经过打包的、可以通过版本下载的一个典型的第三方产品。然而,很多公司也会开发和发布他们的内部商业...
  • Dubbo 授渔:微内核架构在 Dubbo 的应用

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 27,340
精华内容 10,936
关键字:

微内核架构