实施微服务需要哪些基础框架和技术热点

在介绍过服务注册表和网关等组件之后,我们可以通过一个简化的微服务架构图(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］高峰期单个服务延迟致雪崩效应

经过多年的探索和实践,业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践,主要包括：

• 电路熔断器模式(Circuit Breaker Patten),该模式的原理类似于家里的电路熔断器,如果家里的电路发生短路,熔断器能够主动熔断电路,以避免灾难性损失.在分布式系统中应用电路熔断器模式后,当目标服务慢或者大量超时,调用方能够主动熔断,以防止服务被进一步拖垮；如果情况又好转了,电路又能自动恢复,这就是所谓的弹性容错,系统有自恢复能力.下图Fig 8是一个典型的具备弹性恢复能力的电路保护器状态图,正常状态下,电路处于关闭状态(Closed),如果调用持续出错或者超时,电路被打开进入熔断状态(Open),后续一段时间内的所有调用都会被拒绝(Fail Fast),一段时间以后,保护器会尝试进入半熔断状态(Half-Open),允许少量请求进来尝试,如果调用仍然失败,则回到熔断状态,如果调用成功,则回到电路闭合状态.

［图8］弹性电路保护状态图

• 舱壁隔离模式(Bulkhead Isolation Pattern),顾名思义,该模式像舱壁一样对资源或失败单元进行隔离,如果一个船舱破了进水,只损失一个船舱,其它船舱可以不受影响 .线程隔离(Thread Isolation)就是舱壁隔离模式的一个例子,假定一个应用程序A调用了Svc1/Svc2/Svc3三个服务,且部署A的容器一共有120个工作线程,采用线程隔离机制,可以给对Svc1/Svc2/Svc3的调用各分配40个线程,当Svc2慢了,给Svc2分配的40个线程因慢而阻塞并最终耗尽,线程隔离可以保证给Svc1/Svc3分配的80个线程可以不受影响,如果没有这种隔离机制,当Svc2慢的时候,120个工作线程会很快全部被对Svc2的调用吃光,整个应用程序会全部慢下来.
• 限流(Rate Limiting/Load Shedder),服务总有容量限制,没有限流机制的服务很容易在突发流量(秒杀,双十一)时被冲垮.限流通常指对服务限定并发访问量,比如单位时间只允许100个并发调用,对超过这个限制的请求要拒绝并回退.
• 回退(fallback),在熔断或者限流发生的时候,应用程序的后续处理逻辑是什么?回退是系统的弹性恢复能力,常见的处理策略有,直接抛出异常,也称快速失败(Fail Fast),也可以返回空值或缺省值,还可以返回备份数据,如果主服务熔断了,可以从备份服务获取数据.

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

服务框架

微服务化以后,为了让业务开发人员专注于业务逻辑实现,避免冗余和重复劳动,规范研发提升效率,必然要将一些公共关注点推到框架层面.服务框架(Fig 9)主要封装公共关注点逻辑,包括：

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!