目录

一、RPC

1.1 RPC调用流程

二、SOA

三、微服务

3.1.什么是微服务

3.2.微服务与微服务架构

1 &＃xff09;微服务架构

2&＃xff09; 微服务

3.3.微服务的优缺点

3.1 微服务的优点

3.2 微服务的缺点

四.微服务的技术栈有哪些

一、RPC

　　RPC&＃xff08;Remote Process Call&＃xff09;&＃xff0c;即远程服务调用&＃xff0c;被广泛地应用在很多企业应用中&＃xff0c;是早期主要的服务治理方案&＃xff0c;其流程较为简单&＃xff0c;客户端consumer携带参数发送RPC请求到服务提供方provider&＃xff0c;provider根据参数路由到具体函数&＃xff0c;方法&＃xff0c;并将执行获得的结果返回&＃xff0c;至此一次RPC调用完成。

　　

　　随着业务的发展&＃xff0c;大数据时代的到来&＃xff0c;服务提供方的压力也日益增大&＃xff0c;单机应用的处理能力无论在软件&＃xff0c;硬件上都受到限制&＃xff0c;provider也不可能一直无限扩容&＃xff0c;即使扩容&＃xff0c;也存在着很多问题&＃xff0c;即服务的路由&＃xff0c;和Consumer的负载均衡问题。因此&＃xff0c;分布式服务架构应运而生&＃xff0c;RPC发展到一定阶段思考的变革&＃xff0c;成为了分布式服务&＃xff0c;云计算的计算机基础。

        在RPC框架中主要有三个角色&＃xff1a;Provider、Consumer和Registry。如下图所示&＃xff1a;

节点角色说明&＃xff0c;这边看起来&＃xff0c;跟其他的服务注册与发现框架原理差不多&＃xff08;如  Eureka、Consul&＃xff09;&＃xff1a;

Service&＃xff08;provider&＃xff09;: 暴露服务的服务提供方。

Client&＃xff08;consumer&＃xff09;: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心。

RPC指的是项目之间的调用。RPC是把单体项目做了粗粒度的拆分&＃xff0c;而微服务把单体项目拆分的更零碎。

因为RPC是独立系统之间的调用&＃xff0c;所以不太注重事务的一致性

1.1 RPC调用流程

RPC&＃xff08;Remote Procedure Call&＃xff09;远程过程调用&＃xff0c;即一个节点通过网络调用的方式来请求另一个节点提供的服务的过程&＃xff0c;也可以简单的理解为client访问server上提供的函数。

他的基本调用流程如下&＃xff1a;

上面是一次完整的RPC调用流程&＃xff08;这边指的是同步调用情况下&＃xff09;&＃xff0c;步骤顺序如下&＃xff1a;

1. 客户端&＃xff08;client&＃xff09;以本地调用方式&＃xff08;即以接口的方式&＃xff09;调用服务&＃xff1b;
2. 客户端存根&＃xff08;client stub&＃xff09;接收到调用后&＃xff0c;负责将方法、参数等组装成能够进行网络传输的消息体&＃xff08;将消息体对象序列化为二进制 byte[]&＃xff09;&＃xff1b;
3. 客户端通过sockets将消息发送到服务端&＃xff1b;
4. 服务端存根( server stub&＃xff09;收到消息后进行解码&＃xff08;将消息对象反序列化&＃xff09;&＃xff1b;
5. 服务端存根( server stub&＃xff09;根据解码结果调用本地的服务&＃xff1b;
6. 本地服务执行并将结果返回给服务端存根( server stub&＃xff09;&＃xff1b;
7. 服务端存根( server stub&＃xff09;将返回结果打包成消息&＃xff08;将结果消息对象序列化&＃xff09;&＃xff1b;
8. 服务端&＃xff08;server&＃xff09;通过sockets将消息发送到客户端&＃xff1b;
9. 客户端存根&＃xff08;client stub&＃xff09;接收到结果消息&＃xff0c;并进行解码&＃xff08;将结果消息反序列化&＃xff09;&＃xff1b;
10. 客户端&＃xff08;client&＃xff09;得到最终结果。

RPC的目标是要把2、3、4、7、8、9这些步骤都封装起来。

无论是何种类型的数据&＃xff0c;最终都需要转换成二进制流在网络上进行传输&＃xff0c;数据的发送方需要将对象转换为二进制流&＃xff0c;而数据的接收方则需要把二进制流再恢复为对象。

二、SOA

　　由于简单的RPC调用已经不能随着时代发展满足需求&＃xff0c;因此复杂的业务逻辑对于分布式应用架构体系的需求愈发强烈&＃xff0c;业务希望自己的服务是分布式部署的&＃xff0c;请求是分流的&＃xff0c;对数据的操作是能读写分离的&＃xff0c;同时能屏蔽许多复杂需要自己编写的底层服务&＃xff0c;借助已有的公共服务&＃xff0c;去快速的构建自己的应用&＃xff0c;降低人力开发维护的成本和提高应用交付的效率&＃xff0c;基因此&＃xff0c;基于分布式服务思想的SOA&＃xff08;Service-Oriented Architecture&＃xff09;成了新的受追捧的架构。常见的SOA服务调用流程图如下&＃xff1a;　

三、微服务

严格来说微服务属于RPC的一种&＃xff0c;但是广义上的RPC指的是项目之间的调用 

3.1.什么是微服务

1) Martin Fowler论文对微服务的阐述(中文版)

2) 对单一应用进行拆分

3) 每一个独立的应用都有一个独立的进程

4) 拥有自己独立的数据库

5) 微服务化的核心就是讲传统的一站式应用&＃xff0c;根据业务拆分成一个一个的服务,彻底地去耦合&＃xff0c;每一个微服务提供单个业务功能的服务&＃xff0c;一个服务处理一件事,从技术角度就是一种小而独立的处理过程,类似进程的概念,能够自行单独启动或销毁,拥有自己的数据库。

3.2.微服务与微服务架构

1 &＃xff09;微服务架构

1) 类似于eclipse工具里面用maven开发的一个个独立的module,具体是使用springboot开发的一个小模块,一个模块就做一件功能。

2) 强调是整体&＃xff0c;每一个个体完成一个具体的任务或者功能&＃xff0c;把一个个的个体拼接起来&＃xff0c;组成一个整体并对外暴露服务。

3) 微服务架构是一种架构模式,它提倡将单一的应用程序划分成一组小的服务,服务之间互相协调、互相配合&＃xff0c;为用户提供最终价值。每个服务运行在其独立的进程中&＃xff0c;服务与服务间采用轻量级的通信机制互相协作(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建&＃xff0c;并且能够被独立的部署到生产环境、类生产环境等。另外&＃xff0c;应当尽量避免统一的、集中式的服务管理机制。对具体的一个服务而言&＃xff0c;应根据业务的上下文&＃xff0c;选择合适的语言、工具对其进行构建。

2&＃xff09; 微服务

强调的是服务的大小&＃xff0c;它关注的是某一个点&＃xff0c;是具体解决某一个问题/提供落地对应服务的一个服务应用&＃xff0c;狭义地看&＃xff0c;可以看做Eclipse里面的一个个微服务工程或者Module。

注意,微服务、微服务架构、Spring Cloud是三种不同的概念&＃xff0c;不要弄混淆。

3.3.微服务的优缺点

3.1 微服务的优点

1) 每个服务足够内聚&＃xff0c;足够小&＃xff0c;代码容易理解这样能聚焦一个指定的业务。单机版的应用由于很多业务耦合在一起&＃xff0c;修改代码时往往需要读懂一整块的业务功能&＃xff0c;而微服务项目只需要了解其中一小块&＃xff0c;由于项目足够小并且都是独立的&＃xff0c;代码更容易理解&＃xff0c;也更容易维

2) 开发简单&＃xff0c;开发效率提高&＃xff0c;精力集中&＃xff0c;一个服务只做一件事。

3) 小团队也能单独开发&＃xff0c;管理容易&＃xff0c;管理成本降低。

4) 微服务是松耦合的&＃xff0c;是有功能意义的服务&＃xff0c;无论是在开发阶段还是在部署阶段都是独立的&＃xff0c;这样可以防止某个项目出问题了其他服务项目不会受到影响。

5) 微服务能使用不同语言开发。

6) 易于和第三方集成&＃xff0c;微服务允许容易且灵活的方式集成自动部署&＃xff0c;通过持续集成工具&＃xff0c;例如Jenkins,Hudson,bamboo。

7) 微服务易于被一个开发人员理解&＃xff0c;修改和维护&＃xff0c;这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。

8) 微服务允许你利用融合最新技术。

9) 微服务只是业务逻辑代码&＃xff0c;不会和HTML&＃xff0c;CSS或其他界面组件混合。

10) 每个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一的数据库。可以灵活搭配&＃xff0c;连接公共库&＃43;连接独立库。

3.2 微服务的缺点

1) 开发人员需要处理分布式系统的复杂性。

2) 多服务运维难度&＃xff0c;随着服务的增加&＃xff0c;运维的压力也在增大。

3) 系统部署依赖&＃xff0c;一个模块调不通有可能影响到其他模块的使用。

4) 服务间通信成本变高。

5) 数据的一致性问题。

6) 系统集成测试变复杂。

7) 性能监控变困难。

四.微服务的技术栈有哪些

微服务技术栈是多种技术的集合体。

• 服务开发:Spring Boot、Spring、Spring MVC

• 服务的配置与管理:Netflix公司的Archaius、阿里的Diamond等

• 服务注册与发现:Eureka、Consul、Zookeeper等

• 服务调用:Rest、RPC、gRPC

• 服务熔断器:Hystrix、Envoy等

• 服务负载均衡:Ribbon、Nginx等

• 服务接口调用(客户端调用服务的简化工具):Feign等

• 消息队列:Kafka、RabbitMQ、ActiveMQ等

• 服务配置中心管理:SpringCloudConfig、Chef等

• 服务路由(API):Zuul等

• 服务监控:Zabbix、Nagios、Metrics、Spectator等

• 全链路追踪:Zipkin、Brave、Dapper等

• 服务部署:Docker、OpenStack、Kubernetes等

• 数据操作开发包:SpringCloud Stream(封装Redis、RabbitMQ、Kafka等发送接收消息)

• 事件消息总栈:Spring Cloud Bus

https://www.cnblogs.com/wzh2010/p/15642251.html

https://www.cnblogs.com/jiyukai/p/9459983.html