浅说API网关与微服务框架(上)——单身程序媛MM拯救计划
近期工作需要，研究了一下API网关与微服务框架。
对于没有做过开发的同学，或者是脱离一线JAVA/Go/Python等互联网时代开发时间较长的同学而言，这两个概念本身就很难理解，也很容易混淆。因此，我们在这里试图正本清源，帮助自己 ，也帮助大家弄清楚这两个基本概念。
首先让我们来理解一下API网关的概念。
让我们举一个栗子。
P公司开发了一个报销系统，域名为: sse.p***hub.com
报销系统需要关联这些信息：
1、报销人所在的部门、部门主管及秘书，用于报销单初审；
2、报销单所关联的出差流程，用于确定相关的出差补助天数；
3、报销单所关联的产品或市场项目，用于分摊费用；
而这些信息所在的系统分别为：
员工信息查询，API为
hr.p***hub.com/query.aspx?employeeid=员工ID
出差流程查询，API为
travel.p***hub.com/query.aspx?businesstravelid=出差流程ID
财务编码查询，API为
finance.p***hub.com/query.aspx?productid=产品ID
finance.p***hub.com/query.aspx?mktprojectid=市场项目ID
我们发现，开发报销系统，会涉及到3个域名和4个API接口。那么，这些因素中的任意一个发生变化，都会导致需要重新修改报销系统的代码，并重新构建版本，进行测试后发布！
程序媛MM：发际线疯狂后移……
让我们分析程序媛MM痛苦的根因：
为什么痛苦？因为没对象。
为什么没对象？因为头发掉太厉害。
为什么头发掉太厉害？因为老加班。
为什么老加班？因为要改版本验证。
为什么要改版本验证？因为依赖的API改了。
有没有办法让API不改？
——我们还是讨论世界和平的问题吧……
原来，虽然企业可以通过部署iaas云计算等方式，让各个应用系统共享计算/存储/网络/安全等ICT资源，但由于各个应用系统本身之间是烟囱式的，彼此之间的数据互联互通存在鸿沟——
IaaS资源统一分配，其他软件各自为政
有没有一种机制，能统一企业内部API接口，让程序媛MM不需要为这些复杂的API消耗心血呢？
API网关就是这种机制。
假设P公司引入了API网关以后，将API网关作为企业内部系统API的统一接口。所有的查询操作在
apigw.p***hub.com/query.aspx
进行，输入参数method决定了查询的内容，而下一个参数为查询键值。
API网关根据method的不同，去实际对应的业务系统里面查询数据。这样一来，实际上是对各个业务系统的API做了一层统一的封装。
API网关对实际业务系统的API进行封装，对调用者统一接口
这样，当某个系统的接口或域名修改了以后，只需要在API网关上进行对应的变更即可，不需要其他对接的业务应用修改代码了，程序媛MM减轻了工作量，不会老掉头发，也就能找到对象啦！
当然，API网关的功能还有许多。
让我们举一个栗子。
有一天，从报销系统和其他系统去往finance.p***hub.com的查询量过大，导致服务器忙不过来，出现了http 504错误(前端nginx无法和后端tomcat连接，一般是tomcat挂掉了)。此时，有个5个亿的投标需要在finance.p***hub.com上进行利润测算和申请价格。
可想而知，程序媛MM要面对的是什么……
有没有办法把程序媛MM从解决性能问题的深渊中拯救出来呢？
请看下期。