微服务架构的好处:
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