进入微服务世界，系统架构的发展阶段及主流微服务框架

前言

本文首先介绍系统架构演变的几个阶段；然后介绍微服务框架 Dubbo 和 Spring Cloud，以及服务网格 Istio ；最后介绍 Dubbo 、Spring Cloud、Istio 三者之间的区别。

系统架构的发展阶段

很多解决方案并非是最初设计出来的，而是由业务、技术、需求等因素驱动发展而成的。

单体应用阶段

企业将业务所的功能都集中在一起开发一个单体应用，然后将该单体应用部署到一台服务器上即可满足业务需求。

当用户规模越来越大时，单体应用可以通过集群来应对。比如通过，可以通过 DNS、nginx或硬(F5)分配集群中的服务器来提供服务。但是，它的缺点（开发效率低、可维护性差、稳定性差）导致需要对单体应用进行拆分。

优点：

• 易于集中式开发、测试、管理、部署。
• 无须考虑跨语言。

缺点：

• 开发效率低，团队合作困难。
• 可维护性差，代码的维护、重构、部署都比较难。
• 稳定性低，稳定性、可用性（停机维护）、扩展性不高。
• 需要绑定某种特定的开发语言。

垂直应用阶段

为了应对更高的并发、业务需求和解决单体应用的缺点，需

要根据业务功能对单体应用的架构方法进行演进

。例如，将单体应用的3个功能拆分为资讯系统、订单系统、会员系统这3个单体应用来提供服务。

好处：

• 拆分后的系统可以解决高并发、资源按需分配的问题。
• 可以针对不同的模块进行优化和资源分配，便于水平扩展、实现负载均衡、提高容错性，实现系统间的相互独立。

拆分方式：根据业务来拆分应用

• 如：原应用中包含订单、会员两部分，可将其拆分成订单服务和会员服务。
• 优点：拆分后保证业务之间的相互影响较小，能合理地分配硬件资源（不同的业务对流量和性能的要求是不一样的）。
• 缺点：可能会导致整个系统存在“重复造轮子”的问题，而且难以维护。

水平扩展与垂直扩展：

• 当一个服务的性能到达瓶颈时，往往有两种方式对其进行扩展，
• 一种是水平扩展或者说横向扩展，即通过增加服务器，以集群的方式提供服务来增加系统性能。
• 另一种方式为垂直扩展，即通过提高单个服务的资源配置，如增加CPU核心、内存容量等，来提高服务的性能。

分布式系统阶段

在分布式系统中，各个小系统之间的交互是不可避免的，此时可

将核心业务作为独立的服务抽取出来，逐渐形成稳定的基础服务

，这样可以使前端的业务系统能更快速地响应复杂多变的市场需求。

优点：对基础服务进行了抽取，服务之间可以相互调用，从而提高了代码复用和开发效率。

缺点：业务间耦合度变高；调用关系错综复杂；系统难以维护；在搭建集群后，很难实现负载均衡。

针对分布式系统存在的问题，可以通过治理基础服务来解决。

服务治理阶段

在服务治理（SOA）架构中，需要一个

企业总线（ESB）将基于不同协议的服务节点连接起来，它的工作是转换、解释消息和路由

。

SOA 解决了以下问题：

• 服务间的通信问题：引入了 ESB、技术规范、服务管理规范，从而解决了不同服务间的通信问题。
• 基础服务的梳理问题：以 ESB 为中心梳理和规整分布式服务。
• 业务的服务化问题：以业务为驱动，将业务单元封装到服务中。
• 服务的可用复用问题：将业务的功能设计为通用的业务服务，以实现业务逻辑的复用。

随着业务复杂性、需求多变性和用户规模的不断增长，敏捷开发和 DevOps(一种过程、方法的统称，用于促进开发、运维和质量保证部门之间的沟通、合作和整合)变得特别重要。

敏捷开发和 DevOps 在尽可能满足需求的同时，保证了良好的软件质量、系统的可用性。

敏捷交付和 DevOps 的要求催生了微服务架构的出现。

微服务采用的是服务（治理）中心，而不是在 SOA 架构中“中心化”的 ESB。

因此，服务的调用不再需要知道“服务提供者”的IP地址、端口号，而只需要知道在服务中心中注册了的服务名即可。

ESB：

• 就是企业数据总线的意思，他的核心功能就是兼容各种协议接口，可以将数据在各种协议之间进行流转，并且可以针对数据格式进行编排转换。
• 例：假设A系统要调用B系统的某个服务，A系统的服务都是走基于HTTPS的SOAP方式的、而B系统都是HTTP的REST服务，这两个系统之间如果要直接交互基本上是鸡同鸭讲。但只要B系统在ESB上注册过、并配好各种转换规则啥的，那么对A系统来说，只要把调用的数据给ESB，剩下的全部就是ESB来帮你搞定了，A系统根本不关心B系统的服务的具体实现方式是啥、开发语言是啥，只要知道B系统确实有这个服务就行了。

服务注册：

• 就是将所有的服务接口，注册到一个中心的分布式服务集群上。各个业务系统直接访问分布式服务查找需要调用的接口位置，进而调用。

微服务阶段

微服务(microservice)架构是指

：

• 将系统的业务功能划分为极小的独立微服务，每个微服务只关注于完成某个小的任务。
• 系统中的单个微服务可以被独立部署和扩展，且各个微服务之间是高内聚、松耦合的。
• 微服务之间采用轻量化通信机制暴露接口来实现通信。

一个简单的微服务架构

服务网格阶段

服务网格(Service Mesh)独立于服务之外运行，

是服务间通信的基础设施层

。

服务网格类似于在每个服务上粘贴的功能模块。

服务网格的架构图

服务之间通过 sidecar 进行通信，所有 sidecar 和网络连接就形成了 Service Mesh 。sidecar 主要负责服务发现和容错处理

。

服务网格主要由数据平面(Data Plane) 和 控制平面(Control Plane) 组成。

• 数据平面：处理服务间的通信，并实现服务发现、负载均衡、流量管理、健康检查等功能。
• 控制平面：管理并配置 sidecar，以及执行策略和收集数据。

通常，应用程序的开发人员不需要关心 TCP/IP 层。同样，在使用服务网格时，开发人员也不需要关心服务的熔断、限流、监控等，这些都由服务网格来处理。

服务网格架构和微服务架构的区别：

• 侧重点不同。
  • 微服务架构主要关注服务间的生态，例如服务治理等；
  • 而服务网络架构则更加关注服务之间的通信，以及与 DevOps 的结合。
• 侵入性不同。
  • 微服务架构实现了服务间的解耦，服务网格则实现了服务框架与服务之间的解耦。在微服务架构中，服务提供者和服务消费者需要配置“服务中心”的IP地址和端口号等配置信息。
  • 服务网格是在服务之外独立运行的模块，它提供了微服务框架功能，服务不需要在代码和配置中添加相应的依赖和依赖配置项。

服务网格特点：

• 对服务没有侵入性。
• 是应用程序间通信的一个中间层。
• 是一个轻量级的网络代理。
• 应用程序对服务网格无感知。
• 能够解耦应用程序的重试、监控、追踪和服务发现。

目前流行的 Service Mesh 开源项目有：Linkerd、Envoy、Istio、Kong等，其中 Istio 较为流行和著名。

主流的微服务框架

Dubbo

Dubbo 致力于提供高性能和透明化的远程服务调用方案和SOA服务治理方案。

Dubbo 核心功能：

• 面向接口的高性能 RPC调用。
  • 提供了高性能的、基于代理的远程调用功能，服务以接口为粒度，为开发人员屏蔽了远程调用的底层细节。
• 智能负载均衡
  • 内置了多种负载均衡策略，能智能感知节点的健康状况，有效减少调用延迟，提高系统吞吐量。
• 服务的自动注册与发现
  • 支持多种注册服务方式，能对服务实例的上下线进行实时感知。
• 高度的可扩展
  • 遵循“微内核+插件”设计原则，所有的核心功能都被设计为扩展点。
• 运行期流量调度
  • 内置了条件、脚本等路由策略。通过不同的路由规则，可以方便地实现灰度发布、同机房优先等运行期的流量调度。
• 可视化的服务治理与运维
  • 提供了丰富的服务治理、运维工具，可以随时查询服务的元数据、服务的健康状态和调用统计信息，实时下发路由策略，调整配置参数。

Spring Cloud

Spring Cloud 是基于 Spring Boot 的一个快速开发微服务的框架。它提供了以下开发微服务所需的一些常见组件。

• 服务发现(Service Discover)
• 断路器(Circuit Breakers)
• 智能路由(Intelligent Routing)
• 微代理(Micro-proxy)
• 控制总线(Control Bus)
• 一次性令牌(One-time Tokens)
• 全局锁(Global Locks)
• 领导选举(Leadership Election)
• 配置管理(Configuration Management)
• 分布式会话(Distributed Sessions)
• 集群状态(Cluster State)

Spring Cloud 通过 Spring Boot 对这些组件进行封装，屏蔽了复杂的配置和实现原理，最终给开发人员提供了一套简单易懂、易部署和易维护的分布式系统开发工具包。

Spring Cloud 使得构建大型系统变得非常容易和低成本。

Spring Cloud 核心功能：

• 分布式、版本化配置
  • 通过 Spring Cloud Config 来统一管理服务配置。可以将所有服务的配置文件放置在本地仓库或远程仓库中，让配置中心来负责读取仓库的配置文件，而客户端（服务）从配置中心读取配置。
  • Spring Cloud Config 经常和 Spring Cloud Bus 结合使用，无须重启服务即可动态刷新配置文件。
• 服务注册和发现
  • 服务治理组件（Eureka、Consul等），通过它可以发现“服务提供者”，还可以将自已注册到“服务中心”中。
• 路由
  • 通过智能路由网关组件（Zuul、Spring Cloud Gateway）来实现智能路由和请求过滤功能。
  • 内部服务接口通过网关统一对外暴露，避免了内部服务敏感信息在未经授权的情况下对外暴露。
• 负载均衡
  • 可以通过 Feign （远程调用组件）和 Ribbon（负载均衡组件）实现负载均衡。
• 断路器
  • 使用服务容错组件（Hystrix）控制服务的API接口的熔断，以实现故障转移、服务限流、服务降级等功能，防止服务系统发生雪崩效应。
  • Hystrix Dashboard 组件监控单个服务的熔断状态，用 Hystrix Turbine 组件监控多个服务的熔断器的状态。
• 分布式消息传递
  • 通过消息总线组件，数据流操作组件可以将 Redis、RabbitMQ、Kafka 等封装起来，实现消息的接收和发送。

服务网格（Service Mesh）框架Istio

Istio 将流量管理添加到微服务中，提供了连接、安全、管理和监控微服务的方案。

要让微服务系统支持 Istio ，只需要在系统中部署一个特殊的 sidecar 代理，这样就可以使用 Istio 控制平面的功能来配置和管理代理，并拦截微服务之间的所有网络通信。

Istio 核心功能：

• 流量管理
  • 通过其提供的规则配置和流量路由功能，可以很好地控制服务之间流量和API调用。
  • Istio 简化了断路器、超时和重试的配置，并可以轻松设置A/B测试、金丝雀部署、基于百分比的流量分割部署、分阶段部署等重要任务。
• 安全
  • Istio 提供了认证、授权和加密功能，以实现底层安全通信信道和管理服务通信。
• 监控功能
  • 通过 Istio 的监控功能，可以了解服务的性能，及服务如何影响上游和下游的功能。
• 平台无关
  • 独立于平台，可以在各种环境中运行，包括跨云、K8s、Mesos等。

比较 Dubbo、Spring Cloud 和 Istio

国内的中小企业大多使用 Dubbo 或 Spring Cloud 框架。 Istio 是最新的框架，很多人认为它是未来会普及的框架。

Dubbo 架构图

Dubbo 专注于RPC领域，未来将成为微服务生态体系中一个重要组件，而不是成为一个微服务的全面解决方案。

Spring Cloud 架构图

Spring Cloud 架构的生态相当完善。

Istio 架构图

Istio 是 Service Mesh 架构的一种实现。

在 Istio 中，服务之间的通信是通过代理（默认是Envoy）使用 HTTP/1.1、HTTP/2、gRPC、TCP协议来进行。

Pilot 、 Mixer 、 Citadel 组成控制平面。

Istio 架构中的主要概念：

• Pilot
  • 它为 Envoy 提供服务发现、流量管理和智能路由，以及错误处理（超时、重试、熔断）功能。
  • 用户通过 Pilot 的API管理网络相关的资源对象。Pilot 会根据用户的配置和服务的令牌将网络流量管理信息分发到各个Envoy中。
• Mixer
  • 它为整个集群执行访问控制、跨服务网格使用策略(Policy)、管理(Rate Limit、Quota等)，并收集从 Envoy 代理和其他服务自动探测到的数据。
  • Mixer 包含一个非常灵活的插件模型，可以与各种主机环境和后端基础架构进行交互，所以它是独立于平台的组件的。
• Citadel
  • 它提供服务之间的认证和证书管理，使服务能够自动升级到TLS协议。
• Sidecar
  • 它在原有的客户端和服务器端之间添加了一个代理程序。
• Envoy
  • 它提供了服务发现、负载均衡和路由表动态更新的API。这些API解耦了 Istio 和 Envoy 。
  • 代理Proxy(默认使用 Envoy) 作为 Sidecar 会和控制中心通信，以获取需要的服务之间的信息，以及汇报服务调用的Metrics（指标）数据。

对比各项数据

Spring Cloud 在现阶段或未来较长时间内是最为稳妥的微服务的框架。

如果技术上采取激进策略的团队则可以考虑采用 Istio 。

总结

单体应用阶段

：将业务所的功能都集中在一起开发一个单体应用。

垂直应用阶段

：为了应对更高的并发、业务需求和解决单体应用的缺点，需要根据业务功能对单体应用的架构方法进行演进。拆分方式：根据业务来拆分应用。

分布式系统阶段

：将核心业务作为独立的服务抽取出来，逐渐形成稳定的基础服务，这样可以使前端的业务系统能更快速地响应复杂多变的市场需求。

服务治理阶段

：SOA 解决了以下问题：服务间的通信问题、基础服务的梳理问题、业务的服务化问题、服务的可用复用问题。在服务治理（SOA）架构中，需要一个企业总线（ESB）将基于不同协议的服务节点连接起来，它的工作是转换、解释消息和路由。

微服务阶段

：将系统的业务功能划分为极小的独立微服务，每个微服务只关注于完成某个小的任务。 系统中的单个微服务可以被独立部署和扩展，且各个微服务之间是高内聚、松耦合的。微服务之间采用轻量化通信机制暴露接口来实现通信。

服务网格阶段

：服务之间通过 sidecar 进行通信，所有 sidecar 和网络连接就形成了 Service Mesh 。服务网格主要由数据平面(Data Plane) 和 控制平面(Control Plane) 组成。数据平面：处理服务间的通信，并实现服务发现、负载均衡、流量管理、健康检查等功能。控制平面：管理并配置 sidecar，以及执行策略和收集数据。在使用服务网格时，开发人员不需要关心服务的熔断、限流、监控等，这些都由服务网格来处理。

Dubbo

致力于提供高性能和透明化的远程服务调用方案和SOA服务治理方案。

Dubbo 核心功能：

面向接口的高性能 RPC调用、智能负载均衡、服务的自动注册与发现、高度的可扩展、运行期流量调度、可视化的服务治理与运维。

Spring Cloud

是基于 Spring Boot 的一个快速开发微服务的框架。它提供了开发微服务所需的一些常见组件。

Spring Cloud 核心功能：

分布式及版本化配置、服务注册和发现、路由、负载均衡、断路器、分布式消息传递。

Istio

Istio 是 Service Mesh 架构的一种实现。将流量管理添加到微服务中，提供了连接、安全、管理和监控微服务的方案。

Istio 核心功能：

流量管理、安全、监控功能、平台无关。

公众号

参考

《Spring Cloud 微服务架构实战派》 龙中华