分布式服务框架原理与实践 - (EPUB全文下载)

文件大小：0.17 mb。
文件格式：epub 格式。
书籍内容：

分布式服务框架原理与实践
第1章 应用架构演进
第2章 分布式服务框架入门
第3章 通信框架
第4章 序列化与反序列化
第5章 协议栈
第6章 服务路由
第7章 集群容错
第8章 服务调用
第9章 服务注册中心
第10章 服务发布和引用
第11章 服务灰度发布
第12章 参数传递
第13章 服务多版本
第14章 流量控制
第15章 服务降级
第16章 服务优先级调度
第17章 服务治理
第18章 分布式消息跟踪
第19章 可靠性设计
第20章 微服务架构
第21章 服务化最佳实践
第1章 应用架构演进
随着业务的发展，应用规模不断扩大，系统内部的巨无霸应用越来越多，常规的垂直应用架构已经无法应对复杂业务带来的各种挑战。通过将业务公共能力抽象成原子服务，对复杂应用进行水平拆分和服务化，实现服务消费者和提供者的解耦。公共能力抽取和复用，可以有效降低公共模块重复开发建设的成本。
传统垂直架构改造的核心就是要对应用做服务化改造，服务化改造使用到的核心技术架构就是分布式服务框架。
本章对应用架构的演进历史进行剖析，使读者能够更清晰和全面地了解应用架构的历史演进过程以及未来架构的发展方向。
1.1 传统垂直应用架构
在2006年之前，业界比较流行的有：LAMP架构，即Linux+Apache+PHP（前后台界面和业务逻辑）+MySQL 数据库（读写分离）；MVC 架构，即 Spring+S truts+iBatis/Hibernate+Tomcat；厚重的EJB企业架构也流行过很长一段时间。
尽管上述三种架构的技术实现细节存在较大差异，但它们有一个共性：即垂直应用架构。垂直应用架构技术比较单一，学习成本低，开发上手较快，测试、部署和运维也比较简单，因此在很长一段时间里都占据着统治地位。
1.1.1 垂直应用架构介绍
下面以经典的MVC垂直架构为例，对垂直应用架构的特点进行分析总结。
MVC垂直架构逻辑架构图示例如图1-1所示。
图1-1 MVC垂直架构
MVC架构通常分为三层：
1）最前端是视图展示层（View），主要用于前端Portal展示，使用的开发工具为JSP、JS、HTML+CSS等。视图是用户看到并与之交互的界面，视图向用户显示相关的业务数据，并能接收用户的输入。视图层并不执行实际的业务逻辑，也不改变数据模型。它能接收模型发出的数据更新请求，从而对用户界面进行同步更新。
2）中间为调度控制层（Control），主要用于前端Web请求的分发，调度后台的业务逻辑执行，可以通过继承Struts的Action实现。当Web用户单击Web页面中的提交按钮来发送HTML表单时，控制器接收请求并调用相应的模型组件去处理请求，然后调用相应的视图来显示模型返回的数据。
3）第三层为应用模型层（Model），模型是应用程序的主体部分。模型代表了业务数据和业务执行逻辑。当数据发生变化时，它要负责通知视图部分。一个模型可以同时为多个视图提供数据，由于同一个模型可以被多个视图重用，所以提高了应用的可重用性。
标准的 MVC模式并不包含数据访问层，但是在实际开发过程中，通常需要专门的数据库连接池和统一的数据库访问接口对接数据库。于是 ORM 框架逐渐流行起来，iBatis、Hibernate 等 ORM 框架屏蔽了底层的数据库连接池和数据源实现，同时提供了诸如Naming-SQL、面向对象的数据查询接口等JDBC上层封装，极大地降低了使用原生JDBC驱动开发的成本，提升了开发效率。
通常基于 MVC 架构开发的应用代码会统一打成一个 war 包，部署在 Tomcat 等 Web容器中。不同的应用功能之间通过本地API进行调用，基本不存在跨进程的远程服务调用。
业务的组网也非常简单，在小规模应用场景下，通常只需要做热双机即可，服务端监听浮动IP，通过Watch Dog监测应用进程，判断应用进程宕机或者僵死之后，将应用切换到备机中，然后尝试重新拉起主机。双机部署方案逻辑组网示意图如图1-2所示。
在高并发、大流量的应用场景中，需要做集群，通常的组网方案是前端通过 F5 等负载均衡器做七层负载均衡（或者使用SLB等软负载），后端做对等集群部署，它的逻辑组网如下图1-3所示。
图1-2 双机逻辑组网图
图1-3 带负载均衡的集群组网
1.1.2 垂直应用架构面临的挑战
在业务发展初期，应用规模比较小，基于JEE构建的垂直应用架构还能够有效支撑业务的发展。随着业务的不断发展，应用规模日趋庞大，传统垂直架构开发模式的弊端变得越来越突出，具体如下：
1）复杂应用的开发维护成本变高，部署效率逐渐降低。以实际项目为例，2007年我参与一个基于传统MVC垂直架构开发的企业ERP系统，由于业务功能不断膨胀，最后代码全量编译和部署一次需要15分钟。更为严重的是只要某个功能编译出错或者功能测试出问题，就需要重新打包编译，软件的部署效率极低。
2）团队协作效率差，部分公共功能重复开发，代码重复率居高不下。随着业务的发展，团队规模不断扩大，研发被打散到不同的开发小组中。不同的功能模块可能会依赖一些公共能力组件，由于没有类似服务化这种技术契约约束，也很难在不同团队间实现无缝沟通和共享，加之公共能力都是些本地API实现，这就导致公共API被重复开发，不能在团队间有效重用，这会导致编写大量的重复代码。
3）系统可靠性变差。随着业务的发展，访问量逐渐攀升，网络流量、负载均衡、数据库连接等都面临巨大压力。某个节点的故障会导致分摊到其他节点的流量陡增，引起“雪崩效应”，高并发、大流量对系统的可靠性要求非常高。垂直架构将所有的应用模块都部署到同一个进程中，如果某个应用接口发生故障，例如内存泄漏，会导致整个节点宕机。由于是对等集群部署，这就意味着其他节点也有类似问题，宕机可能会此起彼伏，严重影响业务的正常运行。
4）维护和定制困难。由于业务代码不断膨胀，功能越来越复杂，已有垂直架构模式下无法对复杂的业务进行拆分，代码修改牵一发而动全身，维护和定制都非常困难。
5）新功能上线周期变长 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。