我,第一次用到外观模式,应该是3年多以前。那时候是做一个收费系统,在当时的U层和B层之间,加了一层Facade。当时,在一些复杂的业务逻辑处理时,感受到了加入外观层的好处,但对于一些简单的(我指的是,当时很多facade里面的方法都只是简单的返回了B层的方法执行结果)业务,总感觉是没有必要了。那么,外观模式,究竟可以发挥出多大的威力呢????

一、目前的框架

后来,在项目的开发中,用到的设计模式不算少。但外观的比例,却也真的没有那么大。那么最近呢,公司的框架,在service之上,再增加了一个facade层,将facade的接口服务注册到Dubbo中心,对外统一提供API服务。整个的设计师没有问题的,但是,对于架构组的说法,以及目前的用法,我谈一下我的思考(我认为自己对,但我不太确定,只是简单说一下我的看法)

首先,我先整体的说说项目中框架里的调用关系(哈哈,猜的没错,本宝宝要手绘图纸了。丑啊)

我先大概介绍一下。

1,关于事务,采取的是声明式事务,加到了service层,粒度是整个类!首先是我感觉整个类上都加上注释,统一为一样的默认配置,这种做法是有待考究的。因为我不认为每一个方法需要的事务行为都是一致的,再极端一点,我认为有些单表的单条数据操作,不需要事务! 而,我自己的想法是,因为我们统一对外的接口是facade层,所以,我认为是将事务控制到facade这层的方法。 而不再需要在service层加类事务注解,甚至是在基类baseservice上也加上事务管理。      但,当时跟我说的是,由于我们的facade接口对外实现,是通过Dubbo进行的,所以如果将事务注解到facade,可能会和Dubbo之间发生一些别的问题!(这一点,我还没有仔细研究过Dubbo的机制原理和协议,不太肯定和加事务到facade有没有什么冲突或者联系)


2,对于外观模式的作用。

引用自《大话设计模式》:外观模式(Facade):为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

外观模式的使用场景,三个阶段:首先,在设计初期阶段,应该要有意识的将不同的两个层分离;其次,在开发阶段,子系统往往因为不断的重构烟花而变得越来越复杂,增加外观facade可以提供一个简单的接口,减少他们之间的依赖;第三,在维护一个遗留的大型系统时,可能这个系统已经非常难以维护和扩展,为新系统开发一个外观类,来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口,让新系统与facade对象交互,facade与遗留代码交互所有复杂的工作。


而我们的这个系统,从严格意义上来说,也算是一个需要与旧系统实现打交道的,业务都比较成熟。在换新框架的时候,业务逻辑复用,但代码上的复用不多甚至没有。所以,从某种程度上来说,也算是一个新的系统。 简单类比到外观的使用场景,那么应该符合第二点。

先再看看外观的用途:


所以,我就认为当前的facade层只是简单的返回service的方法,那么增加这一层的意义不大。因为增加facade这一层,它并没有做到简化解耦当前项目中controller调用Dubbo服务接口的依赖,因为接口基本等同于service层!   (个人目前的拙见)

而且,外观模式,是一种结构型的设计模式。什么是结构型????

二、API Gateway

谈到外观模式,就联想到最近正在做,正在计划引入项目的API网关服务。在这里面,我就感受到了外观的精巧奇妙。嘿嘿(来张漂亮的图):


API 网关,事实上就相当于外观,客户端统一从API网关服务中调用服务,而API Gateway负责整合具体的服务。

看看API网关的优点(我认为很多就像是外观模式的优点)

1,使服务和客户端解耦。

2,使客户端和服务部署环境解耦。

3,提供了最佳的API给每个客户端。

4,减少的请求/往返次数。例如,API网关可以一次性检索多个服务的数据。更少的请求也意味着更少的开销,提高了用户体验。一个API网关对于移动应用至关重要。

5,简化了客户端的调用,因为API网关可以组合服务,并提供组合后的façade接口。

对于API Gateway这一段的说法,更详细的可以参考:

谷歌翻译版:微服务API Gateway    原文地址:Pattern: API Gateway / Backend for Front-End

三、总结

这次的总结,其实就两句话:

1,如无必要,勿增实体

2,已增实体,就必须发挥其最大功用(而且是好的用处)

第三点,算是对于自己的一个反思:我需要好好深入的学习一些东西,要做到从理论和实践都能具有强大的说服力。而且,在研究这段的过程中,发现自己对于理论的联系能力和辩驳能力都增强了很多,但是实践的速度太慢。比如,测试事务加到哪儿的那一块内容,测了好几个小时,才测完了加到不同地方,不同执行操作的影响。

我还可以做到更好,加油!  嘿嘿,整整API getaway ,特别好玩儿的一个东西!

posted on 2017-07-25 10:15  何红霞  阅读(294)  评论(0编辑  收藏  举报