微服务架构技术选型思考

Posted 2021-04-02 牧师架构之路

---

       在互联网+ 和新商业业态的冲击下，传统行业正处于技术架构转型的十字路口，随着业务的不断创新变化，服务架构也随之无时无刻地进行革新。从早期的单体应用架构、面向SOA架构以及现在的微服务架构，无不是随着业务场景的不同诉求而进行适应性架构变迁。基于当前行业的业务发展，天然基于云服务的云原生模式无疑能给出重要参考意义。然而如何落地云原生技术正逐步成为行业用户的焦点。作为云原生生态领域中的关键一员，微服务的一举一动牵动着整个生态的发展方向。

       那么，什么是微服务架构呢？

       微服务架构是指将大型复杂软件应用拆分成多个简单应用，每个简单应用描述着一个小业务，系统中的各个简单应用可被独立部署。各个微服务之间是松耦合的，可以独立地对每个服务进行升级、部署、扩展和重新启动等流程，从而实现频繁更新而不会对最终用户产生任何影响。相比传统的单体架构，微服务架构具有降低系统复杂度、独立部署、独立扩展、跨语言编程等特点。

       与此同时，由于架构的灵活性、开发的敏捷性使得给运维带来了新的挑战。微服务框架作为微服务开发和运行治理的必要支撑，帮助实现微服务注册、发现、治理等能力。针对微服务架构，以 Spring Cloud 生态体系为例，我们来看下其具体架构拓扑示意图：

       其实，无论是基于那种技术架构，其本质都具备相应的优缺点,，毕竟，存在即是合理的。基于不同的业务场景，通常我们需选用不同的应用架构、技术框架，然而，对于技术要素的选型，前沿性并不是唯一的考量因素，也就是说不一定使用最新的架构、技术解决我们的业务痛点，需要结合公司的实际情况进行综合决策。

       基于上述的参考架构拓扑，我们可以基于分层的思维模型对微服务的架构进行技术选型，具体可从以下几方面进行：

        API 网关

       随着微服务架构概念的提出，API 网关成为了微服务架构的一个标配组件，无时无刻在我们的应用系统架构中起着举足轻重的作用。通常，网关在我们的架构中主要包含以下功能，具体如下图所示：

       目前市面上或者业务场景落地解决方案中，常见的开源网关大致上按照语言分类有如下几类，具体如下图所示：

      若我们依据使用范围、成熟度以及落地场景等维度来划分，目前主流网关技术应用涉及以下4 种：OpenResty、Kong、Zuul/Zuul 2、Spring Cloud Gateway，此外，随着Go语言在微服务领域的快速崛起以及应用，Fagongzi API 网关最近也获得不少关注。因此，若我们的开发平台基于Java 语言的，可选择性较多，同时，我们在业务实现过程中采用 Spring Cloud 生态体系，那么我们应该优先选择 Spring Cloud 生态中最成熟的网关组件（毕竟，从升级层面、性能、稳定性以及兼容性等角度综合评估），具体，例如：Spring Cloud Gateway。若我们的开发平台基于 Go 语言，同理，优先评估生态中所自带的，然后对通用型产品进行评估。

       除了上述的选型因素外，若我们当前的业务基于云原生进行维护，则我们尽可能选择其生态中的组件，比如 Traefik 组件。 

       1、Spring Cloud Gateway

       Spring Cloud Gateway 是 Spring Cloud 生态全新项目，其主要基于 Spring 5.0、Spring Boot 2.0 和 Project Reactor 等技术开发的网关组件，旨在为微服务架构提供简单、有效和统一的 API 路由管理方式，同时提供安全性、监控/度量和限流，Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关，目标是替代 Netflix Zuul组件，其具体架构如下所示：

       2、Traefik

       Traefik 是一个开源的可以使得服务发布变得轻松有趣的边缘路由器。它负责接收我们系统的请求，然后使用合适的组件来对这些请求进行处理。

       除此之外，Traefik 兼容所有主流的集群技术，比如 Kubernetes、Docker、Docker Swarm、AWS、Mesos 以及 Marathon 等等，并且可以同时处理多种方式。

       基于 Traefik，我们不需要维护或者同步一个独立的配置文件：因为一切都会自动配置，实时操作的（无需重新启动，不会中断连接）。使用 Traefik，我们可以花更多的时间在系统的开发和新功能上面，而不是在配置和维护工作状态上面花费大量时间。其架构图如下所示：

        服务治理

       站在技术实现角度，服务治理通常被定义为改变运行时服务的行为和选址逻辑，达到限流，权重配置等目的，主要涉及动态配置、路由标签、负载均衡等等。

       1、Spring Cloud Hystrix/Ribbon

      Spring Cloud 是目前最主流的微服务架构落地首选方案之一，是基于 Spring Boot 实现的开源框架，是一个全家桶，是微服务的整体技术栈。它为服务注册发现、动态路由、负载均衡、配置管理、消息总线、熔断器、分布式链路追踪、大数据操作等提供了简单的实现，让我们可以更简洁地去调用。其生态体系架构组件拓扑如下所示：

      基于上述组件图，开箱即用的特性使得 Spring Cloud 体系比较容易上手，需要哪个功能，直接通过 Maven 引入相应子系统组件即可，可满足不同层次的使用者，也可支持各类不同应用场景特点。微服务改造是一个渐变的过程，不必一开始就使用所有功能。

       2、Dubbo

       Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，即就是个远程服务调用的分布式框架。其生态体系架构组件拓扑如下所示：

      基于上述架构图，在现有的微服务生态体系中，Dubbo 只能说是一个服务治理框架，或者说是一个 RPC 框架，是以接口为粒度，一个接口类就就是一个服务。如果直接用 Dubbo 来实现微服务架构，还缺少以下几个功能：分布式配置、链路追踪以及批量任务等组件。

       3、Sentinel-golang

      随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护等多个维度来帮助您保障微服务的稳定性。其简要架构如下所示：

      结合上述流量控制架构图，Sentinel 的主要工作机制如下：

      1、对主流框架提供适配或者显示的 API，来定义需要保护的资源，并提供设施对资源进行实时统计和调用链路分析。

      2、根据预设的规则，结合对资源的实时统计信息，对流量进行控制。同时，Sentinel 提供开放的接口，方便您定义及改变规则

       服务注册与发现

      针对此部分内容，先来了解下其概念，具体：

      服务注册，即将提供某个服务的模块信息(通常是这个服务的 Ip和 端口)注册到1个公共的组件上去（比如: Zookeeper、Consul）。

      服务发现，即新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。

      其实，针对不同语言体系，微服务框架而已，它们都是通用的，只不过是基于当前公司的业务特性、部署模型以及技术栈进行综合评估。

       1、Etcd 

       Etcd 是一个分布式，一致的 Key-Value 存储，主要用于共享配置和服务发现，Etcd 由 CoreOS 开发并维护，通过 Raft 一致性算法处理日志复制以保证强一致性。虽作为后起之秀，但其已经融入云原生生态领域，并且基于 Go 语言开发，高性能，基于 HTTP作为接口使用简单、方便，使用 Raft 算法保证强一致性让用户易于理解。除此，基于 Etcd 所默认的持久化机制与安全机制使得其在云原生生态领域能够得到进一步的发展。其架构图如下所示：

       2、Consul

       Consul 是由 HashiCorp 基于Go语言开发的支持多数据中心分布式高可用的服务发布和注册服务软件，基于Raft 算法保证服务的一致性，且支持健康检查。Consul 架构采用主从模式，使得集群的数量可以大规模扩展，集群间通过 RPC 的方式调用( HTTP 和DNS )。其简要结构图如下所示：

       3、Zookeeper

       Zookeeper 是由 Google 开源的在 Java 语言上实现的分布式协调服务，是Hadoop和Hbase的重要组件，提供了数据/发布订阅、负载均衡、分布式同步等功能。

       Zookeeper也是基于主从架构，搭建了一个可高扩展的服务集群，其服务架构如下所示：

      4、Eureka

      Eureka 基于Restful Api 开发的服务注册与发现组件，由 Netflix 开源。遗憾的是，目前Eureka仅开源到1.X版本，2.X版本已经宣布闭源。关于 Eureka 体系具体内容可参考之前文章：

      关于上述不同组件所实现的服务注册与发现以及相关特性支持，具体可参考如下列表所示：

	Etcd	Consule	Zookeeper	Eureka
CAP支持	CP	CP	CP	AP
一致性算法	Raft	Raft	Paxos	/
KV存储服务	支持	支持	支持	/
接口协议支持	Http/gRPC	Http/DNS	Client	Http(Sidecar)
Watch支持	支持 long polling	全量/支持 long polling	支持	支持 long polling/大部分增量
自身监控	metrics	metrics	/	metrics
安全	https支持（弱）	acl /https	acl	/
Spring Cloud集成	支持	支持	支持	支持
多数据中心	/	支持	/	/

        语言特性

       随着微服务架构的日益成熟，新兴市场的场景涌现以及云原生生态领域的不断完善，衍生出跨不同体系平台的语言。比如，当前市场火热的 Go 语言。其不仅支撑微服务的业务架构所需，同时，也拥抱云原生的相关平台，使得其发展势头较猛，越来越多的厂商及企业开始基于其进行业务开发。

       针对当前比较流行的2种用于构建微服务体系的编程语言，Java 与 Go ，在这里简要介绍，具体如下。

       首先，Go 不是面向对象编程语言。Go 没有类似 Java 的继承机制，因为它没有通过继承实现传统的多态性。本质上讲，它没有对象，只有结构体。但它可以通过接口和让结构体实现接口来模拟一些面向对象特性。此外，我们可以在结构体中嵌入结构体，但内部结构体无法访问外部结构体的数据和方法。Go 使用组合而不是继承将一些行为和数据组合在一起。

       其次，Go 是一种命令式语言，Java 是一种声明式语言。Go 没有依赖注入，我们需要显式地将所有东西包装在一起。因此，在使用 Go 时尽量少用“魔法”之类的东西。

       再次，当前开源容器编排领域中最火热的 Kubernetes 云操作系统其主要也是基于 Go 语言编写，故使得 Go 所开发的插件能够无缝潜入或对接。

       最后，基于开发平台的选择，Go Web 开发能够展现 Go 的快速、强大和易于理解，非常适用于小型服务和高并发处理场景。然而，对于大型复杂的系统、功能复杂的服务以及单服务器系统，建议还是优先考虑 Java 。

       针对微服务架构所涉及的周边生态，例如：配置中心（Apollo、Nacos、Spring Cloud Config等等）、链路追踪（Zipkin、Pinpoint、Skywalking、Jaeger、Cat等等），仅仅作为一种辅助性支撑框架，对于整个微服务架构发展影响力有限，故暂不在本章赘述。

       综上所述，针对微服务架构的选型，不仅仅涉及技术框架、业务需求、团队实力，同时，也要结合市场的发展现状、生态的成熟度以及公司组织层面的支持，只有基于综合性评估，才能使得业务的实现事半功倍。

- EOF -