码迷,mamicode.com
首页 > 其他好文 > 详细

<分布式服务框架-原理与实践-李林锋>重点词汇

时间:2017-10-15 19:26:57      阅读:220      评论:0      收藏:0      [点我收藏+]

标签:标准   哈希   成本高   动态   提供者   检测   弹性   自身   完整   

序一

  如何降低系统的复杂度,提升敏捷性是关键而头疼的问题;降低模块之间的耦合度,提升组件的内聚性规范对外的接口,实现分布式的系统架构,把一个大型的系统通过服务化的方式规划治理起来,已经成为一个共识。

序二

  与传统的客户端设计相比,服务端的架构设计更关注伸缩性、可用性和可维护性

前言

  随着业务的发展,传统的系统架构,遇到越来越多的问题:代码重复率高、需求变更困难、部署效率低学习成本高、缺乏统一rpc框架;

  随着rpc框架的推广和使用日益深入,一些公共需求被反馈:依赖管理(依赖关系)透明路由服务自动发现)、服务治理

  分布式服务框架不仅仅包含核心的运行时类库,还包括服务划分原则、服务化最佳实践服务治理、服务监控、服务开发框架等,它是一套完整的解决方案

  微服务化架构是敏捷开发、基础设施服务化、DevOps和互联网行业快速发展的综合产物。

  整个服务化架构的演进历程也是业界技术变迁的一个缩影

第1章 应用架构演进

  公共能力抽取和复用,可以有效降低公共模块重复开发建设的成本。

  1.1、传统垂直应用架构

  弊端越来越突出:开发维护成本变高、部署效率逐渐降低;团队协作效率差;系统可靠性变差;维护和定制困难;新功能上线周期变长。

  将公共能力API抽取,作为独立的公共服务供其他调用者消费,以实现服务的共享重用;应用拆分之后,接口调用由本地API演变成进程的远程方法调用,此时RPC框架应运而生。

  1.2、RPC架构

  目标:让远程过程(服务)调用更加简单、透明,由RPC框架负责屏蔽底层传输方式(TCP或UDP)、序列化方式(XML/JSON/二进制)和通信细节。

  二进制序列化方式相对XML和JSON等,体积更小,对于高并发、大数据量和多语言的环境更有优势。

  RPC框架面临挑战:服务URL配置管理变得非常困难,负载均衡器单点压力越来越大;需要进行服务依赖治理,防止业务服务架构腐化;为解决容量规划问题,需要采集服务调用相关KPI数据并进行汇总分析。

  1.3、SOA服务化架构

  SOA面向服务一般原则:服务可复用;服务共享一个标准契约;服务是松耦合的;服务是底层逻辑的抽象;服务是可组合、可编排的;服务是自治的;服务是无状态的;服务是可被自动发现的。’

  SOA服务治理主要包含:服务定义;服务生命周期管理;服务版本治理;服务注册中心(支持服务的订阅发布动态发现机制);服务监控;运行期服务质量保障();快速的故障定界定位手段;服务安全。

第2章 分布式服务框架入门

  关键词:对业务代码低侵入;服务提供者和消费者通过长连接通信;服务调用职责链,提供多种服务调用切面供框架自身和使用者扩展;服务注册中心负责服务发布和通知(服务地址透明化);服务治理对服务的运行状态、历史数据、健康度和调用关系进行可视化的分析和维护;注册中心通过心跳检测服务提供者的存在,并将服务提供宕机事件立即通知消费者;

  技术视为商业目标服务的。

第3章 通信框架

  长连接:多路消息可复用同一个链路,节省资源;避免链路重建过程,降低调用时延

  如果要构建高性能低时延、支持大并发的系统,使用同步阻塞IO是无法满足性能线性增长和可靠性的。

第6章 服务路由

  6.1、透明化路由

  分布式服务线上运行一般都是集群部署,意味着某个服务一般都是多实例部署,这就涉及到了服务路由

  基于注册中心的服务订阅/发布,服务消费者无需硬编码服务提供者地址;注册中心检测到服务提供者列表变更之后,会将变更内容主动推送给消费者,消费者动态刷新本地缓存的服务提供者地址。

  6.2、负载均衡

  负载均衡策略:随机;轮询;服务调用时延动态调整权重;一致性哈希;粘滞链接。

  可配置同机房优先。

第7章 集群容错

  7.2、容错策略

  失败自动切换(Failover);失败通知(Failback);失败缓存(Failcache);快速失败(Failfast)

第9章 服务注册中心

  9.2、关键功能性设计

  服务订阅发布机制优点:透明化路由(服务提供者和消费者互相解耦);服务健康状态检测(服务提供者宕机,实时通知消费者);弹性伸缩能力动态发现)。

第11章 服务灰度发布

  总结:灰度发布,可以实现业务的快速试错敏捷交付,缩短新业务和产品的上线周期

第14章 流量控制

  保障服务SLA(服务等级协议)的重要措施,也是业务高峰期故障预防和恢复的有效手段

第15章 服务降级

  服务降级主要包括:容错降级屏蔽降级两种模式。

  15.1、屏蔽降级

  对非核心服务做强制降级,不发起远程服务调用,直接返回空、异常货值执行本地逻辑,减少自身对公共资源的消费,把资源释放供核心服务使用。

  15.2、容错降级

  当非核心服务不可用时,可对故障服务做业务逻辑放通

  容错降级与屏蔽降级主要差异:触发条件不同,容错降级时根据服务调用结果(RPC异常、业务失败)自动匹配触发,而屏蔽降级通过人工根据系统运行状态手工操作触发;作用不同,容错降级时当服务提供者不可用时,让消费者执行业务放通,而屏蔽降级的主要目的是将原属于降级业务的资源调配出来功能核心业务使用;调用机制不同,容错降级会发起正常远程服务调用,而屏蔽降级在本地调用。

第18章 分布式消息跟踪

  总结:利用分布式消息跟踪系统,对业务调用流程记录进行记录和采集,通过在线和离线的大数据计算,从海量日志中抽取对运维和运营有价值的数据,提升业务的运行质量,挖掘新的营销增长点,促进业务由IT运营DT智慧运营转型。

第20章 微服务架构

  微服务的“微”所表达的是一种设计思想和指导方针。

第21章 服务化最佳实践

  如果服务化框架没有足够的容错能力,业务失败率将会大幅提升。

  21.1、 性能和时延问题

  由于Netty采用异步通信模式,一个I/O线程可以并发处理N个客户端链接和读写工作,从根本上解决了同步阻塞I/O一连接一线程模型,架构的性能、弹性伸缩能力和可靠性都得到极大提升。

  21.2、 事务一致性问题

  通常,分布式服务基于两阶段提交实现。

  在大多数业务场景中,我们可以使用最终一致性替代传统的强一致性,尽量避免使用分布式事务。

<分布式服务框架-原理与实践-李林锋>重点词汇

标签:标准   哈希   成本高   动态   提供者   检测   弹性   自身   完整   

原文地址:http://www.cnblogs.com/yangfengtao/p/7672507.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!