wcf - wechat forwarder
如其名，就是一个简单的转发者，也可以认为它是一个 http proxy，所以对于 https 的应用，它暂时就无能为力了。
微信开放了其公众号的接口，使之公众号的持有者可以定制自己的服务。如果需要定制自己的 服务，那么至少需要有一个自己的应用，通过微信开放的接口使自己的应用与微信服务器交互。
为了简单，下面简称微信服务器为 WS(wechat server)，简称自己的应用为 MS(my server)，如果 多个自己的应用，那么我们就沿用一个 MS1,MS2,MS3... 的规律来简称它们。
稍有将现有系统与微信对接之经验的开发者，都会注意到微信与服务器之间的交互主要分两种(主语都是 MS):
- 被动响应，简称 P
- 主动请求，简称 A
并且在对接的时候，会遇到一个情况，微信后台管理页面只能配置一个 MS，如果我们有多个 MS 的话，情况就有点棘手。
比如我们有 MS1，MS2，MS3，它们中任意一个在微信后台配置了之后都是可以独立使用的，现在我们需要将它们三个同时用于一个公众号。 首先我们知道微信后台是只能同时配置一个应用的，那么现在我们配置了 MS1，接下来就是考虑 MS2，MS3 怎么办。
之前说到，WS 和 MS 交互的形式分为两种的(P/A)，对于 A 来说没有问题 - MS1，MS2，MS3 都可以主动的请求微信服务器。只是对于 P 需要有点思考:
- 将 MS2，MS3 的功能在 MS1 中重新实现一遍 😱
- 在 MS1 中接收微信消息的部分，将微信消息对 MS2, MS3 进行转发，并将 MS2, MS3 的返回结果转发给微信
☺️ - 有一个 MS4，我们在微信后台配置 MS4。MS4 本身只做一件事，就是转发微信来的消息给 MS1,MS2,MS3，并将它们的结果转发给微信服务器 😃
显而易见
- 方法1是最浪费时间人力的。
- 方法2就好多啦，不过我们还是要对 MS1 进行修改，这样 MS1 就不完整啦，它本身是一个独立的应用并且已经工作的很好呢。
- 方法3，是目前最好的，不是吗? MS1~4 它们之间各司其职，相处融洽。
于是 wcf 就这么出来了，它的角色就是 MS4