转载

微服务架构到底应该如何选择？

什么是微服务？

微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 共同提出，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时，服务会使用最小规模的集中管理（例如 Docker）技术，服务可以用不同的编程语言与数据库等。

微服务是SOA架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。

主要有一下几个特点

服务拆分粒度更细微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。

服务独立部署

每个微服务都严格遵循独立打包部署的准则，互不影响。比如一台物理机上可以部署多个 Docker 实例，每个 Docker 实例可以部署一个微服务的代码。

服务独立维护

每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维，并对整个生命周期负责。

服务治理能力要求高

因为拆分为微服务之后，服务的数量变多，因此需要有统一的服务治理平台，来对各个服务进行管理。

微服务架构下，服务调用主要依赖下面几个基本组件：服务描述注册中心服务框架服务监控服务追踪服务治理

开源RPC框架介绍

Dubbo

国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外开源，仅支持 Java 语言。中间一度没人维护坑了不少人，17年重启维护焕发新春。架构图如下

微服务架构到底应该如何选择？

官网： http://dubbo.io/

通信框架方面，Dubbo 默认采用了 Netty 作为通信框架。

通信协议方面，Dubbo 除了支持私有的 Dubbo 协议外，还支持 RMI 协议、Hession 协议、HTTP 协议、Thrift 协议等。

序列化格式方面，Dubbo 支持多种序列化格式，比如 Dubbo、Hession、JSON、Kryo、FST 等。

性能：

http://dubbo.apache.org/zh-cn...

Tars

Tars是基于名字服务使用Tars协议的高性能RPC开发框架，同时配套一体化的服务治理平台，帮助个人或者企业快速的以微服务的方式构建自己稳定可靠的分布式应用。

Tars是将腾讯内部使用的微服务架构TAF（Total Application Framework）多年的实践成果总结而成的开源项目。

官网： https://github.com/TarsCloud/...

架构图如下

微服务架构到底应该如何选择？

开源协议为：BSD-3-Clause

支持多语言 C++，Java，Nodejs，PHP，Go

性能： https://github.com/TarsCloud/...

gRPC

一开始由 google 开发，是一款语言中立、平台中立、开源的远程过程调用(RPC)系统。

官网： https://grpc.io

微服务架构到底应该如何选择？

基于HTTP/2HTTP/2 提供了连接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制。可以节省带宽、降低TCP链接次数、节省CPU，帮助移动设备延长电池寿命等。gRPC 的协议设计上使用了HTTP2 现有的语义，请求和响应的数据使用HTTP Body 发送，其他的控制信息则用Header 表示。

IDL使用ProtoBufgRPC使用ProtoBuf来定义服务，ProtoBuf是由Google开发的一种数据序列化协议（类似于XML、JSON、hessian）。ProtoBuf能够将数据进行序列化，并广泛应用在数据存储、通信协议等方面。压缩和传输效率高，语法简单，表达力强。

多语言支持（C, C++, Python, PHP, Nodejs, C#, Objective-C、Golang、Java）

gRPC支持多种语言，并能够基于语言自动生成客户端和服务端功能库。目前已提供了C版本grpc、Java版本grpc-java 和 Go版本grpc-go，其它语言的版本正在积极开发中，其中，grpc支持C、C++、Node.js、Python、Ruby、Objective-C、PHP和C#等语言，grpc-java已经支持Android开发。

Motan

Motan 是国内另外一个比较有名的开源的 RPC 框架，同样也只支持 Java 语言实现，它的架构可以用下面这张图描述。

微服务架构到底应该如何选择？

Motan 与 Dubbo 的架构类似，都需要在 Client 端（服务消费者）和 Server 端（服务提供者）引入 SDK，其中 Motan 框架主要包含下面几个功能模块。

register：用来和注册中心交互，包括注册服务、订阅服务、服务变更通知、服务心跳发送等功能。Server 端会在系统初始化时通过 register 模块注册服务，Client 端会在系统初始化时通过 register 模块订阅到具体提供服务的 Server 列表，当 Server 列表发生变更时也由 register 模块通知 Client。

protocol：用来进行 RPC 服务的描述和 RPC 服务的配置管理，这一层还可以添加不同功能的 filter 用来完成统计、并发限制等功能。

serialize：将 RPC 请求中的参数、结果等对象进行序列化与反序列化，即进行对象与字节流的互相转换，默认使用对 Java 更友好的 Hessian 2 进行序列化。

transport：用来进行远程通信，默认使用 Netty NIO 的 TCP 长链接方式。

cluster：Client 端使用的模块，cluster 是一组可用的 Server 在逻辑上的封装，包含若干可以提供 RPC 服务的 Server，实际请求时会根据不同的高可用与负载均衡策略选择一个可用的 Server 发起远程调用。

Spring Cloud

Spring Cloud 是为了解决微服务架构中服务治理而提供的一系列功能的开发框架，它是完全基于 Spring Boot 进行开发的，Spring Cloud 利用 Spring Boot 特性整合了开源行业中优秀的组件，整体对外提供了一套在微服务架构中服务治理的解决方案。它的架构图可以用下面这张图来描述。

微服务架构到底应该如何选择？

以下为Spring Cloud的核心功能：

分布式/版本化配置
服务注册和发现
路由
服务和服务之间的调用
负载均衡
断路器
分布式消息传递

Spring Cloud对于中小型互联网公司来说是一种福音，因为这类公司往往没有实力或者没有足够的资金投入去开发自己的分布式系统基础设施，使用Spring Cloud一站式解决方案能在从容应对业务发展的同时大大减少开发成本。

下图是RPC框架详细的比较

微服务架构到底应该如何选择？

如何选择？

微服务架构到底应该如何选择？

一家A轮融资的公司原来架构是net，想换java架构。

公司没有强大的研发实力，公司主要是to B业务，对并发要求不高，那可以试试Spring Cloud 架构，

Spring Cloud 不仅提供了基本的 RPC 框架功能，还提供了服务注册组件、配置中心组件、负载均衡组件、断路器组件、分布式消息追踪组件等一系列组件，被技术圈的人称之为“Spring Cloud 全家桶”，而 Dubbo、Motan 基本上只提供了最基础的 RPC 框架的功能，其他微服务组件都需要自己去实现,对于这类研发能力弱的团队，SpringCloud 无疑是最合适的，减少了研发成本，社区热度高，相关的教程文档很多，减少了入门成本；

再比如这家公司不准备切换Java框架还是继续使用net架构，有一定的研发能力，对并发要求很高，那gRPC无疑是最适合的，跨语言支持，高性能；