一、微服务架构实现需求

技术实现取决于需求，也就是微服务架构需要的考虑的基本技术问题。一个基本的微服务架构需要实现基本的五大核心功能：服务注册和发现、服务间通信、服务容错、数据管理和API网关，基本实现需求如下：

微服务架构技术有哪些_微服务架构组件

二、微服务架构实现技术选型：参考标准的两个维度+微服务实现框架对比

所谓技术选型，就是选择一个合适的技术体系来支持微服务的开发工作，首先，要明确选型的参考标准。

（一）技术选型的两个参考标准

1.核心组件完备性

基本要求考虑以下5大核心组件：

服务通信
事件驱动
负载均衡
API网关
服务路由
配置管理

具体内容如https://blog.csdn.net/xiaofeng10330111/article/details/85682513.

2.关键要素实现难度

这点上我们主要需要明确注册中心及服务可靠性实现上的难度。

注册中心

关于服务注册和服务发现，比较常见的分布式一致性协议是Paxos和Raft协议。主要实现方案对比如下：

微服务架构技术有哪些_微服务架构组件

服务的健康检查

Euraka 使用时需要显式配置健康检查支持；Zookeeper,Etcd 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。

多数据中心支持

Consul 通过 WAN 的 Gossip 协议，完成跨数据中心的同步；而且其他的产品则需要额外的开发工作来实现；

KV 存储服务

除了 Eureka ,其他几款都能够对外支持 k-v 的存储服务，所以后面会讲到这几款产品追求高一致性的重要原因。而提供存储服务，也能够较好的转化为动态配置服务哦。

产品设计中 CAP 理论的取舍

Eureka 典型的 AP,作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。其次 CP 类型的场景 Consul,也能提供较高的可用性，并能 k-v store 服务保证一致性。而Zookeeper,Etcd则是CP类型牺牲可用性，在服务发现场景并没太大优势；

多语言能力与对外提供服务的接入协议

Zookeeper的跨语言支持较弱，其他几款支持 http11 提供接入的可能。Euraka 一般通过 sidecar的方式提供多语言客户端的接入支持。Etcd 还提供了Grpc的支持。 Consul除了标准的Rest服务api,还提供了DNS的支持。

Watch的支持（客户端观察到服务提供者变化）

Zookeeper 支持服务器端推送变化，Eureka 2.0(正在开发中)也计划支持。 Eureka 1,Consul,Etcd则都通过长轮询的方式来实现变化的感知；

自身集群的监控

除了 Zookeeper ,其他几款都默认支持 metrics，运维者可以搜集并报警这些度量信息达到监控目的；

安全

Consul,Zookeeper 支持ACL，另外 Consul,Etcd 支持安全通道https.

Spring Cloud的集成

目前都有相对应的 boot starter，提供了集成能力。

总的来看，目前Consul 自身功能，和Spring Cloud对其集成的支持都相对较为完善，而且运维的复杂度较为简单（没有详细列出讨论），Eureka 设计上比较符合场景，但还需持续的完善。

服务可靠性

相关功能主要包括服务容错、服务隔离、服务限流和服务降级，而且都偏向于实现策略而不是实现工具。

具体内容如https://blog.csdn.net/xiaofeng10330111/article/details/86772740.

（二）微服务实现框架对比

总体来说，微服务之一种架构风格，对于一个大型复杂的业务系统，特的业务功能可以拆分为多个相互交互的微服务，各个微服务之间是松耦合的，通过各种远程协议进行同步/异步通信，各微服务均可以被独立部署、扩缩容以及升降级。实现框架对比主要如下：

	Spring Cloud	Dubbo	Motan	MSEC	其他
功能	微服务完整方案	服务治理框架	服务治理框架	服务开发运维框架	略
通信方式	REST/HTTP	RPC协议	RPC/Hessian	Protocol buffer	grpc、thrift
服务发现/注册	Eurreka（AP）	ZK、Nacos	ZK/Conusl	只有服务发现	Etcd
负载均衡	Ribbon	客户端负载	客户端负载	客户端负载	Nginx+Lua
容错机制	6种容错策略	6种容错策略	2种容错策略	自动容错	Keepaliced、 HeartBeat
熔断机制	Hytrix	无	无	提供过载保护	无
配置中心	Spring Cloud Config	Nacos	无	无	Apollo、Nacos
网关	Zuul、Gateway	无	无	无	Kong、自研
服务监控	Hytrix、Turbine	Dubbo+Monitor	无	Monitor	ELK
链路监控	Sleuth+Zipkin	无	无	无	Pinpoint
多语言	Rest支持多语言	Java	Java	Java、C++、PHP	Java、PHP、Node.js
社区活跃	高，背靠spring	高，背靠阿里	一般	未知	略

服务框架是一个比较成熟的领域，有太多可选项。

Spring Boot/Cloud

由于 Spring 社区的影响力和 Netflix 的背靠，目前可以认为是构建 Java 微服务的一个社区标准，Spring Boot 目前在 GitHub 上有超过 20k 星。

基于 Spring 的框架本质上可以认为是一种 RESTful 框架（不是 RPC 框架），序列化协议主要采用基于文本的 JSON，通讯协议一般基于 HTTP。RESTful 框架天然支持跨语言，任何语言只要有 HTTP 客户端都可以接入调用，但是客户端一般需要自己解析 payload。目前 Spring 框架也支持 Swagger 契约编程模型，能够基于契约生成各种语言的强类型客户端，极大方便不同语言栈的应用接入，但是因为 RESTful 框架和 Swagger 规范的弱契约特性，生成的各种语言客户端的互操作性还是有不可坑的。

Dubbo

Dubbo是阿里多年构建生产级分布式微服务的技术结晶，服务治理能力非常丰富，在国内技术社区具有很大影响力，目前 github 上有超过 16k 星。Dubbo 本质上是一套基于 Java 的 RPC 框架，当当 Dubbox 扩展了 Dubbo 支持 RESTful 接口暴露能力。

Dubbo 主要面向 Java 技术栈，跨语言支持不足是它的一个弱项，另外因为治理能力太丰富，以至于这个框架比较重，完全用好这个框架的门槛比较高，但是如果你的企业基本上投资在 Java 技术栈上，选 Dubbo 可以让你在服务框架一块站在较高的起点上，不管是性能还是企业级的服务治理能力，Dubbo 都做的很出色。

新浪微博开源的 Motan（GitHub 4k stars）也不错，功能和 Dubbo 类似，可以认为是一个轻量裁剪版的 Dubbo。

gRPC

gRPC是谷歌近年新推的一套 RPC 框架，基于 protobuf 的强契约编程模型，能自动生成各种语言客户端，且保证互操作。支持 HTTP2 是 gRPC 的一大亮点，通讯层性能比 HTTP 有很大改进。Protobuf 是在社区具有悠久历史和良好口碑的高性能序列化协议，加上 Google 公司的背靠和社区影响力，目前 gRPC 也比较火，GitHub 上有超过 13.4k 星。

目前看 gRPC 更适合内部服务相互调用场景，对外暴露 RESTful 接口可以实现，但是比较麻烦（需要 gRPC Gateway 配合），所以对于对外暴露 API 场景可能还需要引入第二套 RESTful 框架作为补充。总体上 gRPC 这个东西还比较新，社区对于 HTTP2 带来的好处还未形成一致认同，建议谨慎投入，可以做一些试点。

新锐微服务框架：Istio （Service Mesh的设计理念）

Istio作为用于微服务服务聚合层管理的新锐项目，是Google、IBM、Lyft（海外共享出行公司、Uber劲敌）首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。

目前首个测试版是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和 Cloud Foundry等其他环境增加支持。 Istio将流量管理添加到微服务中，并为增值功能（如安全性，监控，路由，连接管理和策略）创造了基础。

主要体现在以下几点：HTTP、gRPC和 TCP网络流量的自动负载均衡；提供了丰富的路由规则，实现细粒度的网络流量行为控制；流量加密、服务间认证，以及强身份声明；全范围（Fleet-wide）的策略执行；深度遥测和报告。

现如今企业在采用云计算首选开源，而选择一个开源框架，社区的活跃度将作为重要参考选项。结合项目背景、提供功能、社区更新活跃度和稳定性来看，对于使用 Java系开发业务较多的企业，SpringCloud是目前阶段最为稳妥的可执行微服务框架方案；对于更多企业来说，Istio作为支持对于 Kubernetes的优先支持来讲，也是一个值得关注的方案，其与语言几乎无绑定的特性也值得期待。目前对比来看，Dubbo则显得稍逊下来。