在上一期，我们提到了，API网关除了提供统一的API入口外，还可以利用服务限流与熔断等机制来保护服务的可用性，或者说，实现业务的QoS。
而微服务框架则是对API网关的增强。微服务本身是一个非常大的话题，展开可以写一本书。还是让我们用一个栗子来简单直接地让大家对微服务有基本的认知吧：
Rhino开发了一个交友APP，叫做“探陌”，一开始，探陌采用传统的Web-APP-DB前后端三层架构实现，但随着功能的不断迭代，Rhino发现了两个问题：
1、 探陌的代码不断膨胀，每次重新构建需要(也就是程序员们发呆)的时间越来越长；
2、 探陌一开始使用了JAVA语言开发，如果期望引入其他语言(如python，golang等)编写的开源组件几乎不可能；
因此，Rhino梳理了探陌的功能：
1、 编辑个人资料；
2、 发布自己的图片及语音；
3、 查看并按条件筛选附近的人；
4、 查看和搜索附近的人发表的内容；
5、 与关注的人文字、语音或视频聊天；
6、 保存并查找聊天记录；
并且对这6个功能使用的共同的组件进行了抽象化，将涉及的后端APP从一个运行在tomcat里面的单体java程序拆分为若干组件：
名称 | 功能 | 实现语言 |
|---|---|---|
user_search | 查看筛选附近的人 | golang |
chatting_txt | 发送接收聊天内容 | java |
chatting_mm | 语音视频等多媒体聊天 | java |
searching | 搜索 | java |
recording | 聊天记录保存 | Golang |
user_match | 用户匹配推荐 | python |
image | 图片显示与拉取 | node.js |
…… |
各个组件之间使用Rest API或gRPC进行通信。
我们发现，这样一来，不但让APP的设计遵循了“低耦合，高内聚“的原则，还可以让不同的组件用最适合的语言编写（如利用java开发的elasticsearch中间件快速实现搜索功能）
实际上，Rhino实现的就是将“探陌“这个APP进行了微服务化，上表中的各个组件就是所谓的微服务，从前APP进程内的各种调用，大部分演化为微服务之间的远程调用。
如前文所述，对于这种情况，使用API网关不但能够统一调用入口，减少了某组件修改API接口后，其他组件需要同步配合修改的工作量，还能够实现统一的鉴权、性能监控、性能告警和QoS。
然而，在微服务的时代，API网关的这些功能还不够。Rhino问方老师：为什么这么说呢？
方老师正在玩腾讯围棋，随手给Rhino分享了一个QQ音乐的链接，Rhino点开，是李上安的《孤独城市》。
……
看着一望无际心中的炽热
就在川流不息的城市困惑
你像节奏生活之下的空壳
疑惑 挥霍 疑惑 挥霍
你要的明天只是种平坦的生活
何必说被掏空幻想的寄托
抛弃了初心在违背意愿的生活
谁能快活 谁能快乐
……
Rhino猛然坐起，拍了拍自己的犀牛角，回忆起自己初恋的年代，那阳光下的白裙和黑长直……
“抛弃了初心在违背意愿的生活 谁能快活 谁能快乐“
Rhino明白了。
原来，将APP微服务化的初心，是因为原有的单体APP太过于重量级，任何修改都需要反复的验证测试，难以适应互联网时代敏捷迭代的需求。
应用微服务化以后，可以对其中一个组件做修改，其他组件无感知。在开发测试环境中做简单的测试后，在特定的条件下，就可以发布到生产环境了。
所谓的“特定的条件下“。实际上指的是，微服务的容器化部署！我们知道，容器是超轻量级的计算资源分配方案，能够将APP及所依赖的运行环境打包为镜像，剥离掉厚重的Guest OS，实现快速部署、快速弹性扩容、各种灰度方式发布迭代(蓝绿发布，滚动发布，金丝雀发布等)。
因此，微服务框架还需要支持负载均衡(将访问分发到各个微服务实例运行的容器)、服务注册发现(让迭代后的微服务能够自动化向微服务API网关更新注册变更后的API)、服务部署平台(发布机制和租户资源治理等)……这样才能更好地支撑运行在容器上，利用DevOps流水线开发的微服务化应用。
早期最流行的微服务框架是SpringCloud。SpringCloud的微服务注册中心叫Erueka Server，开发者可以利用Erueka Client实现微服务注册。由于并不是所有编程语言都有Erueka Client客户端的实现，使用SpringCloud事实上限制了编程语言的使用。
而Istio是另一类微服务框架。Istio在运行了微服务的容器上插入一个监听代理(sidecar)，利用Sidecar实现熔断、限流等功能。由于这种方式无需改动原有程序代码，被叫做非侵入式微服务框架。这也是未来微服务演变的趋势。
最后，让我们做一个小结：
由于基于传统IaaS开发部署的企业内部应用之间，中间件及数据层是割裂的，它们之间的API调用关系复杂，一个应用的API更新会影响其他应用的正常运行，因此，出现了API网关对应用API进行封装，为各个应用之间调用提供统一的入口；
对于各种应用逐渐复杂的情形，API网关可以提供QoS机制，如限流、熔断、性能监控等功能，保障关键应用的服务质量，还可以提供统一的认证鉴权保障应用的安全性；
当厚重的单体应用被拆分为容器化的微服务后，API网关进化为微服务框架。它除了提供API网关的API封装、QoS、统一鉴权认证等功能外，还可以实现API的自动化注册、负载均衡、性能监控与弹性伸缩、服务发布部署等功能。
由于以springcloud的侵入式微服务框架对开发者有特殊要求，甚至需要修改部分已有应用的程序代码，业界出现了以Istio为代表的非侵入式微服务框架，它向运行了微服务的容器pod上植入sidecar实现微服务框架的数据平面功能，这将是未来微服务的发展方向。
前期链接汇总：
浅说API网关与微服务框架(上)——单身程序媛MM拯救计划
浅说API网关与微服务框架(中)——爷青回！超级马里奥现身
好了，春节期间插播的特别节目告一段落，下期开始我们将进一步解密商用的分布式存储系统的一些内幕
有疑问的同学请先回答这个问题：
“原子跃迁会发出光子，这光子原本就在原子内部吗？”
