可扩展架构 (分层架构、SOA、微服务、微内核架构)

可扩展的基本思想：都可以总结为一个字：拆！就是将原本大一统的系统拆分成多个规模小的部分，扩展时只修改其中一部分即可，无须整个系统到处都改，通过这种方式来减少改动范围，降低改动风险

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

面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为一部分。

比如：信息管理学系统的 展示层 → 业务层 → 数据层 → 存储层

面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。

比如：将系统拆分为注册、登录、信息管理、安全设置等服务，

 

面向功能拆分：将系统提供的功能拆分，每个功能作为一部分

比如：每个服务都可以拆分为更多细粒度的功能：比如注册服务、登陆服务、信息管理服务、安全设置服务

 

从范围上来看，从大到小依次为：流程>服务>功能。不同的拆分方式，本质上决定了系统的扩展方式，可以保证证即使程序员出错，出错的范围也不会太广

  1.面向流程拆分：扩展时大部分情况只需要修改某一层，少部分情况可能修改关联的两层，不会出现所有层都同时要修改。例如学生信息管理系统，如果我们将存储层从MySQL扩展为同时支 持MySQL和Oracle，那么只需要扩展存储层和数据层即可，展示层和业务层无须变动。

  2.面向服务拆分：对某个服务扩展，或者要增加新的服务时，只需要扩展相关服务即可，无须修改所有的服务。同样以学生管理系统为例，如果我们需要在注册服务中增加一种“学号注册”功能，则只 需要修改“注册服务”和“登录服务”即可，“信息管理服务”和“安全设置”服务无须修改。

  3.面向功能拆分 对某个功能扩展，或者要增加新的功能时，只需要扩展相关功能即可，无须修改所有的服务。同样以学生管理系统为例，如果我们增加“学号注册”功能，则只需要在系统中增加一个 新的功能模块，同时修改“登录功能”模块即可，其他功能都不受影响。

不同的拆分方式，将得到不同的系统架构，典型的可扩展系统架构有：

  面向流程拆分：分层架构（分层架构的本质，就是固定的内核，移动的数据）

  面向服务拆分：SOA、微服务

  面向功能拆分：微内核架构(插件式架构)

上述的架构是可以在系统架构设计中进行组合使用的。

 1、整体系统采用面向服务拆分中的“微服务”架构，拆分为“注册服务”“登录服务”“信息管理服务”“安全服务”，每个服务是一个独立运行的子系统。

 2、其中的“注册服务”子系统本身又是采用面向流程拆分的分层架构。

 3、“登录服务”子系统采用的是面向功能拆分的“微内核”架构。

总结分析：因为本人主要负责的是规则引擎的部分，分析后可以得出，肯定不是分层架构，即不是面向流程的，因为规则引擎主要作用在业务层。其次，也不应该是面向服务的，因为规则引擎都是跨越多个服务的。 规则引擎和插件式架构，解决的都是功能扩展的问题。微内核架构就是一种插件式架构。（扩展：规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策）

分层架构和SOA：

分层架构：是很常见的架构模式，它也叫N层架构。例如，C/S架构、B/S架构。常见的是3层架构（例如，MVC、MVP架构）

. C/S架构、B/S架构：划分的对象是整个业务系统，划分的维度是用户交互，即将和用户交互的部分独立为一层，支撑用户交互的后台作为另外一层。

       是C/S架构结构图

       MVC架构、MVP架构

 

分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰，边界足够明显，让人看到架构图后就能看懂整个架构，分层时要保证层与层之间的依赖是稳定的，才能真正支撑快速扩展。分层架构之所以能够较好地支撑系统扩展，本质在于隔离关注点，即每个层中的组件只会处理本层的逻辑。

分层结构的另外一个特点就是层层传递，也就是说一旦分层确定，整个业务流程是按照层进行依次传递的，不能在层之间进行跳跃。所以导致分层架构典型的缺点就是性能，因为每一次业务请求都需要穿越所有的架构分层，有一些事情是多余的，多少都会有一些性能的浪费。

面向服务的架构 SOA：

SOA出现的背景是企业内部的IT系统重复建设且效率低下，主要体现在：

1、企业各部门有独立的IT系统，随着业务的发展，复杂度越来越高，更多的流程和业务需要多个IT系统合作完成。

2、各个独立的IT系统实现技术不同，企业自己也不太可能基于这些系统进行重构。

 

SOA的3个关键概念：

服务：所有业务功能都是一项服务，服务就意味着要对外提供开放的能力，当其他系统需要使用这项功能时，无须定制化开发。

ESB：将企业中各个不同的服务连接在一起。SOA使用ESB来屏蔽异构系统对外提供各种 不同的接口方式，以此来达到服务间高效的互联互通。

松耦合：目的是减少各个服务间的依赖和互相影响。因为采用SOA架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖。如果做不到松耦合， 某个服务一升级，依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。

总结：SOA解决了传统IT系统重复建设和扩展效率低的问题，但其本身也引入了更多的复杂性。SOA最广为人诟病的就是ESB，ESB需要实现与各种系统间的协议转换、数据转换、透明的动态路由等功能、工作量和复杂度都很大，而且这种转换是需要耗费大量计算性能的，当ESB承载的消息太多时，ESB本身会成为整个系统的性能瓶颈

背景：SOA的ESB设计也是无奈之举，SOA的提出背景就可以发现，企业在应用SOA时，各种异构的IT系统都已经存在很多年了，完全重写或者按照统一标准进行改造的成 本是非常大的，只能通过ESB方式去适配已经存在的各种异构系统。

 

面向服务的架构 微服务：

微服务与SOA的关系：

相似点在于两者都关注“服务”，都是通过服务的拆分来解决可扩展性问题。本质上不同的地方在于几个核心理念的差异：是否有ESB、服务的粒度、架构设计的目标等。

1. 服务粒度（依赖服务治理系统）

对一个大型企业来说，“员工管理系统”就是一个SOA架构中的服务；而微服务架构，则“员工管理系统”会被拆分为更多的服务，比如“员工信息管理”“员工考勤管理”“员工假期管理”和“员工福利管理”等更多服务。

2、服务通信（依赖于RESTful API, RPC）

SOA采用了ESB作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，总体上是重量级的实现。微服务推荐使用统一的协议和格式，例如，RESTful协 议、RPC协议，无须ESB这样的重量级实现， 传统SOA架构最广为人诟病的就是庞大、复杂、低效的ESB。

3、服务交付（依赖敏捷开发技术(自动化测试,持续集成,自动化部署)）

SOA只考虑兼容已有系统，几乎不考虑交付需求，微服务的架构理念要求“快速交付”，相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践（如果没有这些基础能力支撑，微服务规模一旦变大（例如，超过20个微服务），整体就难以达到快速交付的要求，这也是很多企业在实行微服务时踩过的一个明显的 坑，就是系统拆分为微服务后，部署的成本呈指数上升。）

4、应用场景

SOA更加适合于庞大、复杂、异构的企业级系统，典型特征就是很多系统已经发展多年，采用不同的企业级技术

微服务更加适合于快速、轻量级、基于Web的互联网系统，这类系统业务变化快，需要快速尝试、快速交付，同时基本都是基于Web，虽然开发技术语言可能不同，但对外接口基本都是提供HTTP RESTful风格的接口，无须考虑在接口层进行类似SOA的ESB那样的处理。

small、lightweight、automated，基本上浓缩了微服务的精华，也是微服务与SOA的本质区别所在

 

微服务的缺点：

1、服务划分过细，单个服务的复杂度确实下降了，但整个系统的复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂度。整体系统的复杂度是随着微服务数量的增加呈指数级增加的。

2、.服务数量太多，团队效率急剧下降，一个需求涉及多个服务。是设计、开发、测试、部署，都需要工程师不停地在不同的服务间切换。

3、调用链太长，性能下降，（微服务之间都是通过HTTP或者RPC调用的，每次调用必须经过网络。一般线上的业务接口之间的调用，平均响应时间大约为50毫秒，如果用户的一起请求需要经过6次微服务调 用，则性能消耗就是300毫秒，这在很多高性能业务场景下是难以满足需求的。为了支撑业务请求，可能需要大幅增加硬件，这就导致了硬件成本的大幅上升)

4、 调用链太长，问题定位困难，一次用户请求需要多个微服务协同处理问题定位难，我们公司）在这方面上得益于强大的服务追踪系统也就是trace日志，后期我会进行深入研究写一篇文章进行详述，每个rpc请求都有相对应的日志，定位问题使其快速、便捷

5. 没有自动化支撑，无法快速交付（有自动化测试、自动化部署、自动化监控）

6. 没有服务治理，微服务数量多了后管理混乱

主要问题有：

服务路由：假设某个微服务有60个节点，部署在20台机器上，那么其他依赖的微服务如何知道这个部署情况呢？

服务故障隔离：假设上述例子中的60个节点有5个节点发生故障了，依赖的微服务如何处理这种情况呢？

服务注册和发现：同样是上述的例子，现在我们决定从60个节点扩容到80个节点，或者将60个节点缩减为40个节点，新增或者减少的节点如何让依赖的服务知道呢？

如果以上场景都依赖人工去管理，整个系统将陷入一片混乱，最终的解决方案必须依赖自动化的服务管理系统，这时就会发现，微服务所推崇的“lightweight”，最终也发展成 和ESB几乎一样的复杂程度。

 

面向功能架构：微内核架构（插件化架构）

是一种面向功能进行拆分的可扩展性架构，通常用于实现基于产品的应用

1、基本架构

微内核架构包含两类组件：核心系统和插件模块。核心系统负责和具体业务功能无关的通用功能，例如模块加载、模块间通信等；插件模块负责实现具体的业务逻辑

微内核的架构本质就是将变化部分封装在插 件里面，从而达到快速灵活扩展的目的，而又不影响整体系统的稳定。

微内核的核心系统设计的关键技术有：

插件管理：核心系统需要知道当前有哪些插件可用，如何加载这些插件，什么时候加载插件。常见的实现方法是插件注册表机制

插件连接：常见的连接机制有OSGi（Eclipse使用）、消息模式、依赖注入（Spring使用），甚至使用分布式的协议都是可以的，比如RPC或者HTTP Web的方式。

插件通信：虽然设计的时候插件间是完全解耦的，但实际业务运行过程中，必然会出现某个业务流程需要多个插件协作，这就要求两个插件间进行通信。由于插件之间没有直接联系，通信必须通过核心系统，因此核心系统需要提供插件通信机制。

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

好处：1、可扩展，充分与业务系统解耦 2、容易理解 3、高效率，方便RD快速配置新的业务