微服务技术选型

概念

springCloud

一个微服务的标准通用解决方案或者说治理平台，非具体的注册中心或者rpc框架，广义上代表的是一种平台套件，内部包含多重云化微服务化技术选项，比如注册中心：Zookeeper，Eureka、Nacos、Consul。技术上有：azure,alibaba,amz web service,consul,netflix,zookeeper等等。可以理解这些都是插拔式的组件，按需选择对应组件

springcloud完成:

• Distributed/versioned configuration
  分布式版本配置
• Service registration and discovery
  服务注册和发现
• Routing
  路由
• Service-to-service calls
  服务调用
• Load balancing
  负载均衡
• Circuit Breakers
  断路 器
• Global locks
  全局锁
• Leadership election and cluster state
  领导选举和集群
• Distributed messaging
  分布式消息传递

注册中心

注册中心是通过提供服务注册和发现/推送来管理维护业务的服务信息，起到一个业务系统信息独立维护作用，避免业务耦合，故障面扩大，实现统一标准的信息存储。
简单说就是一个脱离业务独立做业务系统信息状态维护的系统应用，它提供相应的api来接收多个服务的注册和获取. 就是一个集中的信息维护站
常见的注册中心有：Zookeeper，Eureka、Nacos、Consul、Kubernetes

为什么需要注册中心，为什么不直接调用服务

1、如果服务A直接调用服务B,这时候就需要A固定知道B,但在云化环境下，这个恰恰是不固定的
2、出现故障时候的统一管控，比如服务A出现故障，这时候如果让每个系统自身去检测就比较繁琐，并且容易引发其它问题（网络不可达，未知异常等）
3、灰度发布等相关动态处理
4、服务的集群负载问题
。。。等等其它的微服务网络下的维护问题
区分RPC, 两者不是一个东西，从实现看，注册中心的具体服务调用是需要通过rpc来实现的，rpc可以独立作为服务调用工具。在微服务架构下，两者是一种组合关系
注册中心最核心的是 服务注册和服务发现，通过它实现服务调用。主流的几种方式：
1、 发布-订阅。 消费者及时获取到最新状态。 zk
2、主动拉取。客户端定时拉取最新信息，客户端控制。eureka
没有一定的好坏，只是按需选择不同

理论上：能完成信息存储和信息查询的就可以做注册中心了。就是一个集中的非业务型的数据存储，这种redis,mysql都可以。只是一般为了业务需要和管理需要，注册中心肯定会有一些负载，管理，版本之类的额外作用，包括可扩的能力。所以还是必须使用专门的注册中心组件来做。

RPC框架

通过RPC框架来实现不同服务应用之间的通讯访问，达到类似于访问本地数据的效果。
简单说就是提供标准的方式来做到服务间的数据传递
1、dubbo
2、httpclient
3、grpc
4、thrift
5、其它还有微博的motan，腾讯tars，不过多介绍

负载均衡

微服务下基本都是多应用多集群方式。也就是服务A可能有很多个应用进行提供能力，这时候调用服务A就需要去选择最优的访问对象
主流算法有：
1、轮询
2、随机
3、hash -- 可以保证一个应用（一般ip一样）每次访问的服务都是同一个
4、加权轮询。 配置服务的权重。可以理解为权重高的轮对此吧
5、加权随机。按权重进行随机。权重高的更容易随机到
6、最小连接。尽量找最小访问量的请求

CAP理论

一致性(Consistency)：所有节点在同一时间具有相同的数据；
可用性(Availability) ：保证每个请求不管成功或者失败都有响应；
分隔容忍(Partition tolerance) ：系统中任意信息的丢失或失败不会影响系统的继续运作。

分布式系统协议

一致性协议算法主要有Paxos、Raft、ZAB。

Paxos算法是Leslie Lamport在1990年提出的一种基于消息传递的一致性算法，非常难以理解，基于Paxos协议的数据同步与传统主备方式最大的区别在于：Paxos只需超过半数的副本在线且相互通信正常，就可以保证服务的持续可用，且数据不丢失。

Raft是斯坦福大学的Diego Ongaro、John Ousterhout两个人以易理解为目标设计的一致性算法，已经有了十几种语言的Raft算法实现框架，较为出名的有etcd，Google的Kubernetes也是用了etcd作为他的服务发现框架。

Raft是Paxos的简化版，与Paxos相比，Raft强调的是易理解、易实现，Raft和Paxos一样只要保证超过半数的节点正常就能够提供服务。这篇文章 《ETCD教程-2.Raft协议》 详细讲解了Raft原理，非常有意思，感兴趣的同学可以看看。

ZooKeeper Atomic Broadcast (ZAB, ZooKeeper原子消息广播协议)是ZooKeeper实现分布式数据一致性的核心算法，ZAB借鉴Paxos算法，但又不像Paxos算法那样，是一种通用的分布式一致性算法，它是一种特别为ZooKeeper专门设计的支持崩溃恢复的原子广播协议。

选型依据

0、能够满足业务和性能需求
1、通用性，生态完善
2、更新迭代维护性，官方维护并且中长期看是维护的；研发或者运维维护上方便
3、易用性，开发使用简便
4、架构优异，技术上是更适合后续发展的
4.1、足够简单
5、无版权风险
6、有利于后续团队的整体技术栈统一（适当的性能和架构退步下换取大部分业务的整合通用使用）
6.1、这块会考虑spring的兼容问题，java生态无法绕开spring，所以官方集成维护会是一个重要指标
7、有利于多语言的开发（C）
8、个人偏好

注册中心比较

zookeeper

严格来说，不是专门做注册中心的，是做分布式协调的。不过现在用做注册中心也挺多的。并且方案也算通用，也作为一个选项来分析
1、CAP
保证的是CP,一致性高，不保证一定可用

2、注册和发现
客户端进行注册，服务端记录。当客户端出现变更后，服务端感知进行推送其它客户端消息，客户端获取消息后进行拉取变动

3、集群
存在leader选举，也就是需要基数
服务端为独立部署进程

PS
特别说明下，zk的非A代表的是自身的非高可用。简单说，当master出现问题，选举过程中是无法服务的

eureka
springcloud默认推荐的注册中心，github当前已经不再迭代，2.x废弃，1.x进行维护阶段！ 传闻是转闭源了。 当前常见的就是JAVA版本，并且直接结合到springcloud偏多。-- 也可以理解为server就是一个app
1、CAP
保证的是AP,高可用，但可能存在不一致情况

2、注册和发现
客户端定时的去维护心跳，也去同步刷新注册的信息

3、集群
不存在leader选举，每个节点都是对等的
服务端可以看做一个应用进程

Nacos

阿里巴巴出品，springcloudalibaba进行集成。github上算是更新活跃的，阿里使用（https://nacos.io/zh-cn/），容易依赖其生态，并且阿里这块的开源组件口碑一般。整体的集成度很高，各个组件比较全面，可以达到开箱即用，性能不错--看介绍未实测。
1、CAP
AP,CP都可，可控
2、注册和发现
参考其配置中心模式，采用客户端拉取，长轮询模式。 客户端有定时任务进行拉取对比服务端配置信息，服务端如果有变动，立即返回，否则进入挂起等待，直到返回超时，客户端开启下一次轮询。整体加快了响应时间

3、集群
不存在leader选举，每个节点都是对等的
服务端独立部署进程

4、其它
集成了配置中心

Consul
go开发的一个注册中心服务，springcloudconsul集成。支持良好。
1、CAP
CP
2、注册和发现
提供者进行注册，服务端定时去更新监控状态，维护一个服务表；消费者定时获取刷新服务列表。 消费端直接通过服务表的ip、port去访问服务
3、集群
服务端独立部署进程
4、其它
国内云上环境支持的一般。
Kubernetes
不了解，暂时忽略

总体比较，网上找的

开发实际案例对比

server维护
zk: 很多云环境可以独立申请，特色维护
nacos：云环境特殊支持
consul：国内自己独立进程部署
eureka：独立的java进程，类应用。高可控，稳定性和维护是个问题
springcloud的集成
几种都有官方集成,使用上差别不大
provider和consumer的维护开发
这块主要体现在rpc选择上，本身注册中心影响不大。
管理查看界面
zk:无官方，需要安装第三方ui
nacos：官方自带，有流量查看之类，功能全面
consul：官方自带，一般可用
euraka：自带，简陋可用

后期维护性
zk: 可以组合成为基础组件，配合其它一起使用，加上第三方ui，还算方便
nacos：官方提供了一套维护ui，方便
consul：可以考虑多语言的支持
euraka：当前仅是可用，后期不会有提升

安全问题
zk:维护还算及时，兼容性良好
nacos：部分有云上环境支持，安全问题支持还算及时，问题也不少
consul:看支持厂商，国外用的挺多，理论上支持不会很慢，国内待定
eureka: 预估不会非常及时，但还会维护下去

开发难度
zk: 开源组件，工具很多都支持，方案好找
nacos：全套解决方案，按照阿里思路基本能够解决所有场景问题
consul：未知，原go开发的，springCloud有组件
euraka: 通用方案，基本很多生产环境在用，教程很多。调用维护简单

组件维护情况
zk: 使用量大，维护靠谱
nacos：阿里开源风评一般，但主打开箱即用，尤其是结合到了一些云上环境销售，不容易和dubbo一样废弃
consul：未知
euraka：1.x还是在维护中，无新功能研发了。2.x已经停掉，暂无3.x消息。 纯粹用短期还行

RPC框架选型

openFeign
原来奈飞的Feign框架不维护后演变来的开源版本。基于http协议，无状态，短连接.Feign默认集成了Ribbon.

1、负载均衡
支持策略：轮询、随机、ResponseTime加权。
负载均衡算法是Client级别的。
利用熔断机制来实现容错的，处理的方式不一样

2、性能
一般，走的http协议。短连接算重度接口了
3、开发使用
中等。就相当于一个http请求调用。灵活但需要注意兼容

4、后续支撑
良好，spring官方维护

dubbo
阿里开发的一个开源rpc框架。通过jdk proxy等技术来实现访问远程接口类似本地方法调用的方式。

支持多传输协议(Dubbo、Rmi、http、redis等等)，可以根据业务场景选择最佳的方式,非常灵活。
默认的Dubbo协议：利用Netty，TCP传输，单一、异步、长连接，适合数据量小、高并发和服务提供者远远少于消费者的场景。

1、负载均衡

支持4种算法（随机、轮询、活跃度、Hash一致性），而且算法里面引入权重的概念。
配置的形式不仅支持代码配置，还支持Dubbo控制台灵活动态配置。
负载均衡的算法可以精准到某个服务接口的某个方法。

支持多种容错策略：failover、failfast、brodecast、forking等，也引入了retry次数、timeout等配置参数。

2、性能
按需调整tcp长链，并发高。不适合通用接口协议

3、开发使用
简单。注册后，dubbo服务可以当成一个本地类方法调用。由底层实现负载，容错等。不够灵活但更规范。需要注意序列化问题

4、后续支撑
一般，阿里的产品，之前断更过。但现场有apache支撑，应该还算可靠

grpc技术。nacos内部使用了
暂未分析。springcloud中未发现组件，有集成方案，并且支持多语言

配置中心

因为当前不确定是否做，不过多介绍
nacos
自带全套，很方便使用，结合springcloud或者单独的springboot很方便使用

springcloudconfig
自己集成实现。可以用zookeeper来实现。开发比较方便，更新还需要额外的命令或者页面处理，不太方便

附录一份nacos的架构图

日志追踪链路问题

待定

MQ问题

ctgmq用的RocketMQ，这边选型直接用RocketMQ即可。
有日志之类可丢失数据的并且大量数据的，额外加kafka

RocketMQ

RabbitMQ

Kafka
主要处理大数据方面的

以下是网上摘取的部分内容，随着技术迭代，本身的一些问题在慢慢变化。这边只给出大体的建议。

对各个注册的实际代码进行演示讲解

1、原理简单介绍
2、代码集成模块的maven关系
3、代码调用开发提供者和消费者关系
4、运行启动
5、检查web页面或者命令查看
6、评论好坏检查页面或者数据

选型比较
基于运营商环境和我们内部的技术栈

可用性
因为zk是cp的，非高可用，但当前zk一般是云环境管理，本身可靠性较高。虽然纯技术角度劣势于nacos，但相对可用
负载均衡
两者都可以使用robbin来做，duboo本身可以实现多重负载，粒度更小到服务级别，相对可靠性更高

通用
都算比较广范的使用。一个是全球一个是国内。整体来说nacos从解决方案上更高
zk相对来说更有利于团队技术栈的统一

后续维护
阿里的风评一般。dubbo纳入了apache应该可持续，nacos待定
zk优异

易开发
dubbo的开发很简单
Fiegn 相对通用，就是http请求，resttemplte类似，合并为一起了

架构优异
从解决方案上看nacos更合适，更统一
从微服务架构看，nacos更优秀
从整体来看，nacos提供了完整的解决方案。包括了配置更新，熔断限流机制，并提供了友好的维护界面；zk很原始，需要自己去找组件配合使用
版权风险
都为开源可商用，都是apche 2许可

多语言开发
zk更方便集成到C（也无官方，就是更通用，更容易做统一方案）
nacos看官方支持

个人偏好

基础组件

• 语言使用java8，考虑云环境的默认为8
• 工程管理使用maven，大家比较熟悉
• 基础框架使用springboot + springcloud来做（版本基于的springboot 2.7.x）
• 注册中心待选型--包括注册中心、【配置中心、】MQ、链路日志、负载熔断限流组件、logback做内部日志、axis做webservice独立对外模块、新接口统一使用restful+json风格
• 尽量不引入非必要组件
• 云上环境的云眼集成由公共工程统一集成