【设计模式 7】从公司的目前框架和API Gateway，谈谈对外观模式的理解

我，第一次用到外观模式，应该是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 ，特别好玩儿的一个东西！