写点什么

架构师课程第十周 作业

用户头像
杉松壁
关注
发布于: 2020 年 08 月 09 日
一、根据微服务Dubbo的架构图,画出Dubbo进行一次微服务调用的时序图。
二、关于微服务架构(中台架构、领域驱动设计、组件设计原则),你有什么样的思考和认识?

不管什么架构设计、我觉得都要结合公司的体系、业务特点进行整合,马克思主义还需要与中国的实际情况结合才能发挥作用,否则反而害了自己。微服务架构是公司业务发展的产物,而不是因为技术厉害才出现的,所以不能算是技术驱动。微服务主要解决的是应用部署、维护、管理、迭代快等企业痛点,如果使用微服务能解决自己的问题,就是好的服务。微服务的一些特点,比如流量管理、链路追踪、安全防护、负载均衡等,也是公司实践的结果,并不一定满足所有企业的需求,可以根据自己的需求增加或者减少一部分功能,要知道,任何东西都是有利弊两面的,我们要做的是扩大有利的一面,尽量减少有弊的一面。灵活使用微服务,才能给自己带来更大的好处。当然,现在的微服务框架,已经能满足大部分公司的需求了。

领域驱动设计感觉和之前介绍的应用拆分并没有本质上的区别,只是将应用拆分从业务需求角度考虑,一切还是为了高内聚、低耦合的设计思路。领域驱动设计也不是什么新技术,或许很多公司一开始就是这样开展业务的,只不过是有人将这种思路进行了抽象,形成了一个所谓的技术、体系。很多时候也不需要刻意追求,适合的才是最好的。但从自身发展的角度来说,如果能参与到这样的实践中,对自己的发展与人生是有好处的。况且,人大部分都是喜新厌旧的,领导也是,他们出去也有了吹牛的本钱,也有了优越感,这就是现实,很多的无奈也源于此。

三、总结

本周的主要内容有:微服务介绍、dubbo微服务框架实现、Service Mesh服务网格、RPC协议原理、微服务网关、DDD、系统中台。

微服务是近些年比较热门的一个概念,也是互联网企业在发展中遇到困难、解决困难而兴起的一种技术框架。微服务主要指将单体应用进行适当拆分,各自独立开发维护管理,从而达到高效开发、快速迭代、清晰管理等目的。传统的单体应用随着业务发展,功能越来越多、模块越来越多、代码越来越多、部署越来越慢、排错越来越难,最终人们发现应用编译、部署困难、代码分支管理困难、数据库连接耗尽、新增业务困难。于是又到聪明的架构师们发挥作用的时候,将单体应用拆分成多个相互通信的小应用,这些应用称为微服务。所以微服务本质上是业务发展的需求,至于微服务中最重要的点在于怎么拆分,则需要不同的公司根据自己的业务与管理进行评估。但拆分之后的微服务,应该可以解决上述单体应用的几个问题。除了这些,微服务框架还需要实现的功能:失效转移、负载均衡、高效的远程通信、对应用最少侵入、版本管理等。

阿里开源的微服务框架Dubbo,实现了微服务的主要功能,便于开发者高效的开发微服务应用。服务提供者在启动之后会向注册中心注册自己,由注册中心管理各微服务的提供者。应用不用感知调用的服务是本地还是远程,有Dubbo客户端实现。消费者程序只要调用服务接口即可。Dubbo客户端会请求注册中心拿到服务端的信息,由于可能会有多个服务提供者,因此客户端还要使用负载均衡策略决定一个服务提供者,然后与之建立连接,请求服务。在接收到远端服务的响应之后,Dubbo客户端再将结果反序列化成对象交给应用处理。

Service Mesh服务网格旨在将微服务框架中本该有SDK实现的功能解耦到一个单独的服务中,这样可以减轻应用的负担,并且减少程序语言的依赖。服务网格一般会实现流量管理、故障注入、熔断、安全管理、协议转化、链路跟踪等功能,这样就大大减少了对应用的注入、解耦了语言之间的依赖。服务网格一般使用sidecar的方式拦截应用流量,因此需要一定的服务器资源,服务响应增加一定的延时,并且sidecar也会成为一个比较致命的故障点。因此,是否要使用服务网格,还需要公司自己评估这中间的利弊、性价比等等。

RPC协议(Remote Procedure Call),远程过程调用,是微服务框架实现远程调用的协议。主要可以使用TCP、UDP高效传输二进制或文本,为微服务之间的调用提供高效、可靠的网络通信。

基于网关的微服务架构,网关实现统一接入、安全防护、协议适配、流量管控与容错等功能。网关成为客户端与服务端之间的代理、入口,有网关决定协议转换,向服务端发出请求,可以帮助后端的多种微服务框架协议提供统一的入口、统一的接入标准。网关本身没有业务,主要职责是做各种校验与拦截,这些职责可以通过管道技术连接起来。

DDD(Domain-Driven Design),领域驱动设计,也是新兴的服务架构,从业务端考虑,将业务系统拆分为放到一个领域、子领域中,提供统一的服务,解决了功能开发混乱与调用关系复杂等问题。领域驱动设计从业务层面出发,将某一界限之内的功能模块对象集成到一个领域中,统一提供服务。

在实际项目开发过程中存在一些问题:

1. 用户或产品经理的需求零零散散,不断变更;

2. 工程师在各处代码中寻找可以实现这些需求的代码,修修补补;

3. 软件只有需求分析,没有真正的设计,系统没有一个统一的领域模型维持其内在的逻辑一致性;

4. 功能特性并不是按照领域模型内在的逻辑设计,而是按照各色人等各自的想象设计。

项目时间一长,各种困难重重,项目bug不断,需求不断延期。

领域是一个组织所做的事情以及其所包含的一切,通俗的讲,就是组织的业务范围和做事方式,也是软件开发的目标范围。领域驱动设计就是从领域出发,分析领域内模型及其关系,进而设计软件系统的方法。由于领域范围太大,所以通常将整个领域拆分成多个子领域,比如用户、商品、订单、库存、物流、发票等。如何划分子领域至关重要。在一个子领域中,会创建一个概念上的领域边界,在这个边界中,任何领域对象都只表示特定于边界内部的确切含义。这样边界便称为限界上下文。限界上下文和子领域具有一对一的关系,用来控制子领域的边界。通常限界上下文对应一个组件或者一个模块,或者一个微服务。不同的界限上下文,也即是不同的子系统或者模块之间会有各种的交互合作。DDD使用上下文映射图来设计这种交互。DDD分为战略设计与战术设计。领域、子领域、界限上下文、上下文映射图是战略设计,实体、聚合、CQRS、时间溯源是战术设计。通过战略设计,划分模块和服务的边界及依赖关系,对微服务架构的设计至关重要。

     企业系统中台其实并不是一种技术,而是服务的整合。为了提供统一的服务与规范,将一些基础的调用接口以中台的形式提供给客户调用。



用户头像

杉松壁

关注

还未添加个人签名 2018.03.30 加入

还未添加个人简介

评论

发布
暂无评论
架构师课程第十周 作业