描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121279195
1、微服务是当前非常热的技术关键词之一，那么微服务如何落地呢？首先要实现服务化，微服务架构是一种服务化架构风格。《分布式服务框架原理与实践》对如何构建分布式服务化系统，提供了原理分析、关键技术、开发案例以及业界技术对比，非常系统化，不论是学习分布式服务技术还是深入大型互联网架构都非常实用。
2、《分布式服务框架原理与实践》作者李林锋多年来在华为一直从事核心代码的架构设计和开发，属于实战型架构师，这本书集合了他多年的架构思路，书中内容组织清晰，图例详实，非常便于理解与吸收。
3、《分布式服务框架原理与实践》首先分析了作为一个分布式服务框架所需具备的能力，包括服务注册中心、服务调用、服务路由、服务发布／灰度发布等；接着分析了服务底层如何有效地进行通信，包括通信框架、序列化／反序列化及协议栈等；然后分析了服务如何做到高可靠性及高安全性等重要特性；*后也阐述了从服务化如何向微服务演进。干货满满！
本书作者具有丰富的分布式服务框架、平台中间件的架构设计和实践经验，主导设计的华为分布式服务框架已经在全球数十个国家成功商用。书中依托工作实践，从分布式服务框架的架构设计原理到实践经验总结，涵盖了服务化架构演进、订阅发布、路由策略、集群容错和服务治理等多个专题，全方位剖析服务框架的设计原则和原理，结合大量实践案例与读者分享作者对分布式服务框架设计和运维的体会。同时，对基于Docker部署微服务以及基于微服务架构开发、部署和运维业务系统进行了详细介绍。
第1 章 应用架构演进 ………………………………………………………………………….. 1
1.1 传统垂直应用架构 ………………………………………………………………………. 2
1.1.1 垂直应用架构介绍 ………………………………………………………………….. 2
1.1.2 垂直应用架构面临的挑战 ………………………………………………………… 4
1.2 RPC 架构 …………………………………………………………………………………………. 6
1.2.1 RPC 框架原理 ………………………………………………………………………… 6
1.2.2 *简单的RPC 框架实现 ………………………………………………………….. 8
1.2.3 业界主流RPC 框架 ……………………………………………………………….. 14
1.2.4 RPC 框架面临的挑战 …………………………………………………………….. 17
1.3 SOA 服务化架构 …………………………………………………………………………….. 18
1.3.1 面向服务设计的原则……………………………………………………………… 18
1.3.2 服务治理 ……………………………………………………………………………… 19
1.4 微服务架构 …………………………………………………………………………………….. 21
1.4.1 什么是微服务 ……………………………………………………………………….. 21
1.4.2 微服务架构对比SOA …………………………………………………………….. 22
1.5 总结 ………………………………………………………………………………………………. 23
第2 章 分布式服务框架入门 ………………………………………………………………………… 25
2.1 分布式服务框架诞生背景 ………………………………………………………………… 26
2.1.1 应用从集中式走向分布式 ………………………………………………………. 26?
2.1.2 亟需服务治理 ……………………………………………………………………….. 28
2.2 业界分布式服务框架介绍 ………………………………………………………………… 29
2.2.1 阿里Dubbo …………………………………………………………………………… 30
2.2.2 **HSF ……………………………………………………………………………… 33
2.2.3 亚马逊Coral Service ……………………………………………………………… 35
2.3 分布式服务框架设计 ……………………………………………………………………….. 36
2.3.1 架构原理 ……………………………………………………………………………… 36
2.3.2 功能特性 ……………………………………………………………………………… 37
2.3.3 性能特性 ……………………………………………………………………………… 39
2.3.4 可靠性 …………………………………………………………………………………. 39
2.3.5 服务治理 ……………………………………………………………………………… 40
2.4 总结 ………………………………………………………………………………………………. 41
第3 章 通信框架 ……………………………………………………………………………………….. 42
3.1 关键技术点分析 ………………………………………………………………………………. 43
3.1.1 长连接还是短连接 ………………………………………………………………… 43
3.1.2 BIO 还是NIO ……………………………………………………………………….. 43
3.1.3 自研还是选择开源NIO 框架 ………………………………………………….. 46
3.2 功能设计 ………………………………………………………………………………………… 47
3.2.1 服务端设计 …………………………………………………………………………… 48
3.2.2 客户端设计 …………………………………………………………………………… 50
3.3 可靠性设计 …………………………………………………………………………………….. 53
3.3.1 链路有效性检
序一
IT 的体系架构在历史上经历了几次大的变化。从主机瘦客户机时代，到Client Server兴起，然后过渡到Browser Server 的架构，再到移动 云计算 大数据的大热。总结起来，IT 的核心变迁轨迹是在客户端不断提升体验，易联易用，而在服务器端则是不断追求性能和成本优化改进。近几年，还有一个非常明显的趋势是技术的成熟度和融合度不断提高，移动、云计算领域平台型的公司（Android、iOS、AWS）使得整个IT 能力的使用成本很低，进入速度非常快，现在的高中生也可以利用手头的工具非常快速方便地参与到软件构建中来，这在以前是不可想象的。移动互联网兴起以后，大概在短短5 年内，世界上绝大部分原来在PC 端可以满足的需求都由移动端的应用实现了一遍。IT 已经变成了一个快速消费品，而不是一个奢侈品。技术的进步使得IT 的敏捷性大大提升，但是对于一个大型系统来说，如何能够降低系统的复杂度，提升敏捷性是关键而又头疼的问题。我们也看到一些通用的标准和**实践已经建立起来了，降低模块之间的耦合度，提升组件的内聚性，规范对外的接口，实现分布式的系统架构，把一个大型系统通过服务化的方式规划治理起来，已经成为一个共识。一个现代的大型IT 系统，服务可以多至十万、百万级，如此众多的服务，从设计、开发、运行、编排、维护到治理，每一个环节都需要大量深入仔细的考虑，才能够运转起来。我们可以把这样一个系统比喻成一个城市，城市里面有成千上万的公司，每一个公司都有自己的业务来往，同时又需要现代化的交通、电力、通信、金融等体系的支持。无论是小公司还是大公司，都依赖于整个城市的运作和治理体系。公司和城市是相辅相成的关系。IT系统里面的业务模块和服务化框架也是相辅相成的关系。服务化框架对于一个大型IT 系是不可或缺的。业界有很多介绍服务化理念和技术点的文章和书籍。但真正能够在理论、实践、技术要点、眼界多方面全面覆盖的资料,还是比较缺乏的。我很高兴看到林锋能够总结自己在理论、产品和客户实践多方面的认知和经验，为读者奉献《分布式服务框架原理与实践》一书，深入浅出地介绍分布式服务的概念、体系和关键技术点。希望这本书能够帮助你了解分布式服务框架，掌握分布式服务体系和技术要点，同时也能实践服务化给你的IT 系统带来的敏捷。黄省江 华为软件PaaS 平台＆云中间件技术总监
序二
容器SDN 技术与微服务架构实践从20 世纪末期的**波互联网浪潮开始，软件架构的主流就逐步从Office 这类纯客户端软件逐步过渡到服务端的架构设计。与传统的客户端设计相比，服务端的架构设计更关注伸缩性、可用性和可维护性。很可惜的是，现在市面上讲语言、讲算法、讲设计模式或者讲某一门独立的技术的书都不少，但服务端架构设计的书却寥寥无几。从私下沟通的结果来看，大部分互联网企业都没有解决好上面的几个问题。正如建筑设计的现代化是从结构工程师开始的，软件设计的现代化会从架构师开始，希望李林锋这本书能够帮助广大的架构师或者有志于成为架构师的人掌握好这些知识，让架构师能够带领开发团队构建出稳定、安全、可维护、可伸缩的合格产品，让架构师在软件开发现代化这条路上起到领路人的作用。本书*末一章讲述了*近很火的微服务架构，微服务架构的思想包含了对以前种种架构模式的反思，也通过Docker、Mesos 等技术变成**个可以轻松产品化的架构思想。我相信再过几年对于开发人员，特别是服务端的开发人员，他们所面临的开发模式将与现在的开发模式有很大的差异，这种差异我觉得甚至会大过程序可以有服务端这个概念的引入。在微服务架构下，开发的门槛将进一步降低，分布式将更加自然而不是依赖于艰难的设计，运维的负担也将降低至一个极低的水平。我们可以期望通过微服务架构，从想法到产品的距离将更短，也能期待涌现出更多让人叹为观止的产品，还能期待能出现些我们现在完全无法预测的技术和产品。李道兵 七牛云首席架构师
前 言
2008 年9 月份，我有幸参与了一个华为软件公司的国内Top3 项目，作为一名有经验的开发，项目经理安排我负责整个系统的实时交易和后台服务端设计。尽管有ERP 软件开发经验，但是**次参与这么大项目的架构设计和开发，压力还是非常大，经常夜不能寐。好在公司当时已经研发了Java Web 框架，它基于Spring Struts iBatis 构建，利用公司成熟的MVC 框架我们很顺利地完成了项目的开发和交付，并*终成功上线运行。随着业务的发展，用户数和需求逐步增多，团队规模越来越大，我们遇到了很多棘手的问题：
1） 代码重复率高：一些业务层的公共功能，被多个模块重复开发，导致研发成本上升，代码质量下降，架构腐化，为后续系统的运维和新功能的开发带来巨大的挑战。
2） 需求变更困难：由于长流程无法有效拆分、代码重复率高等因素，导致每次需求变更就影响一大片，需要做大量的回归测试来保证质量，需求的交付周期被拉长。
3） 部署效率低：业务没有拆分，很多功能模块都打到同一个war 包中，一旦有一个功能发生变更，就需要重新打包和部署；巨无霸应用由于包含功能模块过多，编译、打包时间比较长，一旦编译过程出错，需要根据错误重新修改代码再编译，耗时较长。
4） 学习成本高：业务流程是由一长串本地接口或者方法调用串联起来的，臃肿而冗长，而且往往由一个人负责开发和维护。随着业务的发展和需求变化，本地代码在不断的迭代和变更，*后形成了一个个垂直的功能孤岛，只有原来的开发者才理解接口调用关系和功能需求，一旦原有的开发者离职或者调到其他项目组，这些功能模块的运维就会变得非常困难。
5） 缺乏统一的RPC 框架：由于Web 框架只提供了HTTP/HTTPS 协议，例如SOAP、SMPP 等协议栈需要业务自行集成第三方的开源框架，超时重发、网络断连等底层故障需要在应用上层统一封装和处理，工作繁琐而且容易出错，对业务开发人员的技能要求也非常高。随着公司业务的不断发展，传统MVC 架构已经无法再满足业务对平台的诉求，因此在2010 年下半年我们开始研发新的SOA 中间件，它包括企业集成总线ESB、流程编排引擎BPM、RPC 通信框架等。新的RPC 通信框架底层封装了Java NIO 通信框架Netty、常用的序列化/反序列化框架，以及为应用层提供线程池和消息调度器，基于RPC 通信框架，业务可以快速的实现跨进程的远程通信，而不需要关心底层的通信细节，例如链路的闪断、失败重试等，极大的提升了应用的开发效率。在很长一段时间，自研的RPC 框架成为业务**的Java 服务端框架。随着RPC 框架的推广和使用日益深入，一些新的公共需求被反馈过来：
1） 依赖管理：当服务越来越多时，服务URL 配置管理变得非常困难，希望有一个统一的服务注册中心管理服务的依赖关系。
2） 透明路由：通过订阅发布机制，消费者只需要关心服务本身，并不需要配置具体的服务提供者地址，实现服务的自动发现。
3） 服务治理：业务失败之后的放通处理，超时时间控制、流控等常用运维功能，希望能够独立出一个服务治理中心，统一对集群各节点的服务做在线治理，提升治理效率，保障服务SLA。
4） 其他……
为了解决这些问题，以RPC 框架为核心，我们构建了全新的分布式服务框架，相比于传统RPC 框架，它提供了如下新特性：
1） 基于注册中心的服务订阅/发布机制，支持服务自动发现和健康状态检测。
2） 集群容错。
3） 依赖解耦，全配置化开发，对应用零侵入。
4） 服务治理，包括服务降级、服务调用链跟踪、服务上线审批和下线通知等。
5） 服务化**实践等。
分布式服务框架不仅仅包含核心的运行时类库，还包括服务划分原则、服务化**实践、服务治理、服务监控、服务开发框架等，它是一套完整的解决方案，用来协助应用做服务化改造，以及指导用户如何构建适合自己业务场景的服务化体系，将服务化的价值发挥到极致。基于分布式服务框架，业务终于可以把全部精力都放到应用层的逻辑开发，研发效率、系统可靠性都得到了极大的提升。目前，华为电信软件主要解决方案几乎所有的Java 系统都基于分布式服务框架构建，底层的基础框架实现了统一。*近一年多来，随着DevOps 和以Docker 为首的容器技术的发展，微服务架构逐渐流行起来，微服务架构的流行有其必然的历史原因，它是敏捷开发、基础设施服务化、DevOps和互联网行业快速发展的综合产物。亚马逊AWS、Netflix 等都是微服务的成功实践者，相信未来国内越来越多的大型应用也会演进到微服务架构。华为软件公司的Java 架构经历了传统的MVC 垂直架构-RPC 框架-分布式服务框架，目前正在向Docker 微服务方向演进，整个服务化架构的演进历程也是业界技术变迁的一个缩影。在这7 年的演进历程中，我有幸全程参与了相关框架的架构设计和核心模块的开发，深有感触。在此希望将自己设计、开发和运维的相关经验分享出来，为初学者和相关经验人士提供一些启发，汲取相关经验，少走些弯路。?能够完成本书需要感谢很多人，首先感谢华为公司给我提供了足够大的舞台，感谢华为PaaS 平台＆中间件团队领导和同事莫晓军、望岳和王世军等，以及与我在分布式服务框架团队一起战斗过的开发、测试和资料。其次要感谢我的家人，你们一直在背后默默的支持我。感谢参与本书编辑的英姐、美工以及其他人员，你们的辛苦换来了本书的如期上市。*后要感谢所有的读者，你们的支持和鼓励是我写作本书的动力源泉。
李林锋
2015 年12 月于南京
构建企业互联网架构的关键在于系统分布式和服务化，尤其对于大型网站和大型企业系统，系统的灵活性、超大容量、弹性和自治能力是非常大的挑战。在《分布式服务框架原理与实践》一书中，作者基于深厚的软件技术积累和电信领域成功应用实践，对如何构建分布式服务化系统，提供了原理分析、关键技术、开发案例以及业界技术对比，非常系统化，不论是学习分布式服务技术还是深入大型互联网架构都非常实用。
——华为云集成平台首席架构师苗彩霞
认识林锋已有多年，从《Netty权威指南》到本书的诞生，再次见证了作者在该领域深厚的沉淀。阅览该书的目录以及相关章节，我惊诧于作者在这些领域深入的洞察和实践。该书几乎覆盖了分布式系统开发的每一个关键技术点，包括*为重要的通信框架设计、时下流行的微服务、服务路由关联的技术和策略，以及饱受争议的OSGi。强烈推荐相关从业人员阅读此书。
——苏宁云商云计算中心技术总监汤泳
在大型网站架构设计方面摸爬滚打多年后，看到《分布式服务框架原理与实践》如获至宝，作者条理清晰、由浅入深地解析了分布式服务架构所涉及方方面面的关键技术和原理，既有纵向演进介绍，又有横向竞品对比。尤其针对各种场景所提出的设计原则或**实践，都是作者的实战总结，有些经验的获取成本高昂，非常宝贵。本书完全可以直接用于指导分布式服务系统的构建。
——中国移动手机阅读基地平台首席架构师胡稳
分布式的应用在设计、开发以及部署的各个方面都比较复杂，国内外也没有权威的图书进行系统介绍，于是在这方面，我们不得不一遍遍地踩坑。林锋有着深厚的技术基础和丰富的架构经验，这本集他经验和心血而成的图书，包含了分布式系统的方方面面，既有宏观的理论介绍，也有来自一线的经验分享，相信它必将成为架构师和开发人员的***图书！
——东软集团资深软件工程师、InfoQ编辑张卫滨
“微服务”无疑是本年度*热的技术关键词之一！那如何落地微服务呢？我认为首先要实现服务化，而本书恰好提供了一个很好的服务化操作指导。作者首先分析了作为一个分布式服务框架所需具备的能力，包括服务注册中心、服务调用、服务路由、服务发布／灰度发布等；其次作者分析了服务底层如何有效地进行通信，包括通信框架，序列化／反序列化及协议栈等；再次作者分析了服务如何做到高可靠性及高安全性等重要特性；*后作者也阐述了从服务化如何向微服务演进。
——麻袋理财首席架构师王天青
以OpenStack为规范建设的IaaS、以Docker为代表的容器技术、以分布式微服务框架构建的业务平台即将颠覆业务系统整体建设方案，新的系统建设方案将极大提升业务系统的可用性、扩展性和应变能力。微服务架构对于运营商内容型业务的互联网化转型意义非凡，系统架构微服务化才能真正支撑好业务转型的需要。本书将成为帮助大家更好地理解微服务框架关键技术的原理和实现的***书籍。
——咪咕动漫系统支撑部技术总监*
锋兄在华为一直从事核心代码的架构设计和开发，属于实战型架构师，而且乐于分享。《分布式服务框架原理与实践》源于他在多年架构设计工作中的实战经验，阅读价值极高！在面向大规模、分布式系统架构中，服务框架是其中的核心和必经之路。祝贺锋兄新书造福广大程序猿！
——奇蛙CEEWA运动无人机合伙人、前华为开放平台总架构师冯黎
近些年来，越来越多网站需要同时提供Web、移动App、OpenAPI多种访问方式，基于分布式服务的业务分治与复用需求越来越强烈，使用分布式服务构建系统已经成为互联网开发的常用手段。但是分布式服务的关键技术有哪些？核心原理是什么？**实践是什么？本书作者作为分布式框架的开发者根据自己的实践经验编写的这本《分布式服务框架原理与实践》或可为您解惑。分布式服务框架用到的各种技术也是整个互联网分布式技术的一个缩影，您也可窥一斑而知全豹，通过本书学习掌握各种分布式开发技巧。
——宅米网CTO、《大型网站技术架构：核心原理与案例分析》作者李智慧
整书由构建分布式服务为基础讲起，逐步深入到分布式服务的保障机制，*后也讲解了时下新兴分布式设计方案微服务架构。书中内容组织清晰，图例详实，非常便于理解与吸收，是一本不错的提升分布式服务架构能力的书籍。
——链家网架构师吕毅
本书深度阐述了应用和系统架构方面的设计和原理，真实体现了李林锋丰富的技术架构经验以及乐于分享的精神。在业务系统越来越讲究高可用、高性能、可伸缩扩展、高安全性、自动运维的今天，本书集合了大型企业多年的架构思路，为技术以及产品人员提供了重要的参考依据，从理念上提升了每位读者的技术水平，非常值得深入阅读和理解。
——阿里云PaaS平台产品架构师杨林
8.2.2 异步服务调用
基于JDK的Future机制，可以非常方便地实现异步服务调用，JDK的Future接口定义如图8-5所示。
JDK原生的Future主要用于异步操作，它代表了异步操作的执行结果，用户可以通过调用它的get方法获取结果。如果当前操作没有执行完，get操作将阻塞调用线程。
在实际项目中，往往会扩展JDK的Future，提供Future-Listener机制，它支持主动获取和被动异步回调通知两种模式，适用于不同的业务场景。
以Netty的Future接口定义为例，新增了监听器管理接口，监听器主要用于异步通知回调。
异步服务调用的工作流程如下：
1） 消费者调用服务端发布的接口，接口调用由分布式服务框架包装成动态代理，发起远程服务调用。
2） 通信框架异步发送请求消息，如果没有发生I/O异常，返回。
3） 请求消息发送成功后，I/O线程构造Future对象，设置到RPC上下文中。
4） 用户线程通过RPC上下文获取Future对象。
5） 构造Listener对象，将其添加到Future中，用于服务端应答异步回调通知。
6） 用户线程返回，不阻塞等待应答。
7） 服务端返回应答消息，通信框架负责反序列化等。
8） I/O线程将应答设置到Future对象的操作结果中。
9） Future对象扫描注册的监听器列表，循环调用监听器的operationComplete方法，将结果通知给监听器，监听器获取到结果之后，继续后续业务逻辑的执行，异步服务调用结束。
需要指出的是，还有另外一种异步服务调用形式，就是不添加Listener，用户连续发起N次服务调用，然后依次从RPC上下文中获取Future对象，*终再主动get结果，业务线程阻塞，相比于老的同步服务调用，它的阻塞时间更短，其工作原理如图8-8所示。
异步服务调用的代码示例如下：
xxxService1.xxxMethod(Req);
Future f1 = RpcContext.getContext().getFuture();
xxxService2.xxxMethod(Req);
Future f2 = RpcContext.getContext().getFuture();
Object xxResult1 = f1.get(3000);
Object xxResult2 = f2.get(3000); }
假如xxxService1和xxxService2发布成异步服务，则调用xxxMethod之后当前业务线程不阻塞，立即返回null。用户不能直接使用它的返回值，而是通过当前线程上下文RPCContext获取异步操作结果Future。获取到Future之后继续发起其他异步服务调用，然后获取另一个Future……*后，通过Future的get方法集中获取结果。无论有多少个Future，采用此种方式用户线程*长阻塞时间为耗时*长的Future，即T = Max t(future1….N)。如果采用同步服务调用，用户线程的阻塞时间T = t(future1) t(future2) …… t(futureN)。
异步服务调用相比于同步服务调用有两个优点：
◎ 化串行为并行，提升服务调用效率，减少业务线程阻塞时间。
◎ 化同步为异步，避免业务线程阻塞。
由于每次服务调用都是同步阻塞，三个服务调用总耗时为T = T1 T2 T3。下面我们看下采用异步服务调用之后的优化效果。
采用异步服务调用模式，*后调用三个服务异步操作结果Future的get方法同步等待应答，它的总执行时间T = Max(T1, T2, T3)，相比于同步服务调用，性能提升效果非常明显。
第二种基于Future-Listener的纯异步服务调用，它的代码示例如下：
xxxService1.xxxMethod(Req);
Future f1 = RpcContext.getContext().getFuture();
Listener l = new xxxListener();
f1.addListener(l);
……后续代码省略 }
基于Future-Listener的异步服务调用相比于Future-get模式更好，但是在实际使用中有一定的局限性，具体的使用限制留给读者自己思考。
评论
还没有评论。