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

什么是微服务？

微服务的概念最先是在 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/2
HTTP/2 提供了链接多路复用、双向流、服务器推送、请求优先级、首部压缩等机制。能够节省带宽、下降TCP连接次数、节省CPU，帮助移动设备延长电池寿命等。gRPC 的协议设计上使用了HTTP2 现有的语义，请求和响应的数据使用HTTP Body 发送，其余的控制信息则用Header 表示。

IDL使用ProtoBuf
gRPC使用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无疑是最适合的，跨语言支持，高性能；

没有完美的解决方案，只有最合适的

推荐阅读

互联网公司面试必问的Redis题目

互联网公司面试必问的mysql题目(下)

学习Java进阶技术干货、实践分享，职位内推，一块儿聊聊理想。志同道合的朋友，欢迎你的加入。