【面向对象】开发原则（三）：如何使用面向对象的思想来实现一个功能？

ゝ一纸荒年。 2023-01-14 01:58 77阅读 0赞

为了保证接口调用的安全性，我们希望设计实现一个接口调用鉴权功能，只有经过认证之后的系统才能调用我们的接口，没有认证过的系统调用我们的接口会被拒绝

## 1.面向对象分析（做什么） ##

### 1.1 第一轮需求分析 ###

对于如何做鉴权这样一个问题，最简单的解决方案就是，通过用户名加密码来做认证。

我们给每个允许访问我们服务的调用方，派发一个应用名（或者叫应用 ID、AppID）和一个对应的密码（或者叫秘钥）。调用方每次进行接口请求的时候，都携带自己的 AppID 和密码。

微服务在接收到接口调用请求之后，会解析出 AppID 和密码，跟存储在微服务端的 AppID 和密码进行比对。如果一致，说明认证成功，则允许接口调用请求；否则，就拒绝接口调用请求。

### 1.2 第二轮分析优化 ###

1）当前问题

这样的验证方式，每次都要明文传输密码。密码很容易被截获，是不安全的。

那如果我们借助加密算法（比如 SHA），对密码进行加密之后，再传递到微服务端验证，是不是就可以了呢？

实际上，这样也是不安全的，因为加密之后的密码及 AppID，照样可以被未认证系统（或者说黑客）截获，未认证系统可以携带这个加密之后的密码以及对应的 AppID，伪装成已认证系统来访问我们的接口。这就是典型的“**重放攻击**”。

2）解决方案

对于刚刚这个问题，我们可以借助 OAuth 的验证思路来解决。

调用方将请求接口的 URL 跟 AppID、密码拼接在一起， 然后进行加密，生成一个 token。调用方在进行接口请求的的时候，将这个 token 及 AppID，随 URL 一块传递给微服务端。

微服务端接收到这些数据之后，根据 AppID 从数据库中取出对应的密码，并通过同样的 token 生成算法，生成另外一个 token。用这个新生成的 token 跟调用方传递过来的 token 对比。如果一致，则允许接口调用请求；否则， 就拒绝接口调用请求。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center][]

### 1.3 第三轮分析优化 ###

1）当前问题

这样的设计仍然存在重放攻击的风险，还是不够安全。每个 URL 拼接上 AppID、密码生成的 token 都是固定的。未认证系统截获 URL、token 和 AppID 之后，还是可以通过重放攻击的方式，伪装成认证系统，调用这个 URL 对应的接口。

2）解决方案

解决这个问题，我们可以进一步优化 token 生成算法，引入一个随机变量，让每次接口请求生成的 token 都不一样。我们可以选择时间戳作为随机变量。原来的 token 是对 URL、AppID、密码三者进行加密生成的，现在我们将 URL、AppID、密码、时间戳四者进行加密来生成 token。调用方在进行接口请求的时候，将 token、AppID、时间戳，随 URL 一并传递给微服务端。

微服务端在收到这些数据之后，会验证当前时间戳跟传递过来的时间戳，是否在一定的时间窗口内（比如一分钟）。如果超过一分钟，则判定 token 过期，拒绝接口请求。如果没有超过一分钟，则说明 token 没有过期，就再通过同样的 token 生成算法，在服务端生成新的 token，与调用方传递过来的 token 比对，看是否一致。如果一致，则允许接口调用请 求；否则，就拒绝接口调用请求。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1][]

### 1.4 第四轮分析优化 ###

1）当前问题

不过，你可能会说，这样还是不够安全啊。未认证系统还是可以在这一分钟的 token 失效 窗口内，通过截获请求、重放请求，来调用我们的接口啊！

你说得没错。不过，攻与防之间，本来就没有绝对的安全。我们能做的就是，尽量提高攻击的成本。这个方案虽然还有漏洞，但是实现起来足够简单，而且不会过度影响接口本身的性能（比如响应时间）。

所以，权衡安全性、开发成本、对系统性能的影响，这个方案算是比较折中、比较合理的了。实际上，还有一个细节我们没有考虑到，那就是，**如何在微服务端存储每个授权调用方的 AppID 和密码？**。当然，这个问题并不难。

2）解决方案

最容易想到的方案就是存储到数据库里，比如 MySQL。不过，开发像鉴权这样的非业务功能，最好不要与具体的第三方系统有过度的耦合。

针对 AppID 和密码的存储，我们最好能灵活地支持各种不同的存储方式，比如 ZooKeeper、本地配置文件、自研配置中心、MySQL、Redis 等。我们不一定针对每种存储方式都去做代码实现，但起码要留有扩展点，保证系统有足够的灵活性和扩展性，能够在我们切换存储方式的时候，尽可能地减少代码的改动。

### 1.5 最终方案 ###

1）调用方

进行接口请求的时候，将 URL、AppID、密码、时间戳拼接在一起，通过加密算 法生成 token，并且将 token、AppID、时间戳拼接在 URL 中，一并发送到微服务端。

2）微服务端

在接收到调用方的接口请求之后，从请求中拆解出 token、AppID、时间戳。

微服务端首先检查传递过来的时间戳跟当前时间，是否在 token 失效时间窗口内。如果已经超过失效时间，那就算接口调用鉴权失败，拒绝接口调用请求。

如果 token 验证没有过期失效，微服务端再从自己的存储中，取出 AppID 对应的密 码，通过同样的 token 生成算法，生成另外一个 token，与调用方传递过来的 token 进 行匹配；如果一致，则鉴权成功，允许接口调用，否则就拒绝接口调用。

## 2.面向对象设计（怎么做） ##

### 2.1 划分职责进而识别出有哪些类 ###

1.把 URL、AppID、密码、时间戳拼接为一个字符串
    2.对字符串通过加密算法加密生成 token；
    3.将 token、AppID、时间戳拼接到 URL 中，形成新的 URL；
    4.解析 URL，得到 token、AppID、时间戳等信息；
    5.从存储中取出 AppID 和对应的密码；
    6.根据时间戳判断 token 是否过期失效；
    7.验证两个 token 是否匹配；

*  **AuthToken**：1、2、6、7 都是跟 token 有关，负责 token 的生成、 验证；
 *  **Url**：3、4 都是在处理 URL，负责 URL 的拼接、解析；
 *  **CredentialStorage**：是操作 AppID 和密码，负责从存储中读取 AppID 和密码。

当然，这是一个初步的类的划分，其他一些不重要的、边边角角的类，我们可能暂时没法一下子想全，但这也没关系，面向对象分析、设计、编程本来就是一个循环迭代、不断优化的过程。根据需求，我们先给出一个粗糙版本的设计方案，然后基于这样一个基础，再去迭代 优化，会更加容易一些，思路也会更加清晰一些。

> PS：不过，这里还要再强调一点，接口调用鉴权这个开发需求比较简单，所以，需求对应的面向对象设计并不复杂，识别出来的类也并不多。但如果我们面对的是更加大型的软件开发、更加复杂的需求开发，涉及的功能点可能会很多，对应的类也会比较多，像刚刚那样根据需求逐 句罗列功能点的方法，后会得到一个长长的列表，就会有点凌乱、没有规律。  
>   
> 针对这种复杂的需求开发，我们首先要做的是进行模块划分，将需求先简单划分成几个小的、独立的功能模块，然后再在模块内部，应用我们刚刚讲的方法，进行面向对象设计。而模块的划分和 识别，跟类的划分和识别，是类似的套路。

### 2.2 定义类及其属性和方法 ###

刚刚我们通过分析需求描述，识别出了三个核心的类，它们分别是 AuthToken、Url 和 CredentialStorage。现在我们来看下，每个类都有哪些属性和方法。我们还是从功能点列 表中挖掘。

1）AuthToken 类相关功能点有四个

*  把 URL、AppID、密码、时间戳拼接为一个字符串；
 *  对字符串通过加密算法加密生成 token；
 *  根据时间戳判断 token 是否过期失效；
 *  验证两个 token 是否匹配  
    ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2][]

第一个细节：并不是所有出现的名词都被定义为类的属性，比如 URL、AppID、密码、 时间戳这几个名词，我们把它作为了方法的参数。

从业务模型上来说，\*\*不应该属于这个类的属性和方法，不应该被放到这个类里。比如 URL、AppID 这些信息，从业务模型上来说，不应该属于 AuthToken， 所以我们不应该放到这个类中。

第二个细节：我们还需要挖掘一些没有出现在功能点描述中属性，比如 createTime， expireTimeInterval，它们用在 isExpired() 函数中，用来判定 token 是否过期。

第三个细节：我们还给 AuthToken 类添加了一个功能点描述中没有提到的方法 getToken()。

第二、第三个细节告诉我们，在设计类具有哪些属性和方法的时候，不能单纯地依赖当下的 需求，还要分析这个类从业务模型上来讲，理应具有哪些属性和方法。这样可以一方面保证 类定义的完整性，另一方面不仅为当下的需求还为未来的需求做些准备。

2）Url 类相关功能点有两个

*  将 token、AppID、时间戳拼接到 URL 中，形成新的 URL
 *  解析 URL，得到 token、AppID、时间戳等信息

虽然需求描述中，我们都是以 URL 来代指接口请求，但是，接口请求并不一定是以 URL 的形式来表达，还有可能是 dubbo RPC 等其他形式。为了让这个类更加通用，命名更加贴切，我们接下来把它命名为 ApiRequest。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 3][]

3）CredentialStorage 功能点一个

*  从存储中取出 AppID 和对应的密码

CredentialStorage 类非常简单，类图如下所示。为了做到抽象封装具体的存储方式，我们将 CredentialStorage 设计成了接口，基于接口而非具体的实现编程。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 4][]

### 2.3 定义类与类之间的交互关系 ###

因为目前只有三个核心的类，所以只用到了实现关系，也即 CredentialStorage 和 MysqlCredentialStorage 之间的关系。

### 2.4 将类组装起来并提供执行入口 ###

类定义好了，类之间必要的交互关系也设计好了，接下来我们要将所有的类组装在一起，提供一个执行入口。这个入口可能是一个 main() 函数，也可能是一组给外部用的 API 接口。 通过这个入口，我们能触发整个代码跑起来。

接口鉴权并不是一个独立运行的系统，而是一个集成在系统上运行的组件，所以，我们封装所有的实现细节，设计了一个顶层的 ApiAuthencator 接口类，暴露一组给外部调用者 使用的 API 接口，作为触发执行鉴权逻辑的入口。具体的类的设计如下所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 5][]

## 3.面向对象编程（语言实现） ##

面向对象设计完成之后，我们已经定义清晰了类、属性、方法、类之间的交互，并且将所有 的类组装起来，提供了统一的执行入口。

接下来，面向对象编程的工作，就是将这些设计思 路翻译成代码实现。有了前面的类图，这部分工作相对来说就比较简单了。所以，这里只给出比较复杂的 ApiAuthencator 的实现。

public interface ApiAuthencator {
         
        void auth(String url); 
        void auth(ApiRequest apiRequest);
    }
    public class DefaultApiAuthencatorImpl implements ApiAuthencator {
          
        private CredentialStorage credentialStorage;   
        public ApiAuthencator() {
           
            this.credentialStorage = new MysqlCredentialStorage();  
        }    
        public ApiAuthencator(CredentialStorage credentialStorage) {
         
            this.credentialStorage = credentialStorage; 
        }
      	@Override  
        public void auth(String url) {
           
            ApiRequest apiRequest = ApiRequest.buildFromUrl(url);  
            auth(apiRequest); 
        }
      	@Override 
        public void auth(ApiRequest apiRequest) {
         
            String appId = apiRequest.getAppId();  
            String token = apiRequest.getToken();   
            long timestamp = apiRequest.getTimestamp(); 
            String originalUrl = apiRequest.getOriginalUrl();
            
        	AuthToken clientAuthToken = new AuthToken(token, timestamp);  
            if (clientAuthToken.isExpired()) {
            
                throw new RuntimeException("Token is expired."); 
            }
        	String password = credentialStorage.getPasswordByAppId(appId); 
            AuthToken serverAuthToken = AuthToken.generate(originalUrl, appId, password）
            if (!serverAuthToken.match(clientAuthToken)) {
             
                throw new RuntimeException("Token verfication failed.");
            }
        }
    }

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221022/255bb8a67b15417e82cefbedc3d1c6d1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221022/44a1ca27535b49778df1807f3f649557.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221022/fe2022a37c76422fa677e43145de0528.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221022/bd604bf525444db79a75a0354f45eb74.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221022/baba1d9f625b41d79a2de155d9525981.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221022/40cb8de6315c497095247eaff7550326.png