微服务框架-基础框架

标签: IT咨询 | 发表时间:2016-11-14 22:06 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
上面一篇文章对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

 

相关 [微服务 框架 基础] 推荐:

微服务框架-基础框架

- - 人月神话的BLOG
上面一篇文章对SpringBoot框架做了一下简单验证,在文中也写到SpringBoot重点还是在单个微服务模块的开发,已经对于微服务接口开放的便捷性上,而对于微服务基础架构和管控治理层面没有太多支持. 对于微服务基础框架可以看作是微服务治理架构的核心内容,包括了对微服务模块的全生命周期管理能力,这个能力包括了微服务网关APP,DevOps,Docker和云集成,安全,负载均衡,服务注册和发现等诸多能力.

[转]实施微服务,我们需要哪些基础框架?

- - 互联网 - ITeye博客
实施微服务,我们需要哪些基础框架. 作者  杨波 发布于 2015年12月1日 |. 微服务(MicroServices)架构是当前互联网业界的一个技术热点,圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设,他们都有相同的疑问:一个微服务架构有哪些技术关注点(technical concerns).

微服务架构的基础框架选择:Spring Cloud还是Dubbo?

- - 程序猿DD
最近一段时间不论互联网还是传统行业,凡是涉及信息技术范畴的圈子几乎都在讨论 微服务架构. 近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验,这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言,还是有不少激励的. 目前,Spring Cloud在国内的知名度并不高,在前阵子的求职过程中,与一些互联网公司的架构师、技术VP或者CTO在交流时,有些甚至还不知道该项目的存在.

微服务框架Spring Cloud介绍 Part2: Spring Cloud与微服务

- - skaka的博客
之前介绍过 微服务的概念与Finagle框架, 这个系列介绍Spring Cloud.. Spring Cloud还是一个相对较新的框架, 今年(2016)才推出1.0的release版本. 虽然Spring Cloud时间最短, 但是相比我之前用过的Dubbo和Finagle, Spring Cloud提供的功能最齐全..

微服务框架和工具大全

- - IT瘾-geek
引言:不去重新发明轮子总是更好的. 本文探讨了14个已经可用并能提供使微服务的开发和部署更容易的平台、框架和功能. 本文还补充了每个工具将如何有助于建立良好的微服务架构的简要概述.   在《Java微服务》一书中,我们使用 Spring Cloud,它提供使微服务非常容易地开发所需的所有工具和平台.

基础设施服务的微服务化

- - 午夜咖啡
这篇文章是根据我在SFDC(SegmentFault Developer Conference)大会上的分享整理而成. 今天我给大家分享的题目是『基础设施服务的微服务化』. 微服务这一两年非常火,今天的服务器端的分享主题应该至少90%和微服务相关. 同时你会发现,云,容器等技术的发展都是在给微服务铺路,因为用户本质上需要的是服务,不是资源.

微服务架构--服务框架,metrics 和调用链数据

- - 行业应用 - ITeye博客
微服务化以后,为了让业务开发人员专注于业. 务逻辑实现,避免冗余和重复劳动,规范研发. 提升效率,必然要将一些公共关注点推到框架. 服务框架 ( 图 9) 主要封装公共关注点. 服务注册、发现、负载均衡和健康检查,. 假定采用进程内 LB 方案,那么服务自注. 册一般统一做在服务器端框架中,健康检.

Spring框架学习【基础知识】

- - CSDN博客推荐文章
1.在java开发领域,Spring相对于EJB来说是一种轻量级的,非侵入性的Java开发框架,曾经有两本很畅销的书《Expert one-on-one J2EE Design and Development》和《Expert one-on-one J2EEdevelopment without EJB》是java高手进阶必看的宝典,Spring就是从这两本书的理论发展起来的.

一个成功的程序员,自然要懂微服务,汇总微服务架构的15钟框架!

- - 掘金后端
这几年来,微服务这个概念越来越火了,火到什么程度呢. 2019年有一个统计说,两千家企业里,45%在使用微服务,16%在实验开发和测试微服务架构,24%在学习微服务准备转型,只有剩下的15%的企业没有使用微服务. 微服务在2013年才被提出,短短几年就有这么快速的发展. 微服务架构能够实现由小型自主服务组成一个整体应用,各个组成部分之间是松耦合的,复杂性低,各个部分可以独立部署,修复bug或者引入新特性更容易,能够独立扩展,不同技术栈之间可以使用不同框架、不同版本库甚至不同的操作系统平台.

微服务下产品集成和集成测试框架流程(200818)

- - 人月神话的BLOG
今天谈下微服务架构下的应用集成和集成测试方面的内容. 在微服务架构下,由于传统的的单体应用以及拆分为多个微服务,那么原来单个系统内部的API接口调用以及变成了微服务间的外部接口调用,而且还可能已经由不同的开发团队在开发不同的微服务模块. 在这种情况下如果不能很好的进行产品应用集成和后续集成测试,那么会经常出现类似单元测试问题遗留到集成测试,端到端流程无法测试通过,测试用例和数据反复制作,集成过程中出现问题故障排查困难等诸多问题.