架构实践04-高扩展架构模式

零、文章目录

架构实践04-高扩展架构模式

1、可扩展架构的基本思想和模式

（1）软件系统的可扩展性

• 软件系统的特性：软件系统与硬件和建筑系统不同，具有可扩展性。软件系统可以通过不断的更新和调整来增加新功能和特性，以适应新的需求和技术发展趋势。
• 扩展的挑战：扩展软件系统时，如何以最小的代价进行扩展是一个重要问题。扩展时可能需要修改多个部分，导致改动范围大、风险高。

（2）可扩展性的基本思想

• 核心思想：可扩展性架构设计的核心思想是"拆"。通过将大一统的系统拆分成多个小部分，可以减少扩展时的改动范围，降低风险。
• 拆分的目的：拆分的目的是为了在扩展时只需修改部分系统，而不是整个系统，从而减少改动的复杂性和风险。

（3）常见的拆分思路

• 面向流程拆分：
  • 定义：将整个业务流程拆分为几个阶段，每个阶段作为一个部分。
  • 优势：扩展时只需修改某一层或几层，不会影响整个系统。
  • 示例：学生信息管理系统中的展示层、业务层、数据层、存储层。

• 面向服务拆分：
  • 定义：将系统提供的服务拆分，每个服务作为一个部分。
  • 优势：对某个服务扩展或增加新服务时，只需修改相关服务，不影响其他服务。
  • 示例：学生信息管理系统中的注册服务、登录服务、信息管理服务、安全设置服务。

• 面向功能拆分：
  • 定义：将系统提供的功能拆分，每个功能作为一个部分。
  • 优势：对某个功能扩展或增加新功能时，只需修改相关功能，不影响其他功能。
  • 示例：学生信息管理系统中的数据层、存储层、注册服务中的多种注册方式。

（4）可扩展系统架构

• 分层架构：面向流程拆分，固定内核，移动数据。
• SOA架构：面向服务拆分，将系统拆分为多个独立的服务。
• 微服务架构：面向服务拆分的进一步发展，每个服务是一个独立运行的子系统。
• 微内核架构：面向功能拆分，核心系统提供基本功能，其他功能通过插件形式扩展。

2、传统可扩展架构模式：分层架构和SOA

（1）分层架构

• 定义：分层架构是一种常见的架构模式，也称为 N 层架构，通常至少包含 2 层。
• 常见类型：
  • C/S 架构：客户端/服务器架构，分为用户交互层和后台支撑层。
  • B/S 架构：浏览器/服务器架构，同样分为用户交互层和后台支撑层。

- MVC 架构：模型/视图/控制器架构，适用于单个业务子系统，按职责划分层。
- MVP 构架：模型/视图/呈现器架构，类似于 MVC。

- 逻辑分层架构：可以应用于单个业务子系统或整个业务系统，按职责划分层，层与层之间是自顶向下的依赖关系。

• 核心原则：
  • 清晰的层边界：确保各层之间的差异和边界清晰，避免混淆。
  • 隔离关注点：每个层只处理本层的逻辑，支持系统在某层上快速扩展。
  • 稳定的依赖关系：层与层之间的依赖关系必须稳定，以支持快速扩展。
• 优点：
  • 降低复杂度：通过分层将系统分解为更小、更易管理的部分。
  • 支持快速扩展：可以在某一层上进行扩展而不影响其他层。
• 缺点：
  • 冗余：每层都必须参与处理，即使业务简单。
  • 性能损失：每次业务请求需要穿越所有层，可能导致性能下降。

（2）SOA（面向服务的架构）

• 定义：SOA 是一种架构模式，旨在通过服务的形式将企业内部的 IT 系统整合在一起。
• 背景：企业内部 IT 系统重复建设且效率低下，需要解决异构系统之间的集成问题。
• 关键概念：
  • 服务：将业务功能封装为服务，提供开放的能力。
  • ESB（企业服务总线）：将各个异构系统连接在一起，实现服务间的高效互联互通。
  • 松耦合：减少服务间的依赖和互相影响，提高系统的灵活性和可维护性。

• 优点：
  • 资源复用：避免重复开发，提高效率。
  • 灵活集成：支持异构系统的高效集成。
• 缺点：
  • 复杂性：引入了更多的复杂性，特别是 ESB 的实现和维护。
  • 性能瓶颈：ESB 可能成为系统的性能瓶颈。
• 适用场景：
  • 传统企业：如制造业、金融业等，存在大量异构系统。
  • 互联网企业：较少采用，因为互联网企业通常较年轻，没有历史包袱，且对性能要求较高。

（3）互联网企业很少采用 SOA 架构的原因

• 没有历史包袱：互联网企业较年轻，没有大量异构系统的遗留问题。
• 高性能要求：互联网企业对性能要求较高，ESB 可能成为性能瓶颈。
• 快速迭代：互联网企业需要快速迭代，SOA 的复杂性和重负载不利于快速开发和部署。
• 微服务架构：微服务架构作为一种更轻量、更灵活的替代方案，更适合互联网企业的特点。

3、深入理解微服务架构

（1）微服务与SOA的关系

• 历史背景：
  • 2005年：Dr. Peter Rodgers 提出"Micro-Web-Services"概念。
  • 2011年：软件架构工作组使用"microservice"描述一种架构模式。
  • 2012年：James Lewis 在 QCon San Francisco 2012 发表关于微服务的演讲。
  • 2014年：James Lewis 和 Martin Fowler 合写关于微服务的文章。
• 关系与区别：
  • SOA：面向服务的架构，通常包含 ESB（企业服务总线），服务粒度较粗，适合复杂、异构的企业级系统。
  • 微服务：更细粒度的服务，去掉了 ESB，使用轻量级协议（如 HTTP RESTful），强调快速交付和自动化，适合快速变化的互联网系统。

（2）微服务的特点

• 服务粒度：微服务的服务粒度更细，例如"员工管理系统"可以拆分为"员工信息管理"、"员工考勤管理"等。
• 服务通信：微服务推荐使用轻量级协议（如 RESTful、RPC），强调"聪明的终端，愚蠢的管道"。
• 服务交付：微服务要求快速交付，需要自动化测试、持续集成、自动化部署等支持。
• 应用场景：微服务适合快速变化的互联网系统，而 SOA 适合复杂、异构的企业级系统。

（3）微服务的陷阱

• 服务划分过细：服务间关系复杂，系统整体复杂度上升。

• 服务数量太多：团队效率急剧下降，开发、测试、部署成本增加。
• 调用链太长：性能下降，问题定位困难。

• 缺乏自动化支撑：无法快速交付，甚至不如大而全的系统效率高。
• 缺乏服务治理：微服务数量增多后管理混乱，需要自动化服务管理系统。

（4）实践经验

• 服务粒度：不要盲目追求"微"，根据业务需求和服务复杂度合理划分。
• 基础设施：自动化测试、部署、监控等基础设施是成功实施微服务的关键。
• 组织结构：服务拆分应与组织结构匹配，遵循康威定律。
• 逐步实施：不要一次性大规模拆分，逐步进行，逐步优化。

4、微服务架构最佳实践-方法

（1）服务粒度

• 三个火枪手原则：每个微服务由3个人负责开发。这样既能保证系统的复杂度适中，又能形成稳定的备份，促进技术讨论和提升。
• 团队规模：根据团队规模来划分微服务数量。例如，6个人可以划分为2个微服务，12个人可以划分为4个微服务。
• 灵活性：服务拆分不是一成不变的，随着业务发展和团队规模扩大，可以适时调整微服务的数量和粒度。

（2）拆分方法

• 基于业务逻辑拆分：将业务模块按职责范围拆分为独立的服务。注意避免因职责范围理解不同而导致的拆分争议。
• 基于可扩展拆分：将成熟和改动不大的服务拆分为稳定服务，将经常变化和迭代的服务拆分为变动服务。
• 基于可靠性拆分：将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，重点保证核心服务的高可用。
• 基于性能拆分：将性能要求高或性能压力大的模块拆分出来，避免影响其他服务。

（3）基础设施

• 服务发现、服务路由、服务容错：这是最基本的微服务基础设施。
• 接口框架、API网关：提升开发和对接外部服务的效率。
• 自动化部署、自动化测试、配置中心：提升测试和运维效率。
• 服务监控、服务跟踪、服务安全：随着微服务节点数量增加，这些基础设施的重要性逐渐提升。

（4）实践建议

• 逐步实施：不要一开始就追求完美的微服务架构，可以根据业务发展和团队规模逐步调整和优化。
• 基础设施优先：确保"automated"相关的基础设施健全，避免微服务成为焦油坑。
• 团队协作：鼓励团队成员之间的技术讨论和协作，形成良好的开发氛围。

5、微服务架构最佳实践-基础设施

（1）自动化测试

• 重要性：微服务架构中，接口数量增加，版本更新频繁，人工测试效率低下，必须通过自动化测试提高效率。
• 涵盖范围：代码级单元测试、系统级集成测试、系统间接口测试。
• 最低要求：至少实现接口测试自动化。

（2）自动化部署

• 背景：微服务部署节点多，频率高，人工处理效率低且易出错。
• 功能：版本管理、资源管理、部署操作、回退操作。

（3）配置中心

• 背景：微服务节点多，人工修改配置效率低且易出错。
• 功能：配置版本管理、增删改查配置、节点管理、配置同步、配置推送。

（4）接口框架

• 背景：统一接口协议和数据格式，避免微服务间适配复杂。
• 功能：提供多种语言的解析包，确保接口协议和数据格式一致。

（5）API 网关

• 背景：外部系统调用微服务复杂，需要统一入口。
• 功能：接入鉴权、权限控制、传输加密、请求路由、流量控制。

（6）服务发现

• 背景：微服务节点多且动态变化，手工配置不可行。
• 实现方式：自理式和代理式。
• 核心功能：服务注册表，记录服务节点的配置和状态。

（7）服务路由

• 背景：从可用微服务节点中选择具体节点发起请求。
• 实现方式：与服务发现紧密结合，常见路由算法有随机路由、轮询路由、最小压力路由等。

（8）服务容错

• 背景：微服务节点多，故障概率增加，需要自动应对故障。
• 功能：请求重试、流控、服务隔离。

（9）服务监控

• 背景：微服务节点多，监控对象多，人工处理不现实。
• 功能：实时监控、故障定位、预警。

（10）服务跟踪

• 背景：服务监控难以实现请求链路的完整跟踪。
• 功能：记录请求的完整路径和详细信息。
• 技术：基于 Google 的 Dapper 论文。

（11）服务安全

• 背景：微服务数据分散，需要保护业务和数据安全。
• 功能：接入安全、数据安全、传输安全。
• 实现方式：集成到配置中心，提供通用的安全策略库。

6、微内核架构

（1）基本架构

• 核心系统（Core System）：负责通用功能，如模块加载、模块间通信等。
• 插件模块（Plug-in Modules）：实现具体的业务逻辑，如"手机号注册"功能。

（2）设计关键点

• 插件管理
  • 插件注册表：记录每个插件的信息，包括名称、位置、加载时机等。
  • 实现方法：配置文件、代码、数据库等。
• 插件连接
  • 连接规范：核心系统制定插件和核心系统的连接规范。
  • 常见机制：OSGi、消息模式、依赖注入（如Spring）、分布式协议（如RPC、HTTP）。
• 插件通信
  • 通信机制：通过核心系统提供的通信机制实现插件间的通信。
  • 类比：计算机通过主板上的总线实现各组件间的通信。

（3）OSGi 架构简析

• 模块层（Module Layer）：实现插件管理功能，插件称为Bundle，每个Bundle是一个Java的JAR文件，包含MANIFEST.MF元数据文件。
• 生命周期层（Lifecycle Layer）：实现插件连接功能，定义了Bundle的生命周期操作（安装、更新、启动、停止、卸载）。
• 服务层（Service Layer）：实现插件通信功能，提供服务注册功能，插件通过服务注册中心进行通信。

（4）规则引擎架构简析

• 插件管理：业务功能分解为多个规则，保存在规则库中，业务人员通过配置规则实现业务流程。
• 插件连接：规则引擎规定了规则开发的语言，业务人员基于规则语言编写规则文件。
• 插件通信：规则之间通过数据流和事件流进行通信，由引擎负责传递数据和事件。

（5）规则引擎的优点

• 可扩展：业务逻辑实现与业务系统分离，支持不改动业务系统的情况下扩展新功能。
• 易理解：规则通过自然语言描述，业务人员易于理解和操作。
• 高效率：提供可视化的规则定制、审批、查询及管理，方便业务人员快速配置新的业务。

（6）常见的规则引擎

• JBoss Drools：开源的规则引擎，基于Rete算法，具有活跃的社区支持、快速的执行速度、与Java Rule Engine API（JSR-94）兼容等特点。