微服务架构相关

发表于 更新于 分类于

微服务架构的概念

微服务架构并没有统一的定义，想要理解微服务架构需要与传统的 Web 应用对比。

传统的 WEB 应用结构

传统的 WEB 应用核心划分为: 业务逻辑，适配器以及 API 或者 UI 访问的 WEB 界面。
业务逻辑定义业务流程，业务规则和领域实体。适配器包含数据库访问组件，消息组件以及访问接口等，。

虽然以上功能会分模块开发，但是最终都会打包并部署为单体应用，。例如 Java 应用会打包为 WAR 包部署在 Tomcat 或者 Jetty 上面。

这种单体应用适用于小项目，因为

  • 开发简单直接，便于管理
  • 基本不会重复开发
  • 功能都在本地，没有分布式的管理和调用开销。

缺点在于

  • 开发效率低
  • 代码维护难
  • 部署不灵活
  • 稳定性不高
  • 扩展性不够

因此现在主流的设计会采用微服务架构

微服务架构

微服务架构的思路不是开发一个巨大的单体应用，而是将应用分解为无数小的，互联的微服务。一个微服务完成某个特定的功能，比如下单管理，用户管理等。
每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供 API 接口给其他微服务和应用客户端使用。

可以将每个业务逻辑分解为多个微服务，微服务之间通过 RESET API 通信。通常情况下客户端不能直接访问后台微服务，而是通过 API Gateway 来传递请求。
API Gateway 一般负责路由，负载均衡，缓存，访问控制和鉴权等任务。

微服务架构的优点

  • 解决了复杂性问题
    将单体应用分解为多个微服务，强化了任务模块化的水平，因此微服务架构的开发速度快，更容易理解和维护。
  • 使得不同的服务可以有专注于此服务的团队开发
  • 每个微服务可以单独部署
  • 每个微服务可以独立扩展

微服务架构的挑战

可以大致概括为

  • API Gateway
  • 服务间调用
  • 服务发现
  • 服务容错
  • 服务部署
  • 数据调用