本文主要描述：
面向对象的需求分析方法论
一. 需求举例
假设，你正在参与开发一个微服务。微服务通过 HTTP 协议暴露接口给其他系统调用，其实，其他系统通过 URL 来调用微服务的接口。
二. 对案例进行需求分析
针对鉴权这个功能的开发，我们该如何做需求分析？
1. 第一轮基础分析
最简单的解决方案就是，通过用户名 + 密码来做认证。
给每个允许访问我们服务的调用方，派发一个应用名（或者叫应用 ID、AppID）和一个对应的密码（或者叫秘钥）。调用方每次进行接口请求的时候，都携带自己的 AppID 和密码。微服务在接收到接口调用请求之后，会解析出 AppID 和密码，跟存储在微服务端的 AppID 和密码进行比对。如果一致，说明认证成功，则允许接口调用请求；否则，就拒绝接口调用请求。
2. 第二轮分析优化
因为密码是明文，暴露给了网络，所以是不安全的。
加密算法
那如果我们借助加密算法（比如 SHA），对密码进行加密之后，再传递到微服务端验证，是不是就可以了呢？
实际上，这样也是不安全的，因为加密之后的密码及 AppID，照样可以被未认证系统（或者说黑客）截获，未认证系统可以携带这个加密之后的密码以及对应的 AppID，伪装成已认证系统来访问我们的接口。这就是典型的“重放攻击”。
提出问题，然后再解决问题，是一个非常好的迭代优化方法。
借助 OAuth 的验证思路
调用方将请求接口的 URL 跟 AppID、密码拼接在一起，然后进行加密，生成一个 token。
调用方在进行接口请求的的时候，将这个 token 及 AppID，随 URL 一块传递给微服务端。微服务端接收到这些数据之后，根据 AppID 从数据库中取出对应的密码，并通过同样的 token 生成算法，生成另外一个 token。
用这个新生成的 token 跟调用方传递过来的 token 对比。如果一致，则允许接口调用请求；否则，就拒绝接口调用请求。
3. 第三轮分析优化
不过还是有重放攻击的可能，我们可以进一步优化 token 生成算法，引入一个随机变量，让每次接口请求生成的 token 都不一样。
我们可以选择时间戳作为随机变量。我们将 URL、AppID、密码、时间戳四者进行加密来生成 token。调用方在进行接口请求的时候，将 token、AppID、时间戳，随 URL 一并传递给微服务端。
微服务端在收到这些数据之后，会验证当前时间戳跟传递过来的时间戳，是否在一定的时间窗口内（比如一分钟）。如果超过一分钟，则判定 token 过期，拒绝接口请求。如果没有超过一分钟，则说明 token 没有过期，就再通过同样的 token 生成算法，在服务端生成新的 token，与调用方传递过来的 token 比对，看是否一致。如果一致，则允许接口调用请求；否则，就拒绝接口调用请求。
4. 第四轮分析优化
但仍然有重放攻击的可能
未认证系统可以在这一分钟的 token 失效窗口内，通过截获请求、重放请求，来调用我们的接口。
开发成本
不过，攻与防之间，本来就没有绝对的安全。我们能做的就是，尽量提高攻击的成本。这个方案虽然还有漏洞，但是实现起来足够简单，而且不会过度影响接口本身的性能（比如响应时间）。
权衡安全性、开发成本、对系统性能的影响，这个方案算是比较折中、比较合理的了。
其他细节
另外，如何在微服务端存储每个授权调用方的 AppID 和密码。
最容易想到的方案就是存储到数据库里，比如 MySQL。不过，开发像鉴权这样的非业务功能，最好不要与具体的第三方系统有过度的耦合。
针对 AppID 和密码的存储，我们最好能灵活地支持各种不同的存储方式，比如 ZooKeeper、本地配置文件、自研配置中心、MySQL、Redis 等。
我们不一定针对每种存储方式都去做代码实现，但起码要留有扩展点，保证系统有足够的灵活性和扩展性，能够在我们切换存储方式的时候，尽可能地减少代码的改动。
5. 最终确定需求
到此，需求已经足够细化和具体了。看如下描述
三. 小结
针对框架、类库、组件等非业务系统的开发，其中一个比较大的难点就是：
需求一般都比较抽象、模糊，需要你自己去挖掘，做合理取舍、权衡、假设，把抽象的问题具象化，最终产生清晰的、可落地的需求定义。
需求定义是否清晰、合理，直接影响了后续的设计、编码实现是否顺畅。所以，作为程序员，你一定不要只关心设计与实现，前期的需求分析同等重要。
需求分析的过程实际上是一个不断迭代优化的过程。我们不要试图一下就能给出一个完美的解决方案，而是先给出一个粗糙的、基础的方案，有一个迭代的基础，然后再慢慢优化，这样一个思考过程能让我们摆脱无从下手的窘境。
