定义：

通常更侧重宏观的设计，且不考虑开发语言。从不同的维度来讲可以有多重分类、子分类。比如：事件驱动的架构、分层架构等等

分类：

  • 物理架构：主要研究项目最后的部署问题。
  • 逻辑架构：通常设计项目各大模块组成和模块间的关系。
  • 开发架构：确定开发语言、选择合适的技术架构。

演变：

单体架构

特点：

  • 是最简单的架构风格，所有的代码全都在一个项目中。这样研发团队的任何一个人都可以随时修改任意的一段代码，或者增加一些新的代码。
  • 开发人员也可以只在自己的电脑上就可以随时开发、调试、测试整个系统的功能。
  • 也不需要额外的一些依赖条件和准备步骤，我们就可以直接编译打包整个系统代码。

优点：

  • 层级关系简单：典型的三级架构，前端(Web/手机端)+中间业务逻辑层+数据库层

弊端：

  • 严重的耦合：所有的代码都在一起，就算是按照包来切分了不同的模块，各不同模块的代码还是可以直接相互引用，一旦修改影响巨大。
  • 发布难：系统作为一个单体部署，每次发布的新版本都是整个系统，打包、部署、停机、重启存在太多不可控的风险。（可控性差、启动慢）
  • 衍生问题：复杂性高、技术债深、阻碍技术创新、扩展能力受限

SOA

SOA 的关注点是服务。服务最基本的业务功能单元，由平台中立性的接口契约来定义。

个人理解：SOA与微服务的差异

皆是为了降低开发成本采取的措施，前者强调统一管理，后者强调独立。

微服务

组件化、松耦合、自治、去中心化

特点：

  • 主旨是将一个原本独立的系统拆分成多个小型服务。
  • 这些小型服务都在各自独立的进程中运行。
  • 被拆分成的每一个小型服务都围绕着系统中一些耦合度较高的业务功能进行构建。
  • 每个服务都维护着自身的数据存储，业务开发，自动化测试案例以及独立部署机制。
  • 由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。
  • 如果遇到一个功能变更，但其要求每个服务都要同时修改，那么它们就不能称之为微服务（达到这一点需要确认界限上下文）

优点：

  1. 易于开发和维护，因为每个微服务设计的初衷是每个服务专注一个模块开发，不同模块间依赖低，相互关联小
  2. 单个微服务启动较快
  3. 易部署：每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能
  4. 技术栈不受限

缺点：

  1. 运维要求较高
  2. 分布式固有的复杂性
  3. 接口调整成本高
  4. 重复劳动

微服务框架的关注点

  1. 服务注册、发现、负载均衡和健康检查
  2. 监控日志
  3. REST/RPC和序列化
  4. 配置
  5. 限流和容错
  6. 管理接口
  7. 统一错误处理
  8. 安全
  9. API文档自动生成

分层架构

优点：

  • 分层架构使得程序结构清晰，升级和维护都变得十分容易
  • 开发人员可以只关注整个结构中的某一层，对提高软件质量大有裨益。
  • 可以很容易的用新的实现来替换原有的实现。
  • 有利于标准化。
  • 利于各层逻辑的复用。

缺点：

  • 降低了系统的性能。这是显然的，因为增加了中间层，不过可以通过缓存机制来改善。
  • 可能会导致级联的修改。这种修改尤其体现在自上而下的方向，不过可以通过依赖倒置来改善。