架构师训练营第 0 期第 10 周作业
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、服务注册与发现主要流程
【服务提供者应用程序】启动后,通过【服务管理容器】向【注册中心】注册提供服务器的基本信息,包括服务名称,服务协议,IP地址(host)、端口等信息;
【服务消费者程序】启动后,通过【服务框架客户端】,从【注册中心】获取到【服务提供者列表】,并将【服务提供者列表】缓存在【消费者服务器本地】;
如果【服务提供者】的机器发生【扩容】或者【缩容】,【服务提供者】将更改的机器信息同步给【注册中心】;
【注册中心】监听到【服务提供者】的机器信息,通知【服务消费者】更新本地的【服务提供者列表】;
1-4-1-2、服务暴露时序图(类级别)
1-4-2、服务调用
服务调用主要流程:
【服务消费者程序】调用【服务提供者】提供的【服务接口】,【接口访问代理】将方法和参数信息传给【服务框架客户端】;
【服务框架客户端】从本地【服务提供者列表】获取服务端机器信息;
再根据【负载均衡策略】选择远程调用的服务器;
将服务端机器、请求的方法 和 参数 通过【远程通讯模块】将请求发送到【服务提供者】的机器;
【服务提供者】的【远程通讯模块】接收到请求,创建【服务调用线程】,将请求发给具体的实现类处理;
处理完成后,将返回结果通过【远程通讯模块】返回给【服务消费者】;
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、中台架构
对于中台架构,微服务化只是实现业务中台在技术架构层面的一种手段,中台要实现的目标,包括:
消除企业重复建设,提高内部效能;
促进企业内部业务创新;
沉淀能力,对外开放,构建生态;
而业务中台与微服务解决的是不同的问题,业务中台解决的是企业级能力复用的问题,微服务解决的是“组件编译时依赖”的问题;
版权声明: 本文为 InfoQ 作者【Arthur】的原创文章。
原文链接:【http://xie.infoq.cn/article/4500d1b8b8a9a172a01e12079】。未经作者许可,禁止转载。
评论