微服务Memo

微服务架构的好处:

1,使大型的复杂应用程序可以持续交付和持续部署.

2,每个服务都相对较小并容易维护.

3,服务可以独立部署.

4,服务可以独立扩展.

5,微服务架构可以实现团队的自治.

6,更容易实验和采纳新的技术.

7,更好的容错性.

微服务架构的弊端:

1,服务的拆分和定义是一项挑战.

2,分布式系统带来的各种复杂性,使开发,测试和部署变得更困难.

3,当部署跨越多个服务的功能时需要谨慎地协调更多开发团队.

4,开发者需要思考到底应该在应用的什么阶段使用微服务架构.

 

微服务架构中的进程间通信,兴趣点:

REST好处:

1,简单,大家都很熟悉.

2,可以使用浏览器扩展(如postman)或者curl等来测试HTTP API.

3,直接支持请求/响应方式的通信.

4,HTTP对防火墙友好.

5,不需要中间代理,简化了系统架构.

REST弊端:

1,只支持请求/响应方式的通信.

2,可能导致可用性降低.由于客户端和服务直接通信而没有代理来缓冲消息,因此他们必须在REST API调用期间都保持在线.

3,客户端必须知道服务实例的位置(URL).

4,在单个请求中获取多个资源具有挑战性.

5,有时很难将多个更新操作映射到HTTP动词.

 

由于HTTP仅提供有限数量的动词,因此设计支持多个更新操作的REST API并不是很容易.为避免此问题的进程间通信技术是gRPC.

gRPC是一种基于二进制消息的协议,这意味着你不得不采用API优先的方法来进行服务设计.

gRPC API 由一个或多个服务和请求/响应消息定义组成. 服务定义类似于Java接口,是强类型方法的集合. 除了支持简单的请求/响应RPC之外,gRPC还支持流式RPC.服务器可以使用消息流回复客户端.客户单也可以向服务器发送消息流.

gRPC使用Protocol Buffers作为消息格式.

gRPC的好处:

1,设计具有复杂更新操作的API非常简单.

2,具有高效,紧凑的进程间通信机制,尤其在交换大量消息时.

3,支持在远程过程调用和消息传递过程中使用双向流式消息方式.

4,实现了客户端和用各种语言编写的服务端之间的互操作性.

gRPC的弊端:

1,与基于REST/JSON的API机制相比,JavaScript客户端使用基于gRPC的API需要做更多的工作.

2,旧式防火墙可能不支持HTTP/2

 

断路器! (很需要的功能,之前做server的时候很担心这种情况,竟然有固定的解决模式及中间件~~~哇咔咔)

使用断路器模式处理局部故障. 模式:断路器 这是一个远程过程调用的代理,在连续失败次数超过指定阈值后的一段时间内,这个代理会立即拒绝其他调用.  (Netflix Hystrix)

无代理消息

ZeroMQ

基于代理的消息

Apache ActiveMQ

RabbitMQ

Apache Kafka

基于云的消息服务

AWS Kinesis

AWS SQS

 

TO BE CONTINUE~