《分布式服务框架原理与实践》- 总结一下吧

  我们听过无数的道理,却仍旧过不好这一生。额,我说的是技术!

  《分布式服务框架原理与实践》这本书,一直在讲一些大道理,和具体的业务和我本身的工作已经没多大关系了。但是,不管怎么样,还得总结下吧。别人的道理,并不是自己的道理!自己的的道理才是硬道理,哪怕是烂道理!

  个人觉得这本书讲得太宽泛,或者说讲得不够深入,或者文学范不够,总之,感觉不够吸引人,如果赶时间,还是算了吧。

  他列举了许多需要注意的方面,而且就每个方面以单独的章节进行前因,后果的展示,应该说有比较好的或者统一的数据结构结构吧。下面稍微写写每个大道理。

第1章 应用架构的演进

  这单其实比较扯淡,但是呢,又不得不说。因为并不一定所有人都明白以前是什么什么样的。

  从传统垂直架构(单机巨无霸应用),缺点: 应用大,业务复杂,代码无从复用,扩展差。

  到RPC架构(远程方法调用,简单多机部署,框架如 apache thrift, avro-rpc, hessian, grpc),缺点:简单rpc调用,会存在复杂的路由管理,依赖复杂无法厘清,服务治理问题。

  到SOA服务架构,缺点:链路复杂,应用庞大,成本高,具体缺点未列举,其着重点是解决异构应用的服务化。

  到微服务架构,缺点:链路复杂,应用庞大,成本高,具体缺点未列举,其着重点是尽可能的服务拆分。

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

  服务的拆分,纵向拆分(按业务领域),横向拆分(将公共部分抽离出来)

  服务的治理,生命周期管理,服务容量规划,运行期治理,服务安全。

  DUBBO,HSF,Coral Service。

  架构原理: RPC层,Filter Chain层,Service层。

  功能特性: 服务订阅发布,服务路由,集群容错,服务调用,多协议,序列化方式,统一配置。

  可靠性: 服务注册中心,清除单点故障,链路健壮性。

  服务治理: 服务运行状态管控,服务监控,服务生命周期管理,故障快速定界定位,服务安全。

第3章 通信框架

  长连接还是知连接。长连接更省资源,远程通信是常态,链路重建更耗时。

  BIO还是NIO。BIO同步阻塞,简单,与线程一一对应,伸缩能力差。NIO,多路复用,并发性能超出机器最大连接句柄限制。Netty。

  服务端设计原则,只提供上层API,屏蔽通信细节,具有可扩展性。

  可靠性设计,主要应对网络闪断、网络超时、通信对端宕机等情况下,仍能提供正常服务。

  链路有效性检测分三个层面,TCP层面心跳检测(Kepp-Alive);协议层心跳检测,主要存在于长连接协议中;应用层心跳检测,发送心跳消息;(ping-pong, ping-ping)

  断连重连机制,链路中断后,等等INTERVAL时间,再次发起连接。消息缓存重发,资源优雅释放。

  性能差三宗罪:网络传输方式问题,BIO还是NIO;序列化性能差;纯种模型问题。

  netty使用误:不指定线程池线程大小;i/o线程池使用不当,导致通信线程膨胀。

第4章 序列化与反序列化

  Serializable, xml, json, MessagePack, fastjson, Protocol Buffer, Thrift, Avro.

第5章 协议栈

  对接异构第三方服务时,通常会选择HTTP/RESTFUL等公有协议;对于内部不模块的服务调用,往往会选择性能较高的二进制私有协议。

  链路创建,由调用方发起创建,双方握手后创建。链路关闭,发生异常后或者接收到关闭信号后关闭链路。

第6章 服务路由

  基于服务注册中心的订阅发布;消费者缓存提供者地址;

  负载均衡(随机、轮循、调用时延、一致性哈希、粘滞连接(会话保持));

  路由策略,本地路由优先,条件规则路由,脚本路由规则。

第7章 集群容错

  容错策略:失败切换(failover),失败通知(failback),失败缓存(failcache), 快速失败(failfast),扩展。

第8章 服务调用

第9章 服务注册中心

  支持对等集群,提供CRUD接口,安全加固,订阅发布机制,可靠性。zookeeper。

第10章 服务发布和引用

  服务提供者需要支持通过配置、注释、API调用等方式,把接口发布成远程服务;消费者可能通过对等方式引用远程服务提供者,实现服务的发布和引用。

  服务框架支持乱序启动,即提供者、消费者谁先启动都可以。

第11章 服务灰度发布

  灰度是指在黑白之间的颜色,能够平滑过渡的一种发布方式。即机器一部分一部分地发布,将一部分用户引到新功能上,另一部分仍在老功能上,测试完成后,再全量发布。

  灰度应能支持失败回滚。

第12章 参数传递

  业务参数,框架参数。

第13单 服务多版本

  服务端版本升级不影响客户端。热部署。

第14章 流量控制

  动态配额分配制,动态配额申请制。

  动态流控,分级流控。

  并发控制,服务端全局控制,消费者流控。

  连接控制,服务端、客户端连接数流控。

第15章 服务降级

  为保证核心服务的服务质量等级(SLA),停掉不太重要的业务(降级)。

  屏蔽降级,容错降级(业务放通),业务降级。

第16章 服务优先级调度

  当系统资源非常有限时,为保证高优先级服务正常运行,需要降低非核心服务的调用频次。

  线程调度器方案,生成不同优先级的线程池,根据服务决定使用哪个线程池进行运行从而保证优先级。java优先队列。加权优先队列。服务迁入迁出控制。

第17章 服务治理

  多团队问题,服务安全问题,线下服务管控问题,线上保障服务SLA,故障快速定界定位。

  flume日志采集。

第18章 分布式消息跟踪

  埋点日志,采集和存储埋点日志,计算和展示,TraceID,调用上下文。

第19章 可靠性设计

  基于注册中心状态检测,链路有效状态检测,服务健康检测。

  故障隔离:进程级故障隔离,VM级故障隔离,物理机级故障隔离,机房故障隔离。

第20章 微服务架构

  应用解耦,分而治之。

  docker。

  总体来说,本书对本人没多大意义,就当消遣消遣吧。

原文地址:https://www.cnblogs.com/yougewe/p/8283206.html

时间: 2024-10-18 10:20:58

《分布式服务框架原理与实践》- 总结一下吧的相关文章

<分布式服务框架原理与实践>读书笔记1

花了一段时间通读了<分布式服务框架原理与实践>.个人感触,所讲内容虽然不是实战级别,但可以从侧面领略"分布式服务"的魅力和要点. 1.<第一章 应用架构演进> 主要介绍了4个应用架构,这也基本上算是一个企业场景的严谨模式. 重要的是要理解SOA的设计原则.其中服务治理内容,可以作为研究DUBBO的理论储备. 2.第二章 分布式服务框架入门 实现思路上,课采用责任链,实现功能的动态扩展.该思想和Tomcat pipline,spring aop,intercept

&lt;分布式服务框架原理与实践&gt;读书笔记2

继续阅读<分布式服务框架原理与实践> 第六章 服务路由 6.1 透明化路由 路由,可以联想下路由器,比如通过浏览器要访问某个网站,中间会经过很多路由器,但这些信息对用户来说,没有实际意义,我们只关注"是否可以上网"即可. 透明化路由的实现一般采用[注册中心] 6.2 负载均衡 消费者调用服务者提供的服务,规则包括: 随机:2.轮询:3.服务调用时延(权重):4.一致性哈希:5.粘滞连接. 熟悉nginx的,基本也是包括这些规则,原理都是相通的. 6.3 本地路由优先,可以降

分布式服务框架下,如何做到服务化最佳实践?

“升级服务框架后,性能.可靠性等问题日益明显.服务化之后面临的诸多挑战,怎样分析才能给出实践最优解? 在服务化之前,业务通常都是本地API调用,本地方法调用性能损耗较小.服务化之后,服务提供者和消费者之间采用远程网络通信,增加了额外的性能损耗,业务调用的时延将增大,同时由于网络闪断等原因,分布式调用失败的风险也增大.如果服务框架没有足够的容错能力,业务失败率将会大幅提升. 除了性能.可靠性等问题,跨节点的事务一致性问题.分布式调用带来的故障定界困难.海量微服务运维成本增加等也是分布式服务框架必须

wildfly 实践1 --分布式服务配置(服务端角)

实践背景:基于wildfly开发分布式服务,包括web服务,DBA(数据访问)服务及其它业务服务,全部使用分布式方式开发与部署. 实践1:分布式服务(服务端角色)配置 此实践使用两台机器部署服务,一台部署web服务(客户端角色),一台为其它服务如DBA(服务端角色),TCP服务等. 两台机器全部使用wildfly9做为服务容器. web服务器:192.168.50.253(eclipse开发环境在此机器上) ,DBA服务器 192.168.50.123 在50.123机器上运行add-user.

wildfly 实践5 ---分布式服务中的JMS服务访问

实践条件与目标: 1. 分布式服务中主从服务相关配置 2. 从服务中主要代码片段展示 3. 此次使用wildfly10,因为其默认的jms服务是activemq. 步骤: 主服务配置中使用standalone-full.xml启动,其自带activemq模块. 使用adduser增加应用程序用户名称为guest,密码为guest,角色为guest,增加应用程序用户ejbuser,密码123. 配置文件中找到activemq模块,并修改配置如下: <subsystem xmlns="urn:

分布式服务框架学习笔记1 应用架构演进

传统垂直应用架构 业界曾比较流行的有: LAMP架构:Linux+Apache+PHP(前后端分离)+MySQL(读写分离) MVC架构:Spring+Struts+iBatis/Hibernate+Tomcat 在高并发.大流量的应用场景中,需要做集群,通常的组网方案是前端通过F5等负载均衡器做七层负载均衡(或者使用SLB等软负载),后端做对等集群部署. 随着业务的不断发展,应用规模日趋庞大,传统垂直架构开发模式的弊端变得越来越突出.这就需要将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服

浅谈分布式服务协调技术 Zookeeper

Google的三篇论文影响了很多很多人,也影响了很多很多系统.这三篇论文一直是分布式领域传阅的经典.根据MapReduce,于是我们有了Hadoop:根据GFS,于是我们有了HDFS:根据BigTable,于是我们有了HBase.而在这三篇论文里都提及Google的一个Lock Service -- Chubby,哦,于是我们有了Zookeeper. 随着大数据的火热,Hxx们已经变得耳熟能详,现在作为一个开发人员如果都不知道这几个名词出门都好像不好意思跟人打招呼.但实际上对我们这些非大数据开发

《从PAXOS到ZOOKEEPER分布式一致性原理与实践》pdf

下载地址:网盘下载 内容简介  · · · · · · <Paxos到Zookeeper:分布式一致性原理与实践>从分布式一致性的理论出发,向读者简要介绍几种典型的分布式一致性协议,以及解决分布式一致性问题的思路,其中重点讲解了Paxos和ZAB协议.同时,本书深入介绍了分布式一致性问题的工业解决方案--ZooKeeper,并着重向读者展示这一分布式协调框架的使用方法.内部实现及运维技巧,旨在帮助读者全面了解ZooKeeper,并更好地使用和运维ZooKeeper.全书共8章,分为五部分:第一

分布式服务弹性框架“Hystrix”实践与源码研究(一)

文章初衷 为了应对将来在线(特别是无线端)业务量的成倍增长,后端服务的分布式化程度需要不断提高,对于服务的延迟和容错管理将面临更大挑战,公司框架和开源团队选择内部推广Netflix的Hystrix,一是为了推进各部门的服务使用覆盖率,二是为了增加C Sharp语言版本的参与度(目前公司至少三成服务由.NET编写).该博文属于个人对Hystrix研究和实践经验. 什么是Hystrix? Hystrix是世界最大在线影片租赁服务商Netflix开源,针对分布式系统的延迟和容错库.该库由Java写成,