1.微服务架构选型

背景

 

业务情况

目前公司原有业务仍由其它城市团队维护，跑在各大云上。今年开始下云，购置200台刀片托管电信IDC。后续新业务研发初步确定由我们团队研发，后续计划申请支付牌照开展三方支付业务，同时陆续还有其他业务/功能系统的研发。所有的业务/功能应用，都将按照微服务架构思想开发，跑在微服务框架中。

技术能力

目前公司起步自研能力较弱，故目前Java技术栈依赖Spring体系。而技术人员构成主要呈现以下两个特点：

1. 应届毕业生占比过高，整体素质尚可
2. 有经验人员能力不足，学习积极性较弱，无人员培养意识

以上两个特定，导致之前团队氛围较差，有经验人员大都混日子，应届毕业生无人培养。

目前业务在发展初期，人员问题尚未产生直接性影响，同时也给团队了时间去重构框架、培养人员。

框架定位

服务框架将作为上游系统提供统一接入，承载多样的业务/功能，而下游系统除Java应用外，还会有如Python等应用，因此在选型时需考虑多语言支持能力，同时也正式基于此，服务监控类功能由独立团队负责，因此监控方面搭建框架时不过多考虑。

 

关于监控

目前微服务监控类功能实现，大都基于应用层面实现，建立在牺牲部分自身性能之上。同时对于系统和硬件方面的监控，均无法感知。因此监控团队在从硬件的数据口、操作系统日志等方面着手，来实现硬件和系统监控的同时，尝试进行服务的监控。后续根据其实现程度，再确定需要那些监控数据，故监控部分后文将暂不涉及。

---

需求

功能列表

按照微服务架构思想，搭建微服务框架将主要可能涉及以下及部分：

模块	功能	必须
Registry Center（注册中心）	服务注册 服务发现	是
API GateWay（服务网关）	统一接入 多渠道支持 服务限流 服务路由 服务聚合 客户端负载 服务熔断 服务降级 ......	是
Config Center（配置中心）	统一配置文件管理	否
Message Bus（消息总线）	微服务架构的ESB	否
Distributed Tracing（分布式跟踪）	调用链路追踪	否
......	......

 

 

 

 

 

 

 

 

 

 

 

 

可以看到搭建微服务框架注册中心和服务网关必须存在，其余的部分如配置中心、消息总线等非功能需求，后期适时增加即可；而对于诸如链路追踪等监控类功能，则由独立团队负责。

调用链路

框架搭建暂时只涉及服务网关和注册中心，最典型的服务调用链路大体如下：

1. 下游服务将自身注册到注册中心
2. 上游应用系统调用服务网关
3. 服务网关通过注册中心发现服务
4. 服务网关客户端负载后调用下游服务

---

选型

技术栈:Spring Cloud vs Dubbo

Spring Cloud: Spring 基于Spring Boot之上构建，为开发人员提供了工具来快速构建分布式系统的一套解决方案。

Dubbo: 阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能

从技术角度来看RPC vs REST

线程间通讯的方式上：Spring Cloud 采用基于HTTP协议传输约定数据的REST方式；而Dubbo则采用基于TCP协议传输序列化二进制数据的RPC方式。

二者各有利弊，RPC方式传输数据较小，网络带宽占用较少，但增加了异构系统间交互的复杂度；REST方式则正好相反。

考虑后续可能的多语言应用，以及微服务应用均部署在内网，带宽影响较小，故基于REST方式的Spring Cloud更为适用。

从社区支持力度来看，Spring Cloud目前支持力度更大，版本更新较快，应用也更广。

目前Dubbo虽已开始维护，但鉴于国内厂商开源的一贯策略，非商业合作方式使用，前景并不乐观。同时Dubbo的再次维护，也不排除是出于阿里云商业拓展和产业下沿的考虑。

综合考虑来看，最终我们选择基于Spring Cloud技术栈搭建私有云平台的服务框架。

 

Spring Cloud 选型

提到微服务架构必然离不开Spring Cloud， 在Spring Cloud Dalston、Edgware版本的时代，使用Spring Cloud搭建微服务，几乎等同由Zull +Eureka组成，伴之以Feign、Ribbon、Hystrix等组件的Netflix全家桶。在基于Spring Framework 5.0的Spring Boot 2.0版本发布的同时，Spring Cloud Finchley版本为我们提供了更多同时更有价值的选择。

Spring Cloud & Netflix OSS

Netflix OSS：Netflix（网飞）公司开源的一套微服务架构组件(Eureka, Hystrix, Zuul, Archaius, etc.)。

Spring Cloud Netflix: Spring对Netflix OSS的集成和封装

Spring Cloud发展初期通过封装Netflix OSS，快速的为开发人员提供了微服务架构搭建的解决方案，但这种封装更新、升级受制于人，同时整套解决方案也与Spring  Platform无关，存在两套技术体系。这也是为何Spring Cloud在后续版本中陆续基于Spring Platform自研替代组件的原因，如服务网关有Netflix Zuul和Spring Cloud GateWay两种选择。

18年初Spring Cloud Finchley版本的发布，可能会是Spring Cloud与Netflix决裂的开始

• Spring Cloud官网中Netflix相关合并到Spring Cloud Netflix中，不再独立列出
• 跳票许久的Zuul 2.0开源后，Spring 不打算集成

• Eureka 2.0版本的闭源风波，

• Eureka Client与WebFlux一直以来的不兼容

18年后半年开始，随着响应式编程在Spring 中体系中的广泛应用，以及Spring提供的WebFlux开始被陆续接纳，大量的开发者也的选择或主动或随波逐流的开始发生的变化。陆续出现了各种诸如Spring Cloud GateWay替代Zull，Consul替代Eureka的博文。

关于Service Mesh

关于下一代微服务架构的Service Mesh，基于以下两点不在我们考虑范围内：

1. 基层技术人员能力不足
2. 公司层面未引入DevOps，研发、运维团队切割

---

注册中心

套用网络上可作为注册中心组件/应用对比图：

注：此图euerka拼写错误应为eureka

其中ZK的设计定位作为注册中心并不适用；而etcd则需三方工具支持才能实现注册中心功能，也正基于此使用的人较少。故这两者不在考虑范围内。

Eureka vs Consul

Eureka:Netflix公司基于Java语言研发的注册中心组件。

Consul:HashiCorp公司基于Go语言研发的注册中心应用。

Java应用长久以来性能被人所诟病，而Go语言接近于C的性能，单纯从技术栈上来看，Consul性能略胜一筹。

Netflix vs HashiCorp

套用百度词条介绍，二者的背影介绍如下：

技术人员"背后金主"的背景及其商业模式，是软件生命力的支撑，毕竟孤胆英雄能攻一城但无法守一城。

一家影业公司技术部门以支撑自身业务目的研发的Eureka，一家科技公司作为技术输出研发的Consul。明确二者的出身，很多现象就很好理解，比如Eureka2.0版本的闭源风波。而并非针对具体业务和体量的Consul，显然其实用性会更强。

      Consul与各类注册中心对比

Eureka vs WebFlux

响应式编程由来已久，建立的数据流的基础上，通俗的来看主要在于数据获取方式由推到拉的变化，类似的变化已陆续实践在各类基础软件上，比如Kafka相对于传统MQ来说，获取消息的方式由监听MQ消息变为主动根据自身负载拉取消息。

同时Spring Framework 5框架基于Reactor项目，添加了对响应式编程的支持，在原有的Servlet技术栈之外提供的Reactive 技术栈。

Eureka服务依赖如下：

显然 Eureka Server是Servlet Web的产物，而前文提到Eureka Client目前与WebFlux尚不兼容，鉴于Eureka 2.0版本的闭源风波，后续是否兼容存疑。而Consul Client则可同时支持Servlet 和Reactive技术栈。

综上所述，Eureka vs Consul的选择问题演变成，想用Reactive Web 就没法使用Eureka。

为一个应用放弃一个技术栈显然得不偿失，响应式编程后续计划另起单独篇章提及。

选型结果：Consul

选择原因：

• Consul研发团队及公司更可期，有寻求商业合作获得支持的可能
• Consul理论性能和多IDC支持上更胜一筹，同时具备KV存储可用于更多场景
• 响应式编程纳入技术栈，但选择Eureka则必须放弃响应式编程，或自研适配成本过高

---

网关

注册中心选型时，提及了目前Spring 存在Servlet和Reactive 两个技术栈，而Netflix 的所有组件目前均只适配Servlet技术栈。

 

Zuul vs GateWay

Spring Cloud GateWay是Reactive技术栈产物，用于替代Netflix Zuul。成熟度和功能性上Zuul更完善，Spring Cloud GateWay功能较少，但便于自行添加功能。

选型结果：Spring Cloud GateWay

选择原因：

• Zuul Spring已明确不再集成，后续存在直接移除可能
• Spring Cloud GateWay更轻量级，自行维护成本较低，天然支持响应式编程

目前Finchley版本中Spring Cloud GateWay客户端负载、断路器等目前仍使用Netflix相关组件实现。Spring Boot 2.1 RC1版本已发布，期望不久Spring Cloud GateWay下一版本相关功能能够完善，相关Netflix组件能够移除。

内部计划在下一版本的Spring Cloud GateWay发布稳定后，从开源版本拉分支，开始自行维护完善。

---

至此，通过选型确定了Spring Cloud GateWay + Consul的微服务架构，下游应用服务根据业务特点，选择Servlet或Reactive技术栈构建服务即可。