场景：
由一次大的项目改动引起的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的步伐
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": false25 },26 "v2": {27 "Host": "",28 "Port": "",29 "Deprecated": false30 }31 }32 33 }34 35 }services.json【出处：滨海网站建设 http://www.1234xp.com/binhai.html 复制请保留原URL】