写点什么

架构师训练营第 0 期第 10 周作业

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

1、根据微服务框架 Dubbo 的架构图,画出 Dubbo 进行一次微服务调用的时序图



1-1、远程过程调用(RPC)的调用过程



1-1-1、RPC调用的参与者

  • 客户端(Client):服务调用方;

  • 客户端存根(Client Stub):存放服务端地址信息,将客户端的请求参数数据打包成网络消息,通过网络传输到服务端;并且将返回的响应数据转换为方法结果;

  • 网络服务(Network):RPC网络传输,可以是TPC或UDP,传输协议的编码可以是二进制也可以是文本;

  • 服务端存根(Server Stub):解析客户端发送的请求数据,并且调用本地代码进行处理,将处理结果通过网络服务返回客户端;

  • 服务端(Server):服务的真正提供者,保护方法的API定义和实现;



1-2、RPC要解决的问题

  • 服务注册:服务端如何将自己的服务(如接口方法)进行发布,如何向外界暴露服务端的机器IP和端口;

  • 服务下线:服务端机器缩容,需要将下线的机器信息通知外界,避免客户端调用到已下线的机器上;

  • 网络通信:解决【客户端】和【服务端】之间的远程网络通信问题;

  • 服务机器获取:客户端需要知道服务端提供的机器地址;

  • 负载均衡策略:【客户端】请求【服务端】时,需要实现负载均衡策略,避免请求不平均;

  • ....

1-3、Dubbo框架中的角色和功能说明

  • Consumer:服务消费者,也就是【客户端】;

  • Provider:服务提供者,就是【服务端】;

  • Registry:注册中心,负责保存Provider的注册信息,Consumer可以从Registry订阅Provider的注册信息,Registry可以通知给Consumer最新的Provider注册信息;



1-4、Dubbo服务调用时序图

1-4-1、服务注册与发现

1-4-1-1、服务注册与发现主要流程

  1. 【服务提供者应用程序】启动后,通过【服务管理容器】向【注册中心】注册提供服务器的基本信息,包括服务名称,服务协议,IP地址(host)、端口等信息;

  2. 【服务消费者程序】启动后,通过【服务框架客户端】,从【注册中心】获取到【服务提供者列表】,并将【服务提供者列表】缓存在【消费者服务器本地】;

  3. 如果【服务提供者】的机器发生【扩容】或者【缩容】,【服务提供者】将更改的机器信息同步给【注册中心】;

  4. 【注册中心】监听到【服务提供者】的机器信息,通知【服务消费者】更新本地的【服务提供者列表】;



1-4-1-2、服务暴露时序图(类级别)



1-4-2、服务调用

服务调用主要流程:

  1. 【服务消费者程序】调用【服务提供者】提供的【服务接口】,【接口访问代理】将方法和参数信息传给【服务框架客户端】;

  2. 【服务框架客户端】从本地【服务提供者列表】获取服务端机器信息;

  3. 再根据【负载均衡策略】选择远程调用的服务器;

  4. 将服务端机器、请求的方法 和 参数 通过【远程通讯模块】将请求发送到【服务提供者】的机器;

  5. 【服务提供者】的【远程通讯模块】接收到请求,创建【服务调用线程】,将请求发给具体的实现类处理;

  6. 处理完成后,将返回结果通过【远程通讯模块】返回给【服务消费者】;



2、关于微服务架构(中台架构、领域驱动设计、组件设计原则),你有什么样的思考和认识?

2-1、微服务架构的来源

为什么要用微服务架构,这得从单体应用的问题说起:

  • 单体应用编译部署困难,上线成本高;

  • 单体应用代码分支管理困难,研发效率低;

  • 新增业务困难,无法保持业务快速发展;

  • 硬件资源消耗大,如 应用服务器的配置高,数据库连接耗尽;

  • .....



要解决单体应用的问题,最好的方案就是拆分,按模块独立部署,降低系统耦合性;

2-2、微服务架构设计带来的问题

既然要对单体应用拆分,但是拆分也带来一系列问题:

  • 如何拆分?按什么维度进行拆分;

  • 拆分后各服务之间如何保证高效通信;

  • 如何降低服务扩容和缩容带来的维护成本;

  • 服务拆分的集群部署,如何实现集群的失效转移;

  • 服务集群部署,如何实现负载均衡访问;

  • 原本单体应用的事务在一个数据库,服务拆分后,数据库后如何保证分布式事务一致性问题;

  • 业务请求流程变长,从原本一个应用完成整个业务,变成由多个系统共同合作完成,服务的链路变长,如何保证业务正确完成;

  • 服务拆分后,各服务流量不均衡问题;比如电商的订单服务和地址服务;

  • 服务稳定性治理,如 限流、降级、熔断 等;

  • ......



2-2-1、RPC框架解决远程通信带来的问题

通过RPC框架,可以解决微服务间的远程调用中遇到的【服务注册】,【集群容错】,【负载均衡】和【高效通信】等问题,常见的RPC框架包括 Dubbo,Spring Cloud等。



2-2-2、分布式事务一致性问题

通过【分布式事务】组件,可以解决由于数据拆分带来的【分布式事务一致性】问题,分布式事务组件目前比较流行的就是 阿里巴巴的 Seata;



2-2-3、服务治理

至于微服务的治理,比如 熔断、限流、降级 方案等,Spring Cloud 提供了一整套解决方案,包括:

熔断降级:Hystrix;

服务注册发现:Eureka;



2-2-4、配置中心

随着微服务或者分布式服务设计演进,原本通过本地配置文件进行服务配置的方式已经过时,因为每次更新配置需要发布服务,而随着集群机器数量越来越多,每次发布也需要一定时间,目前分布式的配置中心也越来越流行,目前开源的包括 携程的Apollo,Spring Cloud基于 Zookeeper或Consul的配置中心;



2-2-5、服务拆分

最后的问题就是服务拆分,技术层面 包括 网络通信,服务注册等,都可以由技术手段进行解决,但是微服务本身如何进行拆解,根据什么依据进行拆解,成为微服务架构设计的一个难题;特别是某个功能边界比较模糊,无法明确划分,或者某项职责过去由多个人维护,而现在这些人在不同团队,当一个业务需要某项服务时,发现由多个系统都支持相似的服务,可能需要去多考虑服务的实现细节,是否能保证自己的业务等等,这一系列问题的根源,就是对于【复杂系统】的职责没有做好,有没有什么设计方法能解决?



2-3、领域驱动设计对微服务的价值

Eric Evans在2003年提出的领域驱动设计(DDD),就是将单体服务拆分为微服务的指导思想,使用DDD中对系统边界划分,通过【限界上下文】定义每个模型的应用范围,通过明确地定义模型所应用的上下文。根据团队的组织、系统软件的各个部分用法以及物理表现(代码和数据库等)来设置模型的边界。在这些边界中严格保持模型的一致性,而不要受到边界之外问题的干扰和混淆。

通过DDD找到领域的边界,通过边界指导系统进行拆分,这就解决了微服务如何拆分的问题。



2-4、中台架构

对于中台架构,微服务化只是实现业务中台在技术架构层面的一种手段,中台要实现的目标,包括:

消除企业重复建设,提高内部效能;

促进企业内部业务创新;

沉淀能力,对外开放,构建生态;



而业务中台与微服务解决的是不同的问题,业务中台解决的是企业级能力复用的问题,微服务解决的是“组件编译时依赖”的问题;



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

Arthur

关注

还未添加个人签名 2018.08.31 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营第 0 期第 10 周作业