《凤凰架构》笔记

服务架构演进史

原始分布式时代

「调用 远程 方法」与「调用 本地 方法」两者的复杂度相差很多,需要考虑很多额外问题,例如:

  • 远程服务在哪里(服务发现)

  • 有多少个远程服务(负载均衡)

  • 网络出现分区、超时,或者服务出错了怎么办(熔断、隔离、降级)

  • 方法参数与返回结果如何表示(序列化协议)

  • 信息数据如何传输(传输协议)

  • 服务权限如何管理(认证、授权)

  • 如何保证通信安全(网络安全层)

  • 如何使不同机器的服务返回相同的调用结果(分布式数据一致性)

单体系统时代

对于小型系统,即由单台机器就足以支撑其良好运行的系统,单体系统架构不仅 易于开发易于测试易于部署,且由于系统中各个功能、模块、方法的调用过程都是进程内调用,不会发生进程间通信,因此也是运行效率最高的一种架构风格,完全不应该被贴上「反派角色」的标签。

单体系统的真正缺陷在于 隔离自治 能力上的欠缺,由于所有代码都共享着同一个进程空间,不能隔离,也就无法做到单独停止、更新、升级某一部分代码。

单体系统由于隔离能力的缺失,除了 难以阻断错误传播不便于动态更新程序 以外,还面临 难以技术异构 的困难,每个模块的代码都通常需要使用一样的程序语言,乃至一样的编程框架去开发。

微服务时代

微服务是一种 通过多个小型服务组合来构建单个应用 的架构风格,这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言,不同的数据存储技术,运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。

后微服务时代

从软件层面独力应对分布式架构所带来的各种问题,发展到应用代码与基础设施软、硬一体,合力应对架构问题的时代,此即为「后微服务时代」,现在常被媒体冠以「云原生 Cloud Native」这个颇为抽象的名字加以宣传。

最后更新于