可扩展架构

《可扩展架构》由会员分享，可在线阅读，更多相关《可扩展架构（8页珍藏版）》请在装配图网上搜索。

1、可扩展架构（分层架构、SOA、微服务、微内核架构）可扩展的基本思想：都可以总结为一个字：拆！就是将原本大一 统的系统拆分成多个规模小的部分，扩展时只修改其中一部分即可， 无须整个系统到处都改，通过这种方式来减少改动范围，降低改动风 险按照不同的思路来拆分软件系统，就会得到不同的架构。常见的 拆分思路有如下三种：面向流程拆分：将整个业务流程拆分为几个阶段，每个阶段作为 一部分。比如：信息管理学系统的展示层-业务层-数据层-存储层 面向服务拆分：将系统提供的服务拆分，每个服务作为一部分。 比如：将系统拆分为注册、登录、信息管理、安全设置等服务，学哇僧息爸理藕班注瞬报裁f 矗區鲫 ）（H理厳势）（孜

2、全说矍罹勢面向功能拆分：将系统提供的功能拆分，每个功能作为一部分 比如：每个服务都可以拆分为更多细粒度的功能：比如注册服务 登陆服务、信息管理服务、安全设置服务学生傅克淸理索垛手机号注聊手帆号桑靈机学生邛僧洼册邮从范围上来看，从大到小依次为：流程服务功能。不同的拆分 方式，本质上决定了系统的扩展方式，可以保证证即使程序员出错， 出错的范围也不会太广1. 面向流程拆分：扩展时大部分情况只需要修改某一层，少部分 情况可能修改关联的两层，不会出现所有层都同时要修改。例如学生 信息管理系统，如果我们将存储层从MySQL扩展为同时支持MySQL 和Oracle，那么只需要扩展存储层和数据层即可，展示层和

3、业务层无 须变动。2. 面向服务拆分：对某个服务扩展，或者要增加新的服务时，只 需要扩展相关服务即可，无须修改所有的服务。同样以学生管理系统 为例，如果我们需要在注册服务中增加一种“学号注册”功能，则只 需要修改“注册服务”和“登录服务”即可，“信息管理服务”和 “安全设置”服务无须修改。3. 面向功能拆分 对某个功能扩展，或者要增加新的功能时，只需 要扩展相关功能即可，无须修改所有的服务。同样以学生管理系统为 例，如果我们增加“学号注册”功能，则只需要在系统中增加一个 新 的功能模块，同时修改“登录功能”模块即可，其他功能都不受影响。不同的拆分方式，将得到不同的系统架构，典型的可扩展系统架

4、构有：面向流程拆分：分层架构（分层架构的本质，就是固定的内核， 移动的数据）面向服务拆分：SOA、微服务面向功能拆分：微内核架构（插件式架构） 上述的架构是可以在系统架构设计中进行组合使用的。1、整体系统采用面向服务拆分中的“微服务”架构，拆分为“注 册服务”“登录服务”“信息管理服务”“安全服务”，每个服务是 一个独立运行的子系统。2、其中的“注册服务”子系统本身又是采用面向流程拆分的分层 架构。3、“登录服务”子系统采用的是面向功能拆分的“微内核”架构总结分析：因为本人主要负责的是规则引擎的部分，分析后可以 得出，肯定不是分层架构，即不是面向流程的，因为规则引擎主要作 用在业务层。其次，也

5、不应该是面向服务的，因为规则引擎都是跨越 多个服务的。 规则引擎和插件式架构，解决的都是功能扩展的问题。 微内核架构就是一种插件式架构。（扩展：规则引擎由推理引擎发展 而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程 序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数 据输入，解释业务规则，并根据业务规则做出业务决策）分层架构和 SOA：分层架构：是很常见的架构模式，它也叫N层架构。例如，C/S 架构、B/S架构。常见的是3层架构（例如，MVC、MVP架构）.C/S架构、B/S架构：划分的对象是整个业务系统，划分的维度 是用户交互，即将和用户交互的部分独立为一层，支撑用户

6、交互的后 台作为另外一层。是 C/S 架构结构图MVC架构、MVP架构分层架构设计最核心的一点就是需要保证各层之间的差异足够清晰，边界足够明显，让人看到架构图后就能看懂整个架构，分层时要 保证层与层之间的依赖是稳定的，才能真正支撑快速扩展。分层架构 之所以能够较好地支撑系统扩展，本质在于隔离关注点，即每个层中 的组件只会处理本层的逻辑。分层结构的另外一个特点就是层层传递，也就是说一旦分层确定， 整个业务流程是按照层进行依次传递的，不能在层之间进行跳跃。所 以导致分层架构典型的缺点就是性能，因为每一次业务请求都需要穿 越所有的架构分层，有一些事情是多余的，多少都会有一些性能的浪 费。面向服务的架

7、构 SOA：SOA出现的背景是企业内部的IT系统重复建设且效率低下，主要 体现在：1企业各部门有独立的IT系统，随着业务的发展，复杂度越来越 高，更多的流程和业务需要多个IT系统合作完成。2、各个独立的IT系统实现技术不同，企业自己也不太可能基于这 些系统进行重构。SOA的3个关键概念：服务：所有业务功能都是一项服务，服务就意味着要对外提供开 放的能力，当其他系统需要使用这项功能时，无须定制化开发。ESB :将企业中各个不同的服务连接在一起。SOA使用ESB来屏 蔽异构系统对外提供各种 不同的接口方式，以此来达到服务间高效的 互联互通。松耦合：目的是减少各个服务间的依赖和互相影响。因为采用SO

8、A 架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖。如果做不到松耦合， 某个服务一升级， 依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。总结：SOA解决了传统IT系统重复建设和扩展效率低的问题，但 其本身也引入了更多的复杂性。SOA最广为人诟病的就是ESB，ESB 需要实现与各种系统间的协议转换、数据转换、透明的动态路由等功 能、工作量和复杂度都很大，而且这种转换是需要耗费大量计算性能 的，当ESB承载的消息太多时，ESB本身会成为整个系统的性能瓶颈背景：SOA的ESB设计也是无奈之举，SOA的提出背景就可以发 现，企业在应用SOA时，各种异构的IT

9、系统都已经存在很多年了，完 全重写或者按照统一标准进行改造的成 本是非常大的，只能通过 ESB 方式去适配已经存在的各种异构系统。面向服务的架构微服务：微服务与SOA的关系： 相似点在于两者都关注“服务”，都是通过服务的拆分来解决可 扩展性问题。本质上不同的地方在于几个核心理念的差异：是否有 ESB、服务的粒度、架构设计的目标等。对匕维度SOA彈服务圖服务粒度粗细服务通信枣量甌ESB軽级.例如 HTTP RESTful服势交付n快rat mi1.服务粒度（依赖服务治理系统）对一个大型企业来说，“员工管理系统”就是一个SOA架构中的 服务；而微服务架构，则“员工管理系统”会被拆分为更多的服务，

10、比如“员工信息管理”“员工考勤管理”“员工假期管理”和“员工 福利管理”等更多服务。2、服务通信（依赖于RESTful API, RPC）SOA采用了 ESB作为服务间通信的关键组件，负责服务定义、服 务路由、消息转换、消息传递，总体上是重量级的实现。微服务推荐 使用统一的协议和格式，例如，RESTful协议、RPC协议，无须ESB 这样的重量级实现，传统SOA架构最广为人诟病的就是庞大、复杂、 低效的ESB。3、服务交付（依赖敏捷开发技术（自动化测试,持续集成,自动化部 署）SOA 只考虑兼容已有系统，几乎不考虑交付需求，微服务的架构 理念要求“快速交付”，相应地要求采取自动化测试、持续集成

11、、自 动化部署等敏捷开发相关的最佳实践（如果没有这些基础能力支撑， 微服务规模一旦变大（例如，超过20个微服务） ，整体就难以达到快 速交付的要求，这也是很多企业在实行微服务时踩过的一个明显的 坑， 就是系统拆分为微服务后，部署的成本呈指数上升。）4、应用场景SOA 更加适合于庞大、复杂、异构的企业级系统，典型特征就是 很多系统已经发展多年，采用不同的企业级技术微服务更加适合于快速、轻量级、基于Web的互联网系统，这类 系统业务变化快，需要快速尝试、快速交付，同时基本都是基于 Web， 虽然开发技术语言可能不同，但对外接口基本都是提供 HTTP RESTful 风格的接口，无须考虑在接口层进行

12、类似SOA的ESB那样的处理。small、lightweight、automated，基本上浓缩了微服务的精华， 也是微服务与SOA的本质区别所在微服务的缺点：1、服务划分过细，单个服务的复杂度确实下降了，但整个系统的 复杂度却上升了，因为微服务将系统内的复杂度转移为系统间的复杂 度。整体系统的复杂度是随着微服务数量的增加呈指数级增加的。2、.服务数量太多，团队效率急剧下降，一个需求涉及多个服务。 是设计、开发、测试、部署，都需要工程师不停地在不同的服务间切 换。3、调用链太长，性能下降， （微服务之间都是通过 HTTP 或者 RPC 调用的，每次调用必须经过网络。一般线上的业务接口之间的调

13、用，平均响应时间大约为50 毫秒，如果用户的一起请求需要经过6 次 微服务调 用，则性能消耗就是300毫秒，这在很多高性能业务场景下 是难以满足需求的。为了支撑业务请求，可能需要大幅增加硬件，这 就导致了硬件成本的大幅上升）4、调用链太长，问题定位困难，一次用户请求需要多个微服务 协同处理问题定位难，我们公司）在这方面上得益于强大的服务追踪 系统也就是trace日志，后期我会进行深入研究写一篇文章进行详述， 每个rpc请求都有相对应的日志，定位问题使其快速、便捷5、没有自动化支撑，无法快速交付（有自动化测试、自动化部署、 自动化监控）6. 没有服务治理，微服务数量多了后管理混乱主要问题有：服务

14、路由：假设某个微服务有60 个节点，部署在20 台机器上， 那么其他依赖的微服务如何知道这个部署情况呢？服务故障隔离：假设上述例子中的60个节点有 5个节点发生故障 了，依赖的微服务如何处理这种情况呢？服务注册和发现：同样是上述的例子，现在我们决定从60 个节点 扩容到80个节点，或者将60个节点缩减为40个节点，新增或者减少 的节点如何让依赖的服务知道呢？如果以上场景都依赖人工去管理，整个系统将陷入一片混乱，最 终的解决方案必须依赖自动化的服务管理系统，这时就会发现，微服 务所推崇的“lightweight”，最终也发展成和ESB几乎一样的复杂程 度。面向功能架构：微内核架构（插件化架构）

15、是一种面向功能进行拆分的可扩展性架构，通常用于实现基于产 品的应用1、基本架构微内核架构包含两类组件：核心系统和插件模块。核心系统负责 和具体业务功能无关的通用功能，例如模块加载、模块间通信等；插 件模块负责实现具体的业务逻辑PI紅 g-in ComponentPlug-in IComponent i微内核的架构本质就是将变化部分封装在插 件里面，从而达到快速灵活扩展的目的，而又不影响整体系统的稳定。 Plug in Component Plug-ki ComponentIPlug-inf 作 m rxruiqri*Core System微内核的核心系统设计的关键技术有：插件管理：核心系统需要

16、知道当前有哪些插件可用，如何加载这 些插件，什么时候加载插件。常见的实现方法是插件注册表机制插件连接：常见的连接机制有 OSGi（Eclipse 使用）、消息模式、依赖注入（Spring使用），甚至使用分布式的协议都是可以的，比如 RPC或者HTTP Web的方式。插件通信：虽然设计的时候插件间是完全解耦的，但实际业务运 行过程中，必然会出现某个业务流程需要多个插件协作，这就要求两 个插件间进行通信。由于插件之间没有直接联系，通信必须通过核心 系统，因此核心系统需要提供插件通信机制。规则引擎架构简析：规则引擎从结构上来看也属于微内核架构的 一种具体实现，其中执行引擎可以看作是微内核，执行引擎解析配置 好的业务流，执行其中的条件和规则，通过这种方式来支持业务的灵 活多变。规则引擎在计费、保险、促销等业务领域应用较多好处：1、可扩展，充分与业务系统解耦 2、容易理解 3、高效率， 方便RD快速配置新的业务