实施微服务需要哪些基础框架和技术热点
在介绍过服务注册表和网关等组件之后,我们可以通过一个简化的微服务架构图(Fig 5)来更加直观地展示整个微服务体系内的服务注册发现和路由机制,该图假定采用进程内LB服务发现和负载均衡机制.在下图Fig 5的微服务架构中,服务简化为两层,后端通用服务(也称中间层服务Middle Tier Service)和前端服务(也称边缘服务Edge Service,前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备,如PC,Pad或者Phone).后端服务启动时会将地址信息注册到服务注册表,前端服务通过查询服务注册表就可以发现然后调用后端服务;前端服务启动时也会将地址信息注册到服务注册表,这样网关通过查询服务注册表就可以将请求路由到目标前端服务,这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了.如果以面向对象设计模式的视角来看,网关类似Proxy代理或者Fa?ade门面模式,而服务注册表和服务自注册自发现类似IoC依赖注入模式,微服务可以理解为基于网关代理和注册表IoC构建的分布式系统. [图5]简化的微服务架构图 服务容错当企业微服务化以后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务,技术上称为1 -> N扇出(见图Fig 6).在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中.在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源(线程,队列等)被耗尽,造成所谓的雪崩效应(Cascading Failure,见图 7),严重时可致整个网站瘫痪. [图6]服务依赖 [图7]高峰期单个服务延迟致雪崩效应 经过多年的探索和实践,业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践,主要包括:
[图8]弹性电路保护状态图
Netflix将上述容错模式和最佳实践集成到一个称为Hystrix的开源组件中,凡是需要容错的依赖点(服务,缓存,数据库访问等),开发人员只需要将调用封装在Hystrix Command里头,则相关调用就自动置于Hystrix的弹性容错保护之下.Hystrix组件已经在Netflix经过多年运维验证,是Netflix微服务平台稳定性和弹性的基石,正逐渐被社区接受为标准容错组件. 服务框架微服务化以后,为了让业务开发人员专注于业务逻辑实现,避免冗余和重复劳动,规范研发提升效率,必然要将一些公共关注点推到框架层面.服务框架(Fig 9)主要封装公共关注点逻辑,包括:
(编辑:济南站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |