【NOTE】几种可扩展的架构设计

软件系统和建筑系统最大的差异在于可扩展,一个硬件完工后不会再改变其整体结构,但软件不同。

# 如何拆分系统?

为了方便软件随着发展,改进其整体结构,就要考虑「可扩展性」。这需要学会拆分系统。

有 3 种拆分方法:

拆分对象 常见架构 常见场景 经典案例
面向流程 分层架构 系统架构 TCP/IP 7 层协议、Linux 设计
面向服务 SOA、微服务 业务系统 云开发后端
面向功能 微内核 第三方库、独立功能 tcb-js-sdk.js 扩展设计

# 面向流程:分层架构

分层架构核心是:保证隔层之间边界明显,层与层之间依赖稳定,支撑快速扩展。

显然,优点就是强制约束,代码规范;缺点就是性能,请求可能需要穿过多层。

# 面向服务:SOA、微服务

# SOA:面向服务的架构

SOA 有 3 个关键概念:

  • 服务:所有业务功能都是服务,可以对外提供
  • ESB(企业服务总线):类似于计算机总线,用于将各个系统“串”在一起
  • 松耦合

SOA 解决了传统 IT 功能“重复建设”的问题,但是 ESB 复杂度较高。它要实现各个服务之间协议转换、数据转换、动态路由等功能。

SOA 多用于某些服务运行多年,无法改造重写,包括数据协议等方面。此时借助 SOA 架构,为 ESB 接入老服务的数据协议,让其他服务可以调用。

# 微服务:面向服务的架构

微服务适用于快速、轻量的互联网系统。通常来说,数据传输协议均支持 http,接口规范遵循 RESTful 风格。所以不用向 SOA,需要 ESB 来处理异构系统。

微服务的难点在于:

  • 服务划分过细,依赖复杂
  • 调用链长,性能下降
  • 问题定位困难
  • 需要服务治理

微服务和 SOA 区别

微服务是把单个系统拆分,SOA 是把系统整合,方向刚好相反。

# 微服务的基础设施

  • 自动化:测试(单测、e2e)、部署(CI)
  • 配置中心:统一下发,方便管理
  • 数据协议:传输协议(http)、接口规范(restful)、编码格式(json)
  • API 网关:提供外部系统访问的接口,处理鉴权(能否接入)、权限控制(针对服务接口)、路由、频控、安全加密、负载均衡等问题
  • 服务发现:服务注册、请求转发、负载均衡等,分为自理式和代理式。常用自理式,对服务的请求,不经过“中心”
  • 服务监控
  • 服务跟踪:跟踪请求在服务中的完整链路

# 微内核:面向服务的架构

请参考:【架构设计】领悟微内核+插件化的代码设计之美

课程链接:极客时间:从 0 学架构