认识达内从这里开始

高可用与可扩展性都是目前大多数软件开发项目都需要满足的一个编程开发需求，而本文我们就通过案例分析来简单了解一下，可扩展性架构模式类型都有哪些。

1、接口级的故障

接口级故障的表现就是系统并没有宕机，网络也没有中断，但业务却出现问题了。例如，业务响应缓慢、大量访问超时、大量访问出现异常(给用户弹出提示“无法连接数据库”)，这类问题的主要原因在于系统压力太大、负载太高，导致无法快速处理业务请求，由此引发更多的后续问题。

导致接口级故障的原因一般有下面几种：

内部原因，程序bug导致死循环，某个接口导致数据库慢查询，程序逻辑不完善导致耗尽内存等。

外部原因，黑客攻击、促销或者抢购引入了超出平时几倍甚至几十倍的用户，其他系统大量请求，其他系统响应缓慢等。

解决接口级故障的核心思想和异地多活基本类似：优先保证核心业务和优先保证绝大部分用户。

降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。例如，论坛可以降级为只能看帖子，不能发帖子。

熔断是禁止访问的意思，例如A服务内部只要发现是请求B服务的这个接口就立即返回错误，从而避免A服务整个被拖慢甚至拖死。

限流指只允许系统能够承受的访问量进来，超出系统访问能力的请求将被丢弃。

2、可扩展架构模式

可扩展性架构的设计方法很多，但万变不离其宗，所有的可扩展性架构设计，背后的基本思想都可以总结为一个字：拆!

按照不同的思路来拆分软件系统，就会得到不同的架构。常见的拆分思路有如下三种。

面向流程拆分：将整个业务流程拆分为几个阶段，分层架构，例如展示层→业务层→数据层→存储层。

面向服务拆分：将系统提供的服务拆分，SOA、微服务，例如将系统拆分为注册、登录、信息管理、安全设置等服务。

面向功能拆分：将系统提供的功能拆分，微内核架构，每个服务都可以拆分为更多细粒度的功能，例如手机注册、邮箱注册等。

3、微内核架构

微内核架构包含两类组件：核心系统(coresystem)和插件模块(plug-inmodules)。

核心系统负责和具体业务功能无关的通用功能，例如模块加载、模块间通信等;插件模块负责实现具体的业务逻辑，例如专栏前面经常提到的“学生信息管理”系统中的“手机号注册”功能。

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

插件管理，核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。

插件连接，插件连接指插件如何连接到核心系统。通常来说，核心系统必须制定插件和核心系统的连接规范，然后插件按照规范实现，核心系统按照规范加载即可。

插件通信，插件通信指插件间的通信。虽然设计的时候插件间是完全解耦的，但实际业务运行过程中，必然会出现某个业务流程需要多个插件协作，这就要求两个插件间进行通信。

规则引擎从结构上来看也属于微内核架构的一种具体实现，其中执行引擎可以看作是微内核，执行引擎解析配置好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵活多变。

对照微内核架构的设计关键点，我们来看看规则引擎是具体是如何实现的。

规则引擎中的规则就是微内核架构的插件，引擎就是微内核架构的内核。

规则引擎的插件连接实现机制其实就是规则语言。

规则引擎的规则之间进行通信的方式就是数据流和事件流，规则只需要输出数据或者事件，由引擎将数据或者事件传递到下一个规则。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。