asp.net core 实现 api网关进行 api版本控制

场景：

　　由一次大的项目改动引起的app端api不兼容问题，这时候就需要对api做版本控制了，权衡之后因为用户不多，选择了强更，没人想在已经写了8000行代码的单个svc文件中维护好几个版本的接口或者继续新建svc(wcf配置较繁琐)，但暴露出的版本控制问题还是要解决的，不能每次都强更呀。

api版本控制方案：

　　分项目进行版本控制，一个项目一个版本号，维护两个版本号，分开部署，根据其版本号路由到对应host。

　　根据当前项目情况，为了同时完成技术迭代(因没有code review，多次经手，wcf中基于http的api已经难以维护，并且使用的是.net fx4.0，各种不便，完全重构是不可能的)，所以新版本采用restful web api(本来想直接上.net core web api，成本...)。

　　关于api版本控制的其他几种方案不详述，网上很多文章，可以自己搜搜看，对比选用适合自己的方案。

rest风格的api版本控制

此时需要将老的wcf 和新web api管理起来了，做一个api网关再合适不过，不仅处理了版本控制的问题，后面还可扩展网关的其他职能，迈开了从单体过渡到SOA的步伐 asp.net core 实现 api网关进行 api版本控制

api网关方案：使用.net core web自实现(本来想使用Ocelot ，全套当然方便,因其版本控制基于url，我更倾向于rest基于http headers accept来控制，所以自己写吧)

api网关落地：

1.对服务的管理设计

　　建了一个json文件来配置对服务的管理，因其要保留网关其他职能的可能性，所以设计时要注意其扩展性，当然目前没做服务发现，所以需要这么一个设计来管理服务。

　　知道vnd啥意思吗？搜了半天才知道，自定义mime类型的前缀，当然在这里不是必须的，反正都是你自己约定解析的，当然对公还是遵循通用规范好一些。

　　rule里面是对请求的验证规则，顺便使用polly做了重试和超时。

 1 {
 2   "Rule": {
 3     "CORS": {
 4       "AllowOrigins": "",
 5       "AllowMethods": "GET,POST,PUT,DELETE",
 6       "AllowHeaders": "Accept,Content-Type"
 7     },
 8     "Headers": {
 9       "AcceptPrefix": "vnd.saas.services.",
10       "AcceptKey": "version",
11       "AcceptContentType": "json"
12     },
13     "API": {
14       "FilterAPI": "",
15       "APITimeOut": "60"
16     }
17 
18   },
19   "Services": {
20     "main": {
21       "v1": {
22         "Host": "",
23         "Port": "",
24         "Deprecated": false
25       },
26       "v2": {
27         "Host": "",
28         "Port": "",
29         "Deprecated": false
30       }
31     }
32 
33   }
34 
35 }

services.json