1. API网关的作用和定位
- 为对内外关键http服务提供统一的入口，并为集中提供安全，审计，监控，预警，风控构建基础脚手架
- 为对外接口调用提供反向代理
- 节约后端服务开发成本，减少上线风险
- 为服务熔断，灰度发布，线上测试提供简单方案
传统的服务架构
diagram-left.png
使用API网关后的服务架构
diagram-right.png
使用API 网关作为外部服务的反向代理
外部服务的反向代理.png
带来的好处：
- firewall统一对api网关服务器集群做策略，逻辑简单清晰，易于维护
- 对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本
- 两级控制，简单灵活，网络组先变更，运维做测试，成功后授权应用服务器访问。
- 出口审计，监控和报警
2. API网关在整体架构体系的位置
- 鉴于中枢和中央预定系统在生产环境中的位置和功能，API网关会作为中枢和中央预定系统的代理网关提供服务给华住内部渠道和外部合作伙伴
- 华住与外部对接同样需要一层代理来简化部署，减少安全策略的配置变更
API网关的定位2.png
3. tyk.io作为华住网关第一版的基准
选择tyk.io中间件作为API网关第一版的基准主要出于以下原因和目的：
- 轻量，但功能足够
- 结构简单，逻辑清晰
- 存储基于mongodb和redis，两者广泛应用于华住生产环境系统，有能力做好运维，以及在突发异常事件中有能力在较短事件内恢复。
- 性能足够 ，以下是官方benchmark
tyk-1-7-1-performance.png
blitz-2.png
4. tyk.io结构
full-tyk-stack.jpg
5. API网关第一期里程碑以及时间节点
| 任务 | 时间点 | 状态 |
|---|---|---|
| 技术选型与论证 | 2月 - 3月 | Ready |
| 测试环境部署 | 3月底 - 4月初 | |
| 确定性能基线 | 4月中 | |
| 安全评审 | 4月中 | |
| 高可用与灾难恢复评审 | 4月底 | |
| 预发布部署 | 5月初 | |
| 生产部署 | 5月中 | |
| H5 中枢1.0,2.0部分接口 pilot实验 | 5月底 | |
| H5完成切换 | ？ | |
| 官网完成切换 | ？ | |
| app完成切换 | ？ | |
| 出口服务切换 | ？ |
6. API网关第一期硬件需求
***三台中配centos 7虚机服务器 ***
tyk部署硬件-2.png
7. 风险点
- mongodb存储冷热备份与切换方案是否成熟
- 灾难恢复过程中的应急预案是否有效
- 线上服务灰度发布
- tyk使用go语言实现对现有二次研发能力的挑战
附录：
Change Log
| 日期 | 内容 | 作者 |
|---|---|---|
| 2016.3.17 | 第一版 | 陆贇 |
| 2016.3.26 | 修改第二节整体架构位置的图，增加对外服务反向代理示意图，修改里程碑 | 陆贇 |
