零、文章目录
架构实践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）兼容等特点。