我们如何选择mock方案

1.背景：我们为什么需一个mock方案？

1. 我们需要对外提供稳定可靠的对外联调&测试环境，同时我们作为平台（或者叫前台）应用，会依赖大量的业务应用。当某些业务应用不可用的时候，会相应导致我们的业务不可用。同时依赖服务中，一些服务没有稳定可靠的使用环境，我们要提供一个解决方案，来保证我们环境的可用和稳定。

2.可选方案

1. 提出需求，让我们的同志团队，为我们的服务来部署一套专门由我们团队使用的环境，独自使用下相应的稳定性也会更好。这个方案就需要考虑我们自己服务的优先级，因为搭建相应的环境需要申请额外的资源，由于只给我们使用，那么也会造成一定程度上资源的浪费，而且同志团队要维护相应的环境，也需要一部分人力资源，需要去考虑相应的成本，考虑此方案的推进难度。这种方案也是有优点的，可以最大程度模拟相应的环境，去覆盖更多的case。

2. 我们自已来提供一个mock环境，既可以对接提供接口级别的mock,也可以对内，模拟对其他业务应用请求的mock，这种方案可以在保证我们服务可用性的同时，减少对其他服务的上下游依赖。对于这种方案，case的覆盖程度就取决于我们对业务的理解，以及对mock场景的准备情况。同时，对于我们自己而言，如果没有适合我们的mock平台，是需要我们自己设计和开发的，需要评估合理的工作量。

结论:综合评估下来，还是第二种方案的可行性高，不可控变量也更少。

3.mock 方案的选择

适合你的才是最好的！

1. 我们需要什么样的解决方案呢？我们对外提供服务时，是http请求；请求依赖服务时，http协议和dubbo协议都有使用。所以我们要同时解决对http请求的mock和dubbo请求的mock。

2. 在了解我们技术团队已有的方案以后，发现有两个不满足我们使用的地方：
   一、只能做到服务级别的mock，不能做到接口级别的mock.
   二、只能做http协议的mock,不能做dubbo协议的mock.

3. 所以我们决定自己做一个能满足我们使用的mock方案。

4. 思考

1. 我们要做的方案，要满足我们的两大基本诉求：
   一、支持接口级别的mock
   二、同时支持http和dubbo请求的mock

2. 我们可能还可能需要满足的：
   一、小而美，尽量少的占用额外的服务器节点和数据库资源
   二、后续持续升级和迭代
   三、最好具有普适性，其他服务有相同诉求时，也可以快速接入
   四、结合三，要让接入方便快捷，低耦合，不侵入或者少侵入

5.to be continued