微服务框架-基础框架

上面一篇文章对SpringBoot框架做了一下简单验证，在文中也写到SpringBoot重点还是在单个微服务模块的开发，已经对于微服务接口开放的便捷性上，而对于微服务基础架构和管控治理层面没有太多支持。

那什么叫微服务基础框架？

对于微服务基础框架可以看作是微服务治理架构的核心内容，包括了对微服务模块的全生命周期管理能力，这个能力包括了微服务网关APP，DevOps，Docker和云集成，安全，负载均衡，服务注册和发现等诸多能力。微服务基础框架确实不是简单的微服务网关，而是对整个微服务基础环境的支撑和管控。

对于微服务基础框架，建议参考InfoQ的一篇文章如下：

http://www.infoq.com/cn/articles/basis-frameworkto-implement-micro-service/

对于这篇文章的一些重点做如下一些说明：

1. 服务注册和发现

第一种方案为集中式LB方案，对刚开始实施微服务架构时候仍然建议采用该方案，特别是有负载均衡硬件设备如F5，Array等，在加上硬件本身的HA，不会在LB上出现任何性能问题和可靠性问题。

对于第二种进程内LB方案是趋势，当前微服务框架的主流方案，Netflix和Dubbo等均采用该方案，那这种时候服务注册库相当存粹，只是实时准确提供可用服务注册列表和地址信息即可，但是这种方案我们可看到一般不会对调用的日志流进行审计和跟踪。

第三种方案实际上是一种折中的方案，即在每个微服务节点都需要部署相对比较重的独立进程外LB模块，这种方案最大的问题仍然是在于整体基础架构体系偏重同时后续维护工作量大。

2. 服务前端路由-微服务网关

此处核心能力即使微服务网关，不仅仅是实现服务代理和前端路由，还需要实现安全，限流，监控等扩展能力。可以看到对整个微服务环境的治理管控，微服务网关会起到重要作用，具体摘录原文描述如下：

• 服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。
• 安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。
• 限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。
• 监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。
• 其它能力：实现线上引流，线上压测，线上调试(Surgical debugging)，金丝雀测试(Canary Testing)，数据中心双活(Active-Active HA)等高级功能。

要注意到在微服务架构里面的集群和负载功能其实有两层，第一层是在微服务网关上面的分布式集群部署，可以减轻单个API GateWay节点的并发访问压力；另外一个是在微服务模块上层的负载均衡部署，重点是实现在同一个微服务模块集群部署后能够进行负载均衡。

在讲第一点服务注册和发现的时候可以看到，对于LB是可以下沉到服务消费端的，那么在LB下移后对于微服务网关层的能力是否也可以完全下沉到微服务模块节点（不管是进程内部署还是进程外部署），以实现完全意义上的去中心化分布式架构？

我在下面这篇文章曾经谈到过去中心化的微服务网关构建思路，可以参考：

http://blog.sina.com.cn/s/blog_493a84550102wcmw.html

3. 服务容错

该部分 主要还是讲服务的限流和流量控制机制，而对于熔断只是在发现问题和异常后所采用的操作。对于服务容错功能本身功能的重要性就在于，在复杂的微服务架构环境下，服务关联和依赖相当多，当发生大量的服务异常调用的时候，极其容易引起雪崩效应，导致整个微服务环境完全崩溃。

对于服务的容错，在考虑限流机制前，还可以考虑对服务进行分域，将不同域的服务单独部署到不同的JVM容器中，这样至少可以保证在A域的JVM完全崩溃的时候，不会影响到B，C等其它服务部署域。这个有点类似文章最佳实践谈到的 舱壁隔离模式(Bulkhead Isolation Pattern)。

要实现服务的容错管理i，首先要有实时的采集和统计服务运行数据，包括服务运行时间，次数等，这些是服务容错，限流或容错策略计算的基础。

对于服务容错需要分几个层面来谈：

首先来说是服务限流，即当出现超出预设的大并发服务调用的时候，直接在网关处控制服务的流入速度，即让消费方调用在外面等待和排队，然后慢慢的放进来，当然如果调用再大则会引起服务调用超时。注意这是服务消费方调用超时，而不是原始服务提供方，这种超时网关是不清楚的。

其次即开始不限流，服务全部放进来，但是服务提供方可能处理不过来大并发，这种情况下会出现服务超时调用，服务响应时间超过预设值，那么在这种情况下就启动服务限流，控制流入速度。注意在服务限流后可能仍然无法解决服务超时或响应慢的问题。那么这个时候就必须进行服务熔断处理，即禁止对该服务所有访问。对于文中也谈到了熔断的弹性恢复机制，这也是一个相当关键的内容。

对于服务流量控制本身也有多个层级，可以针对所有服务，一个域的所有服务，单个服务都可以。即对服务调用总量或单个服务并发量都能够进行灵活的限流规则定义，以确保整个微服务架构基础环境的稳定性。

Netflix将上述容错模式和最佳实践集成到一个称为Hystrix的开源组件中，凡是需要容错的依赖点(服务，缓存，数据库访问等)，开发人员只需要将调用封装在Hystrix Command里头，则相关调用就自动置于Hystrix的弹性容错保护之下。Hystrix组件已经在Netflix经过多年运维验证，是Netflix微服务平台稳定性和弹性的基石，正逐渐被社区接受为标准容错组件。

4.Netflix的微服务框架

在原来谈SOA和ESB的时候，我们一般会谈两个内容，即ESB服务总线和基于ESB总线的SOA管控和治理平台。而对应到微服务框架也一样的道理：

其一是：微服务网关(服务注册发现，代理路由，安全，限流，日志，监控）
其二是：基于微服务网关的完整微服务框架（客户端和服务端集成，DevOps，云集成）

注意在这里我还是将服务注册发现，日志等能力统一划归到一个完整的微服务网关应该具备的能力，虽然在实现中可能会分为多个子系统或组件，但是本身是属于GateWay应该具备的能力。

Netflix是一家成功实践微服务架构的互联网公司，几年前，Netflix就把它的几乎整个微服务框架栈开源贡献给了社区，这些框架和组件包括：

• Eureka:　服务注册发现框架
• Zuul:　服务网关
• Karyon:　服务端框架
• Ribbon:　客户端框架
• Hystrix: 服务容错组件
• Archaius: 服务配置组件
• Servo: Metrics组件
• Blitz4j: 日志组件

下图Fig 11展示了基于这些组件构建的一个微服务框架体系，来自recipes-rss。



Netflix的开源框架组件已经在Netflix的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal去年推出的Spring Cloud开源产品，主要是基于对Netflix开源组件的进一步封装，方便Spring开发人员构建微服务基础框架。

对于一些打算构建微服务框架体系的公司来说，充分利用或参考借鉴Netflix的开源微服务组件(或Spring Cloud)，在此基础上进行必要的企业定制，无疑是通向微服务架构的捷径。

另外推荐下作者的另外一篇文章：每个架构师都应该了解下康威定律
http://www.infoq.com/cn/articles/every-architect-should-study-conway-law