写点什么

关于微服务架构思考

用户头像
Arthur
关注
发布于: 2020 年 08 月 07 日

微服务概念来源:https://martinfowler.com/articles/microservices.html


微服务【架构】 和 RPC【框架】,二者本身不在一个层面


微服务【架构】,关注把 如何 大型单体应用 拆分成 多个能独立部署并提供服务的应用,这过程中解决【业务能力】拆分,而不是简单的分层或者按业务线划分;


微服务架构,看重【分工】,是一个【软件架构】设计思想(或者说 设计方法),是一个【去中心化】的思想,需要解决的问题:

如何把 大型单体应用 按【业务能力】进行划分,这个业务能力 不是 简单的 按产品 划分,【业务能力】如果划分不清晰,会导致 责任分散,调用混乱;

微服务 就是 分布式服务,这个概念只是因为 Martin Flower 的一篇文章火了;


一个单体应用被拆分成 A、B、C 三个微服务,A 和 B 之间可以用 RPC 通信,B 和 C 之间可以用 http 通信,对于远程访问通信更多在于服务拆分后,服务提供方的选型。


RPC【框架】,关注 方法远程调用实现,解决 远程通信 带来的问题,更多针对 技术问题;


RPC 框架 是 解决远程通信 ,可以看错 方法调用 的 代理模式,调用者 不关心调用的 是本地方法 还是 远程方法,RPC 就是要解决 远程调用 相关问题 包括:

1、传输数据协议

2、集群负载均衡

3、集群容错


架构 是 解决系统 可用性,可扩展,可维护性,这是软件本身基本要求,与 并发高低 无关;

框架 是 针对某个规范,所做的实现,比如 SUN 指定 JVM 规范,每个厂商根据规范实现,数据库也有规范,不同厂商按照规范进行实现;


Microservices Is an Architecture ;

RPC is a framework;


发布于: 2020 年 08 月 07 日阅读数: 77
用户头像

Arthur

关注

还未添加个人签名 2018.08.31 加入

还未添加个人简介

评论 (2 条评论)

发布
用户头像
二者不是一个层面同意,但是RPC慢慢会成为微服务通信的标准选择。微服务独立拆分,但是通信不可避免,微软的.net core 微服务生态已经把grpc纳入,并主推此方式通信。在容器化集群场景下,rpc也是重要的组件。两者关联性还是很高的
2020 年 08 月 08 日 09:07
回复
感谢你的分享,远程调用是 分布式架构,或者说微服务架构 比较困难的问题,你说的几个方案我先了解后,希望有机会和你多交流~
2020 年 08 月 10 日 10:18
回复
没有更多了
关于微服务架构思考